Orientación y objetivos del documento

Enhancements to GDG base processing and LISTCAT command output for both GDG bases and symbolic resolution provide you with information to better manage your storage environment.

3.2.1 Changes to GDG base processing

There are two related changes made to the processing of GDG bases: the removal of support for the specification of an expiration date on the base itself, and the addition of a last-altered date.

GDG alter date

A LISTCAT of a GDG base has a new field labelled LAST ALTER which displays the last date that a GDS was added to or removed from the GDG base. The alteration only applies to a change in status of a GDS; it is not an indication of changes to the GDG base itself. We show a section of the output from a LISTCAT in Figure 3-1.

The date altered will be available via a new field, GDGALTDT, to the Catalog Search Interface (CSI). It will only be valid when requested for a GDG base. More information on the CSI is available in the manual z/OS V1R3.0 DFSMS

Figure 3-1 LISTCAT output of GDG base

GDG expiration date

From z/OS V1R3 DFSMS, it is no longer possible to specify or alter an expiration date or retention period for a GDG base. It is still possible to specify and

manipulate expiration dates or retention periods for individual GDSs. The expiration date that used to be shown on a LISTCAT of the GDG base is no longer displayed.

In Figure 3-2 we show the output of a LISTCAT issued against a GDG on an OS/390 2.10 system.

Figure 3-2 Output from LISTC on pre z/OS V1R3 DFSMS system

When you migrate to z/OS V1R3 DFSMS, any expiration dates applied to GDG bases will no longer be effective; it will be possible to delete and GDG base without specifying the PURGE operand. There will be no way of determining if an expiration date had been assigned to this GDG base, and if so, what its value was.

LISTC ENT(MHLRES4.TEST.GDG) ALL GDG BASE --- MHLRES4.TEST.GDG IN-CAT --- MCAT.SANDBOX.Z03.VSBOX11 HISTORY DATASET-OWNER----MHLRES3 CREATION---2002.090 RELEASE---2 LAST ALTER---2002.099

ATTRIBUTES LIMIT---5 SCRATCH NOEMPTY ASSOCIATIONS NONVSAM--MHLRES4.TEST.GDG.G0001V00 NONVSAM ---- MHLRES4.TEST.GDG.G0001V00

LISTC ENT(MHLRES4.TEST.GDG) ALL

GDG BASE --- MHLRES4.TEST.GDG IN-CAT --- CATALOG.CS HISTORY DATASET-OWNER----MHLRES4 CREATION---1996.246 RELEASE---2 EXPIRATION---0000.000 ATTRIBUTES LIMIT---8 SCRATCH NOEMPTY ASSOCIATIONS

Chapter 3. DFSMSdfp enhancements 45

In Figure 3-3 we show the output from an attempt to alter the expiration date of a GDG on a z/OS V1R3 DFSMS system.

Figure 3-3 Output from attempt to alter expiration information for GDG base

If you have any processing based on the value found in the GDG expiration date field you will need to review this before upgrading your first system to z/OS V1R3 DFSMS.

3.2.2 Extended alias support

Extended alias support was introduced in DFSMS 1.5 and allowed data set names to be indirectly accessed by the use of system symbolics. For testing we defined the alias in Figure 3-4.

Figure 3-4 Defining a symbolic alias

The variable &SYSNAME resolves to SC64 on the system where this was tested, therefore references to MHLRES4.TEST.ALIAS should access data set

MHLRES4.SC64.ALIASTST.

There are several potential causes for the association between alias and data set not being successfully resolved, such as these:

򐂰 The symbol is not in use yet, because the system had not been IPLed. 򐂰 The data set has been given the wrong name.

򐂰 The symbol is entered incorrectly in the IDCAMS DEFINE. 򐂰 The symbol is entered incorrectly in the PARMLIB member.

ALTER MHLRES4.TEST.GDG TO(99365)

IDC3019I INVALID ENTRY TYPE FOR REQUESTED ACTION IDC3009I ** VSAM CATALOG RETURN CODE IS 60 - REASON CODE IS IGG0CLE8-30 IDC0532I **ENTRY MHLRES3.TEST.GDG NOT ALTERED

Note: Please ensure that you install the fix for HIPER APAR OW53804 when you install z/OS V1R3 DFSMS. We have included the text for this APAR in “Maintenance information” on page 171. The PTFs for this APAR should be applied to all down level systems that will share catalogs with a system running z/OS V1R3 DFSMS.

DEFINE ALIAS(NAME('MHLRES4.TEST.ALIAS') - SYMBOLICRELATE('MHLRES4.&SYSNAME..ALIASTST')

Prior to this release, listing the catalog would show the output in Figure 3-5, which tells you that the symbolic was entered correctly, but nothing more.

Figure 3-5 Output from a LISTC of a symbolic alias prior to z/OS V1R3 DFSMS In this release, there are two possible results, shown in Figure 3-6 and Figure 3-7.

Figure 3-6 LISTC of an unresolved symbolic alias

This tells you that the symbolic SUSNAME could not be resolved, which in this case would enable you to solve the problem, as it should have been SYSNAME.

Figure 3-7 LISTC of a successfully resolved symbolic alias

In Figure 3-7, you can see that the symbolic has been successfully resolved, so you will need to start looking to see if the data set is correctly defined.

ALIAS --- MHLRES4.TEST.ALIAS IN-CAT --- MCAT.SANDBOX.Z03.VSBOX11 HISTORY RELEASE---2 ASSOCIATIONS SYMBOLIC-MHLRES4.&SYSNAME..ALIASTST ALIAS --- MHLRES4.TEST.ALIAS IN-CAT --- MCAT.SANDBOX.Z03.VSBOX11 HISTORY RELEASE---2 ASSOCIATIONS SYMBOLIC-MHLRES4.&SUSNAME..ALIASTST RESOLVED-MHLRES4.&SUSNAME..ALIASTST ALIAS --- MHLRES4.TEST.ALIAS IN-CAT --- MCAT.SANDBOX.Z03.VSBOX11 HISTORY RELEASE---2 ASSOCIATIONS SYMBOLIC-MHLRES4.&SYSNAME..ALIASTST RESOLVED-MHLRES4.SC64.ALIASTST

Chapter 3. DFSMSdfp enhancements 47