Special considerations with IAM Alternate Indexes
Renaming and copying
There are special considerations when any associated data set or all the associated data sets in an IAM Alternate Index sphere are renamed. These same considerations exist if the data sets are copied or restored with a new name. Because IAM data sets appear to the utilities performing such functions as non-VSAM data sets, the association information is not automatically updated when a data set name is changed. To update the association information, a DEFINE RECATALOG must be done on all of the affected Alternate Index and path data sets.
IAM has a function that automatically performs this recatalog process when the renamed data set is opened, providing that the change in the name is identical in each of the cluster, path, and Alternate Index components. Firstly, IAM verifies that all the components had identical name changes and determine the new name of each component. If satisfied, it internally performs the recatalog. If it fails, then you should perform a manual recatalog.
To perform a manual recatalog, the base cluster should be recataloged first, followed by the Alternate Index data sets, and then the path data sets. The information that must be provided includes the new data set name, the new related or path entry data set name, and for base clusters and Alternate Index data sets, the volumes. If the volumes are unknown or include DFSMS candidate volumes, then specify a volume of ANYVOL. The ANYVOL specification indicates that IAM uses the volumes that are currently in the catalog. The base cluster RECATALOG must also include the OWNER($IAM) parameter, which is optional for the Alternate Index and Path recatalog. The IAM Alternate Index support intercept for the DEFINE RECATALOG function has processing to reset the association names. An example of a DEFINE RECATALOG is shown below.
Example of recatalog after a rename (EX1065A)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER-
(NAME(newname.iam.cluster)-
OWNER($IAM)-
VOLUME(ANYVOL)-
RECATALOG )
DEFINE ALTERNATEINDEX-
(NAME(newname.iam.aix)-
RELATE(newname.iam.cluster)-
VOLUMES(ANYVOL)-
RECATALOG )
DEFINE PATH-
(NAME(newname.iam.path)-
PATHENTRY(newname.iam.aix)-
RECATALOG)
LISTCAT ENT(newname.iam.cluster) ALL
LISTCAT ENT(newname.iam.aix) ALL
LISTCAT ENT(newname.iam.path)ALL
/*
Removing association information
If you have only made a copy of the base cluster and renamed it, you can eliminate the association information from the base cluster by issuing a DELETE cluster name AIX NOSCRATCH. IAM recognizes the special delete and remove all of the associations from its definition.
Delete support
IAM Alternate Index support includes special processing for data set deletion. As with VSAM, when the base cluster is deleted, all related Alternate Index and path data sets will also be deleted, providing that the SVC 26 DELETE interface is used. This interface also requires that the related data sets be cataloged. If a related data set is not cataloged, it will be skipped over by the delete process. This is the interface that is used by IDCAMS, the TSO DELETE command, and the IAM ISPF panels. If the SCRATCH SVC interface is used for non-SMS managed volumes, then IAM does not intercept the request, and only the specified data set is deleted.
If a delete is issued for an Alternate Index, then the Alternate Index and any related paths are deleted. If the delete is issued for a path, only the path is deleted. These actions are consistent with VSAM delete processing.