RRDS Processing

A unique processing capability of fixed length record RRDS (numbered) files is that, they can be loaded in a random relative record number sequence. The records are actually stored in ascending relative record number sequence. VSAM will pre-format files when a higher relative record number is written, and then will go back and re-read and write out control intervals as lower relative record numbers are written. This can result in very high EXCPs when loading these files with VSAM. IAM takes a different approach. When a fixed length record RRDS is being loaded randomly, IAM will temporarily store the records in a data space. If necessary, multiple data spaces will be used. When the file load process closes the data set, IAM will then write the records out in ascending relative record number sequence. Because of this function, customers planning on using fixed length RRDS files that are loaded randomly will need to make sure that their installation exits provide for adequate data space usage for IAM to load these data sets.

Another consideration for fixed length record RRDS files is that, IDCAMS will ignore any values specified for FREESPACE on the define request. This is because VSAM reserves a fixed length slot within the cluster for each record. IAM does not reserve space for unused relative record numbers. To compensate for this, customers can either use the RRDSCI% Global Option to indicate a default amount of free space per block, or can use the I= (Integrated Overflow) IAM Override when defining or loading a fixed length record RRDS file to reserve some free space to allow for inserted records, or updated records where the length may change due to data compression.

IAM also supports loading variable length RRDS files in random relative record number sequence. An IAM override must be specified to do this because normal VSAM does not support this capability. To use this feature, specify on an IAM Override RRDSLOAD=RANDOM. As with fixed length record RRDS files, IAM will use data spaces to hold the records until the file is closed for load processing.

IAM supports data compression for RRDS data sets, using either the proprietary IAM software compression, or using the IBM hardware compression instruction. This may provide significant space savings for IAM RRDS files when compared to VSAM RRDS files.

Buffering

The file load process is essentially a sequential output process. To optimize the I/O process, IAM uses a different buffering technique than the Real Time Tuning that is used on normal file access and update. During open processing, IAM acquires a pool of buffers to be used, based on the default or overridden value for CRBUFOPT. The buffer pool is split into two sets. When the first set of buffers have been filled with data, IAM then issues the I/O for those buffers. Processing continues with the application passing records, which are placed into the second set of buffers. IAM is effectively providing I/O and processing overlap. When the second set of buffers is filled, IAM issues the I/O request to write all of those buffers, and waits if necessary for the I/O on the prior buffer set to complete. When that I/O completes, IAM continues accepting records into the first set of buffers. For efficient physical I/O, IAM always writes out data in full track increments. The largest number of buffers that will be used for a file load is specified by CRBUFOPT=MCYL. In that case, IAM acquires enough storage for two cylinders worth of data, and will write out a complete cylinder per physical I/O. The fastest file load is obtained by using CRBUFOPT=MCYL, which is the default setting from the IAM Global Options. Remember to supply buffers for the input file as well. For encrypted files, because VSAM Linear data sets are used, rather than performing buffer handling and buffer writes on a cylinder level, instead, the buffer handling and writing of data is done on a VSAM Control Area level. For more information, refer IAM-s-Real-Time-Tuning and IAM-Tuning-Guidelines .

64_Bit Virtual Storage

For circumstances where there is a virtual storage constraint, users can request the IAM load process acquire the buffers in 64-bit addressable virtual storage. This is done by specifying an IAM Create Override of CRBUFOPT=64BIT. This will result in IAM acquiring 2 megabytes of 64-bit virtual storage for the buffers, enough to hold 2 cylinders of data or 2 Control Area’s worth of data. The buffering technique is identical to the CRBUFOPT=MCYL, only the location of the buffers is different.

z/HPF High Performance FICON

IAM will automatically use z/HPF High Performance Ficon channel programs when zHPF is enabled on the system and the device that the data set is being written to supports the level of zHPF required for EXCP processing.

File Full, or Sx37 Error

IAM file load processing is protected by other products that will handle x37 type of abends. Such products change the secondary space allocations and can add additional volumes to the data set to avoid the x37 abend. If the recovery is not successful the x37 abend will still occur.

A file full error caused by an x37 abend during the load process is considered a fatal error by IAM. Because the index is written at the end of the data set, an out of space condition will prevent the index from being properly written out to DASD. There will usually be messages indicating some type of Sx37 error condition. To ensure that IAM is able to properly clean up after such a failure, in particular to release the ENQs that are issued, IAM will attempt to avoid an actual Sx37 abend under CICS. In that case, the request will fail with a file full logical error. A file full error will also be raised if the area being used for the temporary storage of the high keys is filled. This is considered a fatal error to the file load. Either increase the storage available for the data space by using the DATASPACE override, or if not using the data space, increase the allocation values for the work file in the IAM Global Options Table, with the WORKPRIMARY and WORKSECONDARY values.