SMS Support in IAM

Overview

IAM provides support for SMS that is equivalent to the VSAM support, including support for JCL file definition, and temporary data sets. By definition, to be eligible for an SMS managed volume, the file must be assigned a Storage Class. The Storage Class, along with optionally a Data Class and/or Management Class, can be explicitly specified on the DEFINE command, by JCL parameters for JCL defined files, or selected by the ACS routines. IAM files on SMS managed volumes will be cataloged with the class names. As a part of the SMS support, an additional method of triggering an IAM DEFINE is available. Files will be defined as IAM files if the Data Class or Storage Class name contain the $IAM literal.

SMS Automatic Class Selection Routines

For both IDCAMS DEFINEs and VSAM JCL allocations, the ACS (Automatic Class Selection) routines are called prior to the IAM DEFINE intercept. When IAM intercepts the request, the SMS classes, the SMS Storage Group, and the SMS volumes have already been selected. IAM will then screen the request and determine if the file should use the IAM format. If $IAM, in the Data Class (DATACLAS) or Storage Class (STORCLAS) name, is being used as the criteria for determining IAM format files, then the class names must have $IAM in them at this point in the process. They contain either the explicit names from the DEFINE request, or the names selected by the ACS routines. This allows the installation the possibility of controlling IAM files, and IAM usage through the ACS routines. For JCL allocation, these are the classes and volumes that will be used.

For IDCAMS DEFINE requests, the ACS routines will be re-entered when IAM issues the dynamic allocation of the file as a non-VSAM data set. The request will specify the SMS classes as received from the intercepted DEFINE request, and the volumes that had initially been selected by SMS. On the second pass through the ACS routines, IAM files can be identified checking the DDNAME field for a value of @#$IAM. The ACS routines can change the SMS classes and the Storage Group, which will change the volumes on which the file is placed. At this point, the file must not be switched to a non-SMS volume, because the allocation will fail. However, it can be switched from an unmanaged volume to an SMS managed volume. Changing the DATACLAS at this time will have no effect on the file characteristics, as they were determined by IAM prior to the dynamic allocation. The MGMTCLAS, STORCLAS, and Storage Group can all be effectively changed by the ACS routines on the dynamic allocation request.

SMS Classes

IAM provides full support for IDCAMS defines under SMS. The DATACLAS, STORCLAS, and MGMTCLAS can either be explicitly provided on the DEFINE command, or selected by the ACS routines. The Data Class can provide file characteristics for the file being defined, including record length, key length, key offset, share options, free space, and others, eliminating the need to specify those values explicitly on the DEFINE. As per SMS rules, the options in the Data Class will be used, unless explicitly overridden on the DEFINE command.

DFSMS Extended Format

While IAM files can optionally be defined as DFSMS extended format sequential data sets, We recommend that DFSMS Extended Format IAM files be converted to DSNTYPE=LARGE format. These data sets can fully utilize larger volumes, such as a 3390-9 or even larger volumes of up to 64K cylinders. With z/OS 1.11 or higher these data sets can fully utilize EAV volumes, those exceeding 64K cylinders. These data sets can use up to 123 extents per volume and exceed the prior limit of 255 extents in total, when multiple volumes are specified. Such data sets must be DFSMS managed, with a data class that specifies “Extended Required” or “Extended Preferred” for the data set name type, and with Compaction set to NO. These data sets must also have a Storage Class with a Sustained Data Rate (SDR) either left blank, or set to 0. Setting other values for Sustained Data Rate will cause the data set to have multiple STRIPES, which IAM does not support. IAM will internally compress the file, with either software or hardware compression.

Allocation Errors

If the IAM allocation encounters any errors, the error messages will appear on the JES job log, with the Z/OS allocation messages (SYSMSGS) and also on the IDCAMS SYSPRINT, if it is available. Because of the manner in which IDCAMS prints messages on SYSPRINT, the error messages from IAM will precede the actual DEFINE command. IDCAMS will also print out additional error messages after the DEFINE, performing an analysis on the return codes set by IAM. When possible, IAM uses the VSAM return codes that most clearly indicate the actual problem, although that is not always possible. Always see the IAM and related allocation error messages for the most precise problem determination possible.

JCL Allocations

VSAM files being defined through JCL can also be easily converted to IAM files. This is done by either putting $IAM in the data set name (DSN), or by using a Storage Class (STORCLAS) or Data Class (DATACLAS) with $IAM in the name. Both permanent and temporary data sets can be defined, with the restriction that temporary data sets cannot be multi-volume, same as with VSAM. The use of a Data Class (DATACLAS) is highly recommended for JCL defined files. By using a Data Class, values for Free space, CI Size, and Share Options can be specified, which are not available through JCL parameters. All files defined in JCL will, by default, be capable of handling variable length records, up to the maximum length specified in the DATACLAS or LRECL field.

To allocate IAM files through JCL, IAM must be in the link list. STEPLIB and JOBLIB are ineffective in this case, because it is the initiator that is issuing the allocation, and IAM must have access to various load modules for the define.

If the IAM allocation encounters any errors, the error messages will appear on the JES job log and with the Z/OS allocation messages (SYSMSGS). SMS will also print out additional error messages appearing with the z/OS allocation messages, performing an analysis on the return codes set by IAM. IAM uses the VSAM return codes that most clearly indicate the actual problem, although that is not always possible. Always see the IAM and related allocation error messages for the most precise problem determination possible.

Any CREATE overrides for JCL allocated files must be in the job step that loads the file, not necessarily the step allocating the file. The define process does not access the IAMOVRID DD for JCL defines. For example, if the file is allocated in an IEFBR14 step, and then subsequently loaded by an IDCAMS REPRO, the IAM create overrides must be in the IDCAMS REPRO step.

Dynamic Allocation

The TSO ALLOC command, and the Z/OS DYNALLOC service, has also been enhanced to provide for allocation of new and temporary VSAM files. These requests will also be screened by IAM, and can be converted to an IAM file in the same manner as a JCL allocation can. IAM treats the request just like a JCL request. The new ALLOC keywords are the same as the new JCL keywords, and dynamic allocation has the equivalent text units.

Multi-volume

IAM files can be spread across multiple SMS managed volumes, both with and without Guaranteed Space.

Note

As IBM restricts temporary VSAM files to a single volume, this also applies to

When an IAM file is defined with a Storage Class that specifies Guaranteed Space, the primary allocation quantity is allocated on each volume at DEFINE time, as per the SMS non-VSAM rules. When Guaranteed Space is not specified, only the first volume is selected at DEFINE, and the subsequent volumes are cataloged as an '*'. During file load or reorganization, if additional volumes are needed, they will be selected by SMS. SMS has a restriction that within a job step, if a file defined without guaranteed space uses additional volumes, only one DD statement can be used, because any other DDs are not updated to indicate the additional volumes.