DFSMS catalog enhancements for z/OS V2R1

The catalog component of DFSMS provides the following enhancements:

• VSAM record-level sharing (RLS) directory only caching: This enhancement adds new DIRONLY parameter to DATACLAS RLSCFCACHE, which specifies that RLS not cache the data or index part of the VSAM data set in the coupling facility cache structure.
• Generation data set (GDS) support for PDSE data sets: This enhancement removes the restriction against defining an SMS-managed partitioned data set extended (PDSE) as a generation data set (GDS). Both allocating a PDSE and defining a generation data group with generation data sets, including PDSEs, is unchanged. See "DEFINE GENERATIONDATAGROUP" in z/OS DFSMS Access Method Services Commands.

  You must have a system at the z/OS® V2R1 level or higher to exploit the ability to define a PDSE as a generation data set. Attempts to define a PDSE as a generation data set on a system below the z/OS V2R1 level fails. In a mixed sysplex environment, systems below the z/OS V2R1 level see PDSE generation data set as a simple generation data set. Note also that DFSMShsm and DFSMSdss are unable to migrate or copy a PDSE generation data set from a z/OS V2R1 or higher system to pre-V2R1 systems. See "Data Set Organization of Generation Data Sets" in z/OS DFSMS Using Data Sets.

  The LISTCAT ENTRY output is enhanced to indicate when a generation data set is a PDSE by adding the DSNTYPE field with a value of LIBRARY.

• New CSI field names: You can now access the following fields using the Catalog Search Interface (CSI): ASSOC, ASSOCSYB, BUFND, BUFNI, HILVLRBA, INDXLVLS, SEQSTRBA, STRNO, and TRACKS.

  See "Field Name Directory" in z/OS DFSMS Managing Catalogs.

• JES3 allocation assist tape TS7700: For scratch and specific allocations, this enhancement allows you to use JES3 to direct the allocations to candidate clusters for scratch mounts or to particular distributed library clusters for specific mounts in the TS7700 Virtualization Engine.
• Validate and remove an incorrect DEB address from the DEB table with new new PURGE,PURGE=FORCE option on the DEBCHK macro: This function introduces the new PURGE,PURGE=FORCE option for the DEBCHK macro that tells catalog to validate and remove an incorrect DEB address from the DEB table. This is used when a DEB is FREEMAINed, but, for some reason the DEB table was not updated to remove that DEB address from the table. For example:
  1. An incorrect length in subpool 230 was FREEMAINed, including one or more DEBs
  2. An incorrect address was passed to FREEMAIN, including one or more DEBs.
  3. DEB storage was incorrectly overlaid, which destroys the next DEB pointer in that DEB, preventing the application program from closing subsequent DEBs in that chain.
  4. DEB storage was incorrectly overlaid, which destroys the next DEB pointer in that DEB. The system follows the DEB chain in the TCB for the terminating task and calls CLOSE for each DEB that the task neglected to close. If a CLOSE fails, the DEB is removed from the TCB DEB chain and from the DEB table. However if it gets a program check while following the DEB chain, it abandons the rest of the DEBs on the current TCB chain.

  The new PURGE,PURGE=FORCE option on the DEBCHK macro can prevent these problems by removing the DEB pointer from the DEB table without checking the DCB (or ACB). The caller must be in system key, supervisor state, hold the local lock, and the passed DEB pointer must exist in the DEB table but not not represent a valid DEB. See "Ensuring Data Security by Validating the Data Extent Block (DEBCHK macro)" in z/OS DFSMSdfp Advanced Services.

• IDCAMS support for large block interface (LBI): This enhancement allows IDCAMS REPRO and PRINT commands to perform on data sets with a blocksize larger than 32K, up to the maximum that the LBI interface supports, if the LBI feature is enabled. The blocksize is still limited to 32K when the LBI feature is not enabled. See the following:
  • To enable LBI, see z/OS DFSMS Using Data Sets
  • For the IDCAMS PRINT and REPRO commands, see z/OS DFSMS Access Method Services Commands.
• Catalog contention detection enhancements: The new MODIFY CATALOG,CONTENTION command can be used to specifies a new wait time or action (or both) for one of the reason classes or Catalog resources for which contention detection is available (ALLOCLCK, SYSIGGV2, SYSZTIOT, and SYSZVVDS). See z/OS DFSMS Access Method Services Commands for information on the MODIFY CATALOG,CONTENTION command.
• Generation data group enhancements: You can now specify the order in which the generation data set list is to be returned for data set allocation when the generation data group (GDG) name is supplied on the DD statement. GDG entries can now be returned in either FIFO (oldest GDS defined to the newest GDS) or LIFO (newest GDS defined to the oldest GDS) order for concatenation. See z/OS DFSMS Access Method Services Commands for information on the new FIFO and LIFO parameters for the ALTER and DEFINE GENERATIONDATAGROUP commands.

  Also see z/OS DFSMS Managing Catalogs for information on activating the new GDG FIFO function using the IGGCATxx keyword GDGFIFOENABLE.

• Catalog alias enhancements:
  • IDCAMS now resolves the symbolic related name for an alias to make sure requests are oriented to the correct catalog. Previously, orientation was to the master catalog, which could cause unexpected results. The restriction on the IDCAMS DEFINE ALIAS command that the resolved value for entryname must be a catalog entry that is located in the same catalog that contains the value for aliasname has been removed. See z/OS DFSMS Access Method Services Commands for information on the IDCAMS DEFINE ALIAS command.
  • IDCAMS DEFINE ALIAS command will record the alias creation date. This date can be helpful when cleaning up obsolete high level qualifiers. If an alias has no associated data sets, the alias creation date can be used to determine whether this is a new alias for which no data sets have been created yet or this is an obsolete alias that should be deleted.
  • IDCAMS will now check when deleting a catalog entry that has an associated alias to verify that the alias is related to the entry being deleted, before deleting the alias record. For example, non-VSAM record A has alias association C, but alias C has association D in its X record. In this case, the alias C should not be deleted when data set A is deleted. This check is done for all non-VSAM, GDS, and UCON records.