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:
- 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, preventing the application program from closing
subsequent DEBs in that chain.
- 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:
- 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.