Multiple IAM/RLS Address Spaces

Multiple IAM/RLS Address Spaces

IAM will allow customers to run multiple IAM/RLS address spaces per MVS image (LPAR or System). There could be several reasons to run multiple IAM/RLS address spaces. For example, one might want to isolate different applications such that a failure with one application grouping will not impact other unrelated applications. Another reason might be for billing purposes, to be able to isolate as much as possible the processing for different applications or customers, by eliminating common server address spaces. Or, it could be necessary or desirable for security purposes to have certain applications isolated from others.

Related topics

CICS-Considerations


Irrespective of the reason, customers that desire to utilize multiple IAM/RLS address spaces will need to have well defined groups of data sets and processing that can be isolated from each other to make this possible. The use of multiple IAM/RLS address spaces is subject to the following restrictions:

  1. A batch job, CICS region, or TSO user can only be connected to only ONE IAM/RLS address space. Therefore, all IAM data sets that require IAM/RLS processing for that user address space must be handled under the same IAM/RLS address space. This is necessary to avoid problems with coordination of journaling, recovery, syncpoint processing and the associated overhead involved in such if multiple IAM/RLS address spaces are involved.
  2. An IAM data set can only be opened by ONE IAM/RLS address space at a time.
  3. Each IAM/RLS address space must be started with its own unique proc and name.
  4. Each IAM/RLS address space must have its own set of journals, parameter input, and record lock journal data set if needed.
  5. Each IAM/RLS address space requires its own system LX. A system LX is used to establish the cross memory environment required to use an IAM/RLS address space. Due to system limitations on the number of system LXs, this will restrict the maximum number of IAM/RLS address spaces that can be used unless the address space is started with the REUSASID=YES parameter on the START command for the IAM/RLS procedure.
  6. All IAM/RLS address spaces in a SYSPLEX must use the same DATASET NAME TABLE.

RLSID

Each IAM/RLS address space will be identified by a unique 4-character identifier within the scope of a SYSPLEX, referred to as the RLSID. The RLSID can be indicated via the RLSID startup parameter for IAM/RLS. If the RLSID startup parameter is not specified, then the IAM Global Options Table will contain a default value for the RLSID, which will be set as IAM is shipped to RLS1. Customers will be able to revise that value as they desire.

During OPEN processing for an IAM data set, a “default” IAM/RLS will be referred to as necessary. The “default” associated IAM/RLS address space will be determined using the RLSID and based upon the current status of the association with an IAM/RLS address space. Once a batch job, CICS region, or TSO user has opened an IAM data set for processing through an IAM/RLS address space that IAM/RLS address space will be the only IAM/RLS address space that can provide services to that job, region, or user. If no connection to an IAM/RLS address space has been established, then the IAM/RLS address space to connect, will be selected based on the following criteria, from highest to lowest priority order:

  1. From the RLSID specified via an IAM ACCESS Override for this job step that relates to the data set being opened. The RLSID could be specified on either an override that explicitly specifies the data set being opened via DDNAME or DSNAME, or if no such override has been given, then by an Override for DD=&ALLDD.
  2. If no ACCESS override is applicable, then the RLSID that was specified via an IAM CREATE Override when the data set was defined or loaded will be used, if any was so indicated.
  3. If no RLSID overrides were specified and if the data set name table processing is indicated then the desired RLSID can be obtained from the data set name table.
  4. If RLS processing is required for this data set and there has been no specification of an RLSID then the RLSID from the IAM Global Options Table loaded for this job step will be used.

There is only one data set name table that is to be used and shared among all of the IAM/RLS and IAM/PLEX address spaces within a SYSPLEX. This is different from the prior releases where each IAM/RLS address space had its own table. This change was made to make it easier to manage the table, particularly when there are multiple IAM/RLS or IAM/PLEX address spaces. The revised table also provides for data set name masking capabilities as well as allowing specification of the desired RLSID.

Recommended Implementation

The implementation method chosen by many users is the data set name table. This method offers a single point of control over which data sets are going to be utilizing IAM/RLS and eliminates the need for any JCL changes for jobs utilizing IAM/RLS. The requirements to utilize this method are:

  1. Building a card image data set containing the data set SELECT list and if necessary, a data set EXCLUDE list along with the desired RLSID to handle each SELECT group.
  2. Specification of the table via a DD statement in each of the IAM/RLS JCL procedures. Each IAM/RLS procedure MUST specify the same table.
  3. Revising the IAM Global Options to RLS=(TABLE,OPTIONAL) or RLS=(TABLE,REQUIRED).
  4. Starting an IAM/RLS (or IAM/PLEX) address space on each LPAR that is using IAM files during IPL, or before any IAM files are processed. If RLS=(TABLE,REQUIRED) is used, then no IAM files will be able to be opened until an IAM/RLS or IAM/PLEX address space has initialized a table in virtual storage. With Version 9.2 and above a special startup procedure can be used that will start the IAM VIF and load the data set name table, but will not actually start IAMRLS or IAMPLEX.

One specifies the RLSID on the SELECT statement like the following:

  • SELECT RLSID=RLS1,DSN=(IAM.DATASET.ONE,
    IAM.DATASET.TWO,IAM.APPL1*)
  • SELECT RLSID=RLS2,DSN=(IAM.DATASET.THREE,IAM.DATASET.FOUR)

If the RLS Global Option is set to use the data set name table, then the first 2 data sets and any that match the beginning of the file name IAM.APPL1 will automatically be opened under RLS1, and the second 2 data sets will be opened under RLS2.

A second recommended method of implementing the use of multiple IAM/RLS address spaces is to have all files that are going to be using IAM/RLS services to be defined with the IAM CREATE Override of RLSID=nnnn indicating the IAM/RLS address space is to process it. The primary advantage of this method of implementation is that it eliminates the overhead during open processing of every IAM file for scanning the table to determine eligibility for IAM/RLS and eliminates the need for the ECSA storage used to hold the table. There also is no need to change the JCL of any of the jobs using this data set, other than the job that define or reorganizes it. The specification of the CREATE Override of RLSID will indicate that this data set is requesting / requiring IAM/RLS services from the specified IAM/RLS address space. The RLSID can be revised or eliminated at any time through the use of the DEFINE RECATALOG process.

Alternative Implementations

An alternative implementation method is to use the IAMACCESS Overrides. Using this method, the jobs and CICS regions that have the data sets requiring other than the “default” IAM/RLS address space will need to have their JCL changed to include an IAM ACCESS Override, for example:

//IAMOVRID DD *
ACCESS DD=&ALLDD,RLSID=xxxx
/*

If there are overrides for additional specific data sets, then they will have to include the RLSID=xxxx override as well.


 

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