IAM/PLEX: IAM Sysplex Record Level Sharing

The IAM/PLEX feature builds on the IAM/RLS function by using XCF sysplex services and the Sysplex Logger to support Record Level Sharing (RLS) for IAM data sets across multiple LPARs within a z/OS sysplex.

IAM/PLEX capabilities for VSAM applications

IAM/PLEX feature is an evolutionary step forward from the basic single-system IAM/RLS, which has been in use for several years. The IAM/PLEX design is different from VSAM/RLS , so you can take advantage of RLS without the complexity involved in setting up a VSAM/RLS environment. IAM/PLEX provides the following capabilities for VSAM applications:

Concurrent data sharing in IAM files for update by batch and online applications from multiple LPARs and systems in a sysplex. This capability improves the availability of data on online systems by eliminating the need to close files while batch updates are underway.
Automatic record locking without application program changes. Batch jobs that do extensive update activity may need to use the IAM sync point process to avoid holding excessive record locks.
Support for the CICS VSAM RLS parameters UNCOMMITTED, CONSISTENT, REPEATABLE, and NOSUSPEND. IAM/PLEX provides equivalent functionality for these parameters.
Journaling for recovery and auditing purposes
Back out updates for failed applications, including an automatic dynamic back out of updates by a batch job step those abends
Recovery of data sets that have experienced a media failure
Specific or automatic batch sync point processing for batch jobs that do heavy update processing

IAM/PLEX concepts

Each data set is owned by one instance of an IAM/PLEX address space within the sysplex. Each IAM/PLEX instance is 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 a remote IAM/PLEX instance, such as an IAM/PLEX instance on another LPAR, is sent to the owning IAM/PLEX instance by using 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.

Users uses startup parameters to specify a four-character identifier (RLSID) for each data sets that IAM/PLEX. The RLSID specifies the named instance of IAM/PLEX, which is the owner responsible for processing the I/O requests for the subject data sets. Users assign the RLSID to a data set either by the IAM/PLEX data set name table, or by using the IAM CREATE or ACCESS overrides.

Each IAM/PLEX instance is also assigned to a group of IAM/PLEX instances referred to as the RLSGROUP. The RLSGROUP corresponds to the z/OS XCF group that is used for communication within the group. An IAM/PLEX instance can communicate with other IAM/PLEX instances that are in the same RLSGROUP only. Therefore, each IAM data set that is using IAM/PLEX services with an RLSID becomes a part of the same RLSGROUP of which the owning IAM/PLEX instance is a part. To access that data set, each LPAR requiring such access must contain an IAM/PLEX instance that is a member of that RLSGROUP.

Sample IAM/PLEX process

In the following diagram, one RLSGROUP named RLSPROD, which consists of two IAM/PLEX instances named RLS1 and RLS2. Each instance is running on a separate LPAR.

Suppose 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. IAM then sends the request from IAM/PLEX_RLS1 to IAM/PLEX_RLS2 by using XCF services. IAM/PLEX_RLS2 obtains the record lock, retrieves the record, and sends the record via XCF back to the CICS-1 address space through IAM/PLEX_RLS1. In this scenario, IAM/PLEX_RLS1 as the router, and IAM/PLEX_RLS2 is the target.

IAM/PLEX configuration concepts

The following basic concepts form the foundation for configuring an IAM/PLEX:

A job step, a CICS region, or any other address space can directly connect to only one IAM/PLEX instance. All user address space communication with other IAM/PLEX instances is through that one IAM/PLEX instance. Therefore, all the IAM data sets that an address space accesses through IAM/PLEX must be owned by an IAM/PLEX instance within the same RLSGROUP.
Each data set can 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.
An IAM/PLEX instance can be owned by only one RLSGROUP.
There can be multiple RLSGROUPs within a sysplex. Each RLSGROUP is completely independent of the other RLSGROUPs (for example, production RLSGROUP and a test RLSGROUP, or 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).
Multiple instances of IAM/PLEX address spaces can exist 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 is 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.
If you are using journaling, a shared sysplex system logger is required.
You can enable persistent record lock support by using a Record Lock Journal data set. If an IAM/PLEX instance is recycled, the record locks that it held at the time it was shut down or failed are reestablished, is reestablished by reading the Record Lock Journal data set and the sysplex system logger. Each instance of an IAM/PLEX that owns data sets needs its own Record Lock Journal to facilitate this process.
An automatic disconnect and reconnect function is available for CICS regions that use IAM/PLEX services for the following purposes:
- Avoid the need to recycle CICS regions
- Automatically reopen files that were being processed at the time of failure when the IAM/PLEX instance is available
- Initiate any transaction backouts that might be necessary because of the failure.
Based on our testing configuration, although you can use a Coupling Facility for XCF communications, the performance is significantly better when you use channel-to-channel (CTC) type links. Our configuration does not have a dedicated CF engine, so we do not currently have any data for that type of configuration. Depending on the workload, multiple pairs of links between each LPAR involved might be necessary to achieve the desired performance. Many components are involved in IAM/PLEX performance. In our environment, XCF communication uses the most time.

For more information about IAM RLS features and capabilities of IAM/PLEX, see IAM Record Level Sharing.

For more information about setting up and using IAM/PLEX, see IAM-PLEX-Record-Level-Sharing.

Configuring XCF for the IAM/PLEX performance

IAM/PLEX uses XCF for communication between its address spaces running on different LPARs, so it's important to properly configure XCF to ensure good application performance (both online and batch).

If you already use Db2, IMS, or VSAM/RLS in your production sysplex environment, then your XCF configuration is already set for the best performance. If, however, you experience unexpected response delays or longer-than-expected elapsed times, then you might need to update your XCF configuration. Try performing the following actions:

Add more XCF paths, typically of different size from the existing ones..
Spread the signaling structures over multiple ICF/CFs.
Use dedicated engines on the control file in the production environment (not shared).
Consult the relevant IBM documentation.

Important

If you are not using the n-way data sharing in the current configuration, the increase in XCF activity related to IAM/PLEX might cause additional stress. In this case, consider configuring additional hardware. You are already using n-way data sharing if the current environment is using Db2 or IMS in your sysplex environment.