IAM/PLEX: IAM Sysplex Record Level Sharing

IAM/PLEX

The IAM/PLEX feature provides record level sharing support of IAM data sets across multiple LPARs within a z/OS Sysplex. IAM/PLEX builds upon the IAM/RLS function by utilizing the XCF Sysplex services and the Sysplex Logger to provide a record level sharing capability for IAM files within a Sysplex.

Related topic

IAM-PLEX-CICS-Considerations

IAM’s implementation is an evolutionary step forward from the basic single system IAM/RLS that utilizes the IAM/RLS framework that has been in use for several years. The IAM/PLEX design is different from VSAM/RLS and is intended to enable users to take advantage of record level sharing without the complexity involved with setting up a VSAM/RLS environment. IAM/PLEX provides the following capabilities for VSAM applications:

  • Concurrently share data in IAM files at the record level for update by batch and online applications from multiple LPARs and systems in a Sysplex. This capability provides improved availability of data on online systems by eliminating the need to close files while batch updates are being performed.
  • Automatic record locking without application program changes. Batch jobs that do extensive update activity may need to utilize the IAM sync point process to avoid holding excessive record locks.
  • Support of the CICS VSAM RLS parameters UNCOMMITTED, CONSISTENT, REPEATABLE, and NOSUSPEND. IAM/PLEX provides equivalent functionality for these parameters.
  • Journaling capabilities that can be used for recovery and auditing purposes
  • Capabilities to back out updates for failed applications, including an automatic dynamic back out of updates by a batch job step that abends
  • Capabilities to recover data sets that may have experienced a media failure
  • Explicit or automatic batch sync point processing for batch jobs that do heavy update processing

IAM/PLEX Concepts

All of the logical and physical I/O processing for files handled by IAM/PLEX will be performed by an IAM/PLEX address space. IAM/PLEX operates with a concept that any particular data set will be owned by one instance of an IAM/PLEX address space within the Sysplex. Each IAM/PLEX instance will be responsible for all the I/O, record locking, and journaling services for the data sets that it owns. I/O requests for IAM data sets handled by remote IAM/PLEX instance, such as an IAM/PLEX instance on another LPAR, will be sent to the owning IAM/PLEX instance by utilizing the z/OS Sysplex XCF signaling services. The performance of the remote I/O process is dependent on the configuration of the XCF communication links between the LPARs.

Data sets that are being processed by IAM/PLEX are assigned an RLSID, which is a four character identifier specified by the user. The RLSID specifies the named instance of IAM/PLEX, that will be the owner to process the I/O requests for the subject data sets. The RLSID is assigned to a data set either by the IAM/PLEX data set name table, or through the use of IAM CREATE or ACCESS overrides. Each IAM/PLEX instance is assigned an RLSID through startup parameters.

In addition to the RLSID, each IAM/PLEX instance is assigned to a group of IAM/PLEX instances referred to as the RLSGROUP. The IAM/PLEX RLSGROUP corresponds to the z/OS XCF group that will be used for communication within the group. An IAM/PLEX instance can communicate with other IAM/PLEX instances that are in the same RLSGROUP only. In effect then, each IAM data set that is using IAM/PLEX services with an RLSID also becomes a part of the RLSGROUP that the owning IAM/PLEX instance is in. To access that dataset there needs to be an IAM/PLEX instance that is a member of that RLSGROUP on each LPAR requiring such access.

IAM/PLEX Diagram

image2021-4-21_17-36-44.png

In the above diagram there is one RLSGROUP named RLSPROD, which has two IAM/PLEX instances named RLS1 and RLS2. Each instance is running on a separate LPAR. For example, let us assume that CICS-1 wants to read a record for update in IAM DSN=PROD.B, which is owned by IAM/PLEX_RLS2. CICS-1 issues a standard read for update, which IAM processes and sends the request from IAM/PLEX_RLS1 to IAM/PLEX_RLS2 using XCF services. IAM/PLEX_RLS2 will obtain the record lock, retrieve the record, then send the record through XCF back to the CICS-1 address space through IAM/PLEX_RLS1. In this scenario, IAM/PLEX_RLS1 is known as the router, and IAM/PLEX_RLS2 is the target.

IAM/PLEX Configurations

When configuring how to set up an IAM/PLEX, there are some basic concepts that form the foundation of how IAM/PLEX works. The most essential basic concepts are the following:

  1. A job step, a CICS region, or any other address space can directly connect to only one IAM/PLEX instance. All of that user address space communication with other IAM/PLEX instances will be through that one IAM/PLEX instance. Therefore, all of the IAM data sets that an address space accesses through IAM/PLEX must be owned by an IAM/PLEX instance that is within the same RLSGROUP.
  2. Any particular data set can only be owned by one IAM/PLEX instance. Therefore, any user address space that needs to access that data set through IAM/PLEX must be either directly connected or remotely connected through the same RLSGROUP.
  3. An IAM/PLEX instance can belong to only one RLSGROUP.
  4. There can be multiple RLSGROUPs within a Sysplex. Each RLSGROUP is completely independent of the other RLSGROUPs. Examples might be a production RLSGROUP, and a test RLSGROUP. Or there could be RLSGROUPs for different business units, where each group has its own set of unique data sets with no need to access data sets in different RLSGROUPs.
  5. There can be multiple instances of IAM/PLEX address spaces on a single LPAR. When multiple IAM/PLEX instances that are members of the same RLSGROUP are active on the same LPAR only one instance will be eligible for direct connection by users on that LPAR. The other instances of the same RLSGROUP are treated as remote instances with services provided through XCF.
  6. A shared Sysplex system logger is required if journaling is being used.
  7. Persistent record lock support is available with the use of a Record Lock Journal data set. If an IAM/PLEX instance is recycled, the record locks it held at the time it was shut down or failed, will be reestablished by reading the Record Lock Journal data set and the Sysplex system logger. Each instance of an IAM/PLEX that owns data sets will need its own Record Lock Journal to facilitate this process.
  8. An automatic disconnect and reconnect function is available for CICS regions that are utilizing IAM/PLEX services. This will help prevent the need to recycle CICS regions, automatically re-open files that were being processed at time of failure when the IAM/PLEX instance is available and initiate any transaction backouts that may be necessary due to the failure.
  9. Based on our testing configuration, while a Coupling Facility can be utilized for XCF communications, the performance is significantly better through the use of channel to channel (CTC) type links. Our configuration does not have a dedicated CF engine, so we do not have any data at this time for that type of configuration. Depending on the workload, multiple pairs of links between each LPAR involved may be necessary to achieve the desired performance. There are many components involved in IAM/PLEX performance, from our environment the XCF communication is the major component utilizing the most time.

Please also read IAM Record Level Sharing on the IAM Record Level Sharing for additional information on the features and capabilities of IAM/PLEX.

Full information on setting up and using IAM/PLEX is in IAM-PLEX-Record-Level-Sharing of the IAM Space.



 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*