z/OS V2R1 includes several enhancements for DFSMS catalogs, described in this section.
- VSAM 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. See Set Up VSAM RLS Directory Only Caching
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 Do Not Allocate a State Data Set as a GDS PDSE and 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 the Field Name Directory section 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. See Enable JES3 allocation assist tape TS7700 in DEVSUPxx.
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 the system to validate and remove an incorrect DEB address from the DEB table. This is used when a DEB is freed, but, for some reason the DEB table was not updated to remove that DEB address from the table. For example:
- An incorrect length in subpool 230 was FREEMAINed, including one or more DEBs
- An incorrect address was passed to FREEMAIN, including one or more DEBs.
- 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 represent a valid DEB. See Ensuring Data Security by Validating the Data Extent Block (DEBCHK macro) in z/OS DFSMSdfp Advanced Services.
- 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.
IDCAMS
support for record level sharing (RLS): This enhancement provides
RLS support for several IDCAMS operations, allowing users to copy,
print and backup VSAM data sets while sharing the data set with other
applications. A new RLSSOURCE parameter is added to the REPRO, PRINT,
and EXPORT commands, and an RLSTARGET parameter is added to the REPRO
and IMPORT commands. - For details on the command updates, seez/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.
- 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.
The following table lists the overall tasks to perform, to fully use the catalog enhancements.
| Tasks | Procedures you must perform: |
|---|---|
| Administering |