z/OS V2R2 includes several enhancements for DFSMS catalogs, described in this section.
- Catalog attributes health check: This enhancement is designed
to inspect all the catalogs currently defined in the user's environment
for shareoptions and DASD status and report any inconsistencies between
the two. The CATALOG_ATTRIBUTE_CHECK will notify the system programmer
of any inconsistent catalog(s) in their environment. The notification
will be done in the form of a report in the message buffer using SDSF.
The system programmer can decide to redefine or alter the inconsistent
catalog(s) with the correct shareoptions at a convenient time. See
the following:
- For new messages, see z/OS MVS System Messages, Vol 9 (IGF-IWM)
- For more information on the CATALOG_ATTRIBUTE_CHECK, see IBM Health Checker for z/OS User's Guide
- CSI Enhancements: This enhancement includes new CSI fields. For more information, refer to Sample Z Entry Request Output in z/OS DFSMS Managing Catalogs.
DUMPON support for catalog front end modules:
When you request CAS dynamic dumping with the MODIFY CATALOG,DUMPON
command, you can now specify modules involved in catalog front end
processing. For more information, refer to MODIFY CATALOG in z/OS DFSMS Managing Catalogs. 
- Catalog to use connect with MLWTO: This enhancement will assist all users of Catalog modify reports who are currently or will be in a situation where the maximum limit for the MLWTO is exceeded.
- Restore a user catalog to any volume: You
can now logically restore a user catalog to any volume with
the same device type as the volume from which it was dumped.
Previously, you could restore only to the same volume. Physically
restoring a user catalog is not changed — it must
be done to the same volume as the volume from which the
user catalog was dumped. For more information, refer to Restoring
integrated catalog facility catalogs in z/OS DFSMSdss Storage Administration.
Catalog modify command security enhancements: This enhancement will allow the MODIFY command for Catalog to separate authorization for those sub-commands which provide reporting capabilities from those sub-commands which alter the catalog environment. This is achieved by defining a new RACF Resource for the OPERCMDS class and permitting selected users with READ or UPDATE access.
- A new parameter has been introduced to allow the user to control adding the TSO user id as a prefix when running LISTCAT as a TSO command. This new parameter is PREFIX/NOPREFIX.
- A new option "CIMODE" has been introduced in the PRINT command and REPRO command to process data sets using CI level processing. This will allow the PRINT and REPRO commands to be able to read a broken VSAM ESDS dataset and extract the good records from it.
- IDCAMSPARM(TEST) enhancement: AMS commands use system adapters UGPOOL, UGSPACE, UGSPC16 to obtain core storage for command processing. Some of the commands such as PARM(TEST) have 31 bit support but still perform below the line, because those system adapters use a macro version of getmain/freemain (MF) that does not actually obtain the storage above the line as expected even though "LOC=ANY" is specified on the call of getmain.
- REPROMERGECAT output enhancement: IDCAMS will provide new optional keywords, MESSAGELEVE(ALL|SHORT) for REPRO MERGECAT. These options will provide existing or condensed output listings. ALL is the default.
- IDCAMS VERIFY: Original way as it is now where IDCAMS opens the data set for output and then issues the VERIFY macro with no options and then closes the data set.
- IDCAMS VERIFY RECOVER: Currently the RECOVER option causes VSAM Record Management VERIFY to back out or complete any interrupted CA reclaim in addition to regular IDCAMS VERIFY functions. There will be no change to this way of running VERIFY.
- EXAMINE/IDCAMS VERIFY RECOVER: This will be a new enhancement that is functional only when EXAMINE and VERIFY RECOVER are run in the same IDCAMS job step. EXAMINE has been enhanced to pass the error information that it finds (such as index CI#, data CI#, error type, and so forth) to VERIFY. As long as there is no concurent access on the data set, VERIFY will attempt to repair any errors that it can.
Using the Generation Data Group enhancements:- Extended format for generation data groups (GDGs):
z/OS V2R2 introduces a new extended format for generation data groups (GDGs). Extended format GDGs can contain up to 999 generation data sets (GDSes). The previous GDS limit was 255 GDSes per GDG. New GDGs can be defined with this new extended format. For existing GDGs, the previous GDS limit still applies.
To support this enhancement, the IDCAMS DEFINE GDG command includes a new optional parameter (EXTENDED) that you can specify to enable a new GDG to contain up to 999 GDSes. If you do not specify that parameter, the default value (NOEXTENDED) takes effect, setting a limit of 255 GDSes for the GDG.
A new GDGEXTENDED parmlib variable lets you specify whether to allow the EXTENDED value to be used on DEFINE of a GDG. If GDGEXTENDED(NO) (the default) is specified, then the DEFINE of a GDG with the EXTENDED parameter is not allowed. If GDGEXTENDED(YES) is specified, then the DEFINE of a GDG with the EXTENDED parameter is allowed. For more information, see the description of IGGCATxx in z/OS MVS Initialization and Tuning Reference.
The LIMIT parameter on the IDCAMS DEFINE GDG command is changed to accept a maximum value of 999 for extended GDGs. The previous maximum LIMIT value of 255 still applies to GDGs which are not defined as EXTENDED.
For extended GDGs, the IDCAMS ALTER LIMIT command is also enhanced to let you set a new GDS limit of up to 999 for the GDG. The z/OS Generic Tracking Facility has also been used to help determine if any calls to Catalog Management are only requesting the classic GDG limit, and not the extended GDG limit.
For more details about these enhancements, see the descriptions of the ALTER command and the DEFINE GENERATIONDATAGROUP command in z/OS DFSMS Access Method Services Commands.
- GDGSCRATCH parmlib variable:
z/OS V2R2 introduces a new GDGSCRATCH parmlib variable that specifies whether the default option on DEFINE of a generation data group (GDG) should be SCRATCH or NOSCRATCH. If GDGSCRATCH(NO) (the current default) is specified, then the flag in the catalog GDG record will be set to NOSCRATCH. If GDGSCRATCH(YES) is specified, the flag in the catalog GDG record will be set to SCRATCH. If the NOSCRATCH or SCRATCH keyword is specified on the IDCAMS DEFINE GDG statement, it will be honored regardless of the GDGSCRATCH(YES|NO) IGGCATxx parmlib setting. If GDGSCRATCH(YES|NO) is not in the parmlib, then the existing default of NOSCRATCH is used.
For more details about this enhancement, see the description of the DEFINE GENERATIONDATAGROUP command in z/OS DFSMS Access Method Services Commands and the description of IGGCATxx in z/OS MVS Initialization and Tuning Reference.
- New option for GDG management - PURGE: This enhancement adds a new PURGE option to the DEFINE and ALTER commands. Additionally, it adds a new LISTCST field to print the PURGE option. The PURGE option is valid only when the SCRATCH option is specified. It will override expiration dates when deleting generation data sets (GDSes). If not specified, the default is NOPURGE, but this can be overridden by the new GDGPURGE parmlib variable.