Special considerations for processing IAM data sets

JCL

In general, there are no JCL changes required to access IAM files in place of VSAM. The only required JCL parameters on the DD card for an IAM file are the DSN and DISP. If the JCL was set up to use Batch LSR for VSAM, that can be left in place for IAM, although IAM will not use any of the VSAM LSR buffers. Likewise, any AMP parameters can also be left in place. The BUFNI value will always be ignored by IAM, because it does not need or use index buffers. The BUFND value will be looked at and used as the value for MAXBUFNO, providing that there was no MAXBUFNO override, and that the value exceeds the default value for MAXBUFNO. STRNO will be used to establish the initial number of place holders, as done by VSAM.

While optional, users are highly encouraged to add an IAMINFO DD statement allocated to SYSOUT to job steps that are using IAM data sets. When this DD statement is present, a one-page report will be produced each time an IAM data set is closed, providing file characteristics and statistics from the execution, including logical and physical I/O counts, and storage requirements. As an alternative, users are encouraged to set up the IAM Global Options to write out the IAMINFO as SMF records. These records contain the same information without the need for modifying JCL. The IAMINFO reports can then be produced by running the IAMSMF program’s IAMINFO command.

Multiple ACB

IAM data sets can be processed by multiple ACBs opened within the same address space, either with the same or different DD names. IAM will share the control block structure and the index between the different ACBs, as long as all of the ACBs are opened under the same task.

The advantages of sharing the control block structure and index are that, doing so significantly reduces the storage required to process the data set with the multiple ACBs, plus it provides for complete data integrity between the different ACBs. If the sharing is not done, then each ACB is completely independent, and will be subject to the standard Cross Region sharing considerations. This means that unless a file is defined with Share Option 3 or 4, only one of the ACBs can be opened for update.

Another advantage of the sharing is that for CICS, or other long running jobs, there is provision for 24-hour operation, if IAM RLS is not being used. This is achieved by having one of the ACBs opened for read-only access, and the other being opened for update. When the update ACB is closed, all the updated data buffers are written out, and the necessary control information in the data set is updated. The data set can then be updated by other jobs. Then, when the update ACB is reopened, all the buffers are invalidated to make sure that only the current blocks from the data set are used, and the overflow and PE indexes are rebuilt to reflect the current state of the file. This will provide for online read only access to the file while it is being updated by batch processing, however, the online system will not have full read integrity for updated, added, or deleted records.

Pervasive encryption

IAM provides support for z/OS Pervasive Encryption. This support is automatically enabled when an IAM data set is defined with a Key label parameter specified on an IDCAMS Define Cluster statement, a security system Data Set Profile, or via the assigned SMS Dataclas. A Dataclas with the SMS Extended Format and Extended Addressability attributes turned on must be used. When IAM intercepts the Define for such an IAM data set, IAM will allocate a VSAM Linear data set instead of a non-VSAM DSORG=PS data set. All I/O to an IAM Linear data set will be executed through use of IBM Media Manager rather than EXCP. IBM Media Manager will take care of encrypting data for write operations and decrypting data for read operations.

Messages related to IAM’s defining of a VSAM Linear Data Set are output using a DD Name of IAMCAMS, if IAM Global Options are set to dynamically allocate the IAMCAMS output file or the user has added an IAMCAMS DD statement to their define step JCL.

What is a block in an IAM DSORG=PS non-encrypted data set is a Control Interval in an IAM Linear data set. Control Intervals in a Linear data set must be a multiple of 4K. For DSORG=PS non-encrypted data sets, IAM chooses a block size that is optimal for the geometry of the DASD type being used, most likely a 3390. IAM will choose a multiple of 4K for Linear datasets that is a best fit for the DASD type, but this best fit may not be as optimal as for DSORG=PS non-encrypted data sets. Therefore, when converting an IAM file to being encrypted, the file may grow somewhat in size.

IAM KSDS, ESDS, and RRDS data sets can be defined with a Key Label and therefore be encrypted. Applications that use ESDS data sets and are currently only capable of supporting 4 byte RBA ESDS data sets (non-Extended Addressability format) and wish to encrypt such ESDS data sets will need to specify either NOXESDS or PSEUDORBA on an IAM Override CREATE statement in the ESDS Define step. This is because the SMS Extended Addressability attribute will force ESDS/EA as a default.

Note that the first two Blocks (CIs) in an IAM Linear Dataset are non-data blocks that IAM uses for file control information. These first two blocks are not encrypted for performance and diagnostic reasons. All other blocks will be encrypted except for any empty preformatted blocks. To reduce the processing time of encryption, it is recommended that encrypted data sets utilize data compression. Either the IAM software compression can be used, or the IAM implementation of the IBM Hardware Compression instruction can be used.

Programs using z/OS Catalog Services to get information on IAM Encrypted Linear files will receive information back that shows them to be KSDS, ESDS, or RRDS data sets, the same as what happens for IAM non-encrypted physical sequential non-VSAM data sets.

Encrypted file in VSAM linear data set

IAM will intercept the Define of a KSDS, ESDS, or RRDS with a KEYLABEL and turn that request into a DEFINE of a VSAM Linear Data Set. The below attributes are required and some of these required attributes are inherited from the Define attributes of the KSDS, ESDS, or RRDS or from the Data Class used on the Define Cluster. Such required attributes are so indicated with an ‘*’ below. The Linear Data Set required attributes are:

• *SMS Extended Format
• *SMS Extended Addressability (>4gb)
• *Can not be compressed by SMS
• Reusable (IAM Linear requirement, the actual IAM logical data set does not need to be reusable.)
• Will be defined with Share Options 4,4. IAM will internally enforce the Share Options requested by use of an ENQ on major name of IAMENQ.
• *OWNER($IAM) for both cluster and data component when defined, unless the user has specified alternative OWNER information on the DEFINE CLUSTER for theIAM data set.
• Data Component name will be either the name specified by the user on the DEFINE request, or if no Data Component name was specified, then the Data Component name will be cluster name appended with ".$IAM" which may be truncated to minimum of .$ if insufficient room is at end of the name. If no room is available at the end, the DSN low level qualifier will be changed to “.$IAM”.
• CI Sizes in 4K increments up to 32K will be used for the VSAM Linear file. The blocking factors (B=) have been revised for Linear data sets to a specific set of CI sizes with B=1 being the largest block size at 32K, which is also still the most inefficient size for space utilization. B=4 is still the default, even though it isn’t precisely 4 blocks per track, but it does have the largest amount of space available on the 3390 architecture for 740K as opposed to approximately 802K in standard sequential data set with B=4. That is a decrease in usable DASD space per cylinder of 8%.
• For B=3, IAM internally uses VSAM ESDS file in place of VSAM Linear file, to support non 4K multiple CI size.

CI size table

Renaming IAM Linear data set

When renaming an IAM Encrypted Linear Data Set you will need to use two IDCAMS ALTER statements. You will need an ALTER statement with a NEWNAME keyword for both the Base Cluster name and the Data Component Name. Failure to rename the Data Component name will prevent a new IAM Encrypted Data Set from being allocated with the same Cluster Name as the original Cluster Name, since the IAM generated Data Component name will be considered a duplicate and already in existence by z/OS Catalog Services. If you need to find out what the current Data Component name is of an IAM Linear Data Set, run an IDCAMS LISTCAT ENT(base cluster name) ALL job and review the SYSPRINT output.

Record Level Sharing

IAM provides two features that enable sharing of IAM files at the record level. IAM/PLEX is an optional feature that enables applications running on different LPAR’s that are within a Sysplex to share IAM files for update processing with locking at the record level. IAM/RLS is the other feature and it is included with the base IAM product that enables applications running on the same LPAR to share IAM files for update processing with locking at the record level.

When using either of these two features the I/O requests are transferred over to an IAM/PLEX or IAM/RLS address space for processing, with data and status returned to the application program. Both of these features support concurrent batch and online system processing, along with journaling, recovery through the journals, and record locking. Each of the IAM/PLEX and IAM/RLS address spaces is assigned a unique 4-character identifier referred to as the RLSID. Each of the IAM data sets that is eligible for sharing is also assigned an RLSID to represent the address space that will handle that particular data set. An RLSID is assigned to a data set from the data set inclusion / exclusion table, or by the RLSID CREATE or ACCESS override. The basic underlying rules are that, a data set can only be owned by one of either an IAM/RLS or IAM/PLEX address space, and that any particular job or CICS region can only be directly connected to one IAM/RLS or IAM/PLEX address space. With IAM/PLEX jobs can access files handled by other IAM/PLEX address spaces providing that they are assigned to the same RLS group.

For CICS, there are no changes to CICS application programs. There are some IAM provided CICS exits required so thatIAM can properly identify and handle the CICS units of work.

Batch applications that do heavy update activity on recoverable files, that is those that have before image journaling enabled, will need to either use the automatic syncpoint capability, or include calls to the IAM syncpoint within their programs.

IAM/RLS sequential fast path

For applications that sequentially read a portion or the entire contents of an IAM file that is being processed through an IAM/RLS address space or a directly connected IAM/PLEX address space, a higher performance fast path will be automatically invoked. This fast path processing reduces the overhead caused by IAM/RLS, such that the sequential reader will have performance that is very close to the performance without using IAM/RLS. These results are achieved by IAM/RLS passing back several records to the job reading the file, thus significantly reducing the interaction between the job and IAM/RLS. The sequential fast path will be used only on sequential reads for input only. The sequential fast path is not used on sequential reads for update.

In test runs using the same 33-gigabyte file from the Long Key test, for an IDCAMS REPRO, the elapsed time for the RLS Fast Path run was 76% less than using RLS without the Fast Path. The CPU time was also reduced by 64%. This test was done using all default parameters.

The amount of data passed by IAM RLS to the application job can be controlled with theIAM ACCESS Override of RLSFP=. For this override, users can specify a value from 0 to 8. A specification of 0 will turn off the sequential fast path processing. Other values are used as multipliers on the file’s block size to determine the amount of storage that IAM RLS will use as a buffer between itself and the application program. The override is specified on the actual job step that is processing the IAM file sequentially. The default value is 2, meaning that approximately 2 blocks worth of data records will be passed back to the application program. For many jobs, the default value should provide sufficient benefit. For very large files, or files with long records, a higher value may improve performance even more. There is no IAM Global Option for the RLSFP value which can only be changed with an override.

Journaling

IAM provides capabilities to create a journal of data set update activity to facilitate data recovery and replication. Users can select from one of four different logging mechanisms to provide for data recovery, improve data availability, and auditing of update activity. These capabilities are:

• LOGREPLICATE which provides support for replication of data to an external system through the use of IBM’s GDPS Active–Active solution. This specifically enables IAM files to be used by the IBM InfoSphere Data Replication for VSAM for z/OS product to facilitate enhanced application and data availability. The same log stream can be used for multiple IAM files, and a mix of IAM and VSAM files. In addition to being used for replication, the records can be used by the IAMRREST utility to perform undo and / or redo recovery processing.
• FRLOG is a log stream journal process that will create all or a subset of the records that are written with LOGREPLICATE. These records can be used by the IAMRREST utility to perform undo and / or redo recovery processing. The same log stream can be used for multiple IAM files, or a mix of IAM and VSAM files.
• The IAMLOGVR address space can be setup to assist with LOGREPLICATE and/or FRLOG journaling to make security setup easier and to make Logstream error recovery more robust.
• IAM/RLS and IAM/PLEX can produce journal records for the IAM data sets that they are processing. These records can be used to provide undo or redo type of recovery processing by the IAMJREST utility program. A dynamic job backout function is also available with the IAMBREST program. IAM/RLS can write out journal records to either a rotating set of six sequential DASD data sets, or to a log stream. IAM/PLEX can only create journal records to a coupling facility log stream. These journal records are in an IAM format and can be used by either the IAMJREST utility of recovery processing or by your own recovery program. Either type of journal contains records for multiple IAM data sets that are covered by the journal process. Specification of this journal process, along with the type of records to be written to the journal are specified by the IAMJRNAD override when the file is defined, by the LOG() IDCAMS DEFINE parameter. IAM/RLS and IAM/PLEX both require the data set to be either defined for the journal processing, or an IAM JRNAD override needs to be specified on the IAM/RLS or IAM/PLEX address space.
• JRNAD or LOG parameter outside IAM/RLS and IAM/PLEX provides a simple journal process and journal records to a log file that is a sequential data set, allocated and managed by you with base IAM data set name appended with “.LOG”. Only one IAM data set can have journal records in the output journal data set and will need a “.LOG” data set for each IAM data set. The IAMJREST utility provides the support to perform recovery processing from this log for an individual data set.