SYMBOLICRELATE and DELETE

Answer

When a data set ALIAS of NON VSAM is created using DEFINE ALIAS RELATE and when a DELETE is done against the REAL data set, the data set alias is deleted as it has an the actual data set does have a association.

However, when a data set ALIAS of NON VSAM is created using DEFINE ALIAS SYMBOLICRELATE and when a DELETE is done against the REAL data set, the data set alias created using SYMBOLICRELATE is not deleted. This is because the entry is not associated with any real data sets and it is only a catalog entry.

SYMBOLICRELATE aliases can resolve to different data sets depending on what system you are in and it wouldn't be in the best interest to delete it when it may be valid on other systems, for this reason, DELETE will not remove the data set ALIAS created with SYMBOLICRELATE.

Manual updates have been submitted via readers comment form for future releases.

Following are the updates:

If the non-VSAM data set has aliases, all of its alias entries are deleted when you use the DELETE command.

If the non VSAM data set has aliases that are defined using RELATE parameter, all of its ALIAS entries are deleted when you use the DELETE command.

If the non VSAM data set has aliases that are defined using SYMBOLICRELATE parameter, the ALIAS entries are NOT deleted when you use the DELETE command. see "Extended Alias Support" in z/OS DFSMS Managing Catalogs.

If the non-VSAM data set is partitioned, you can delete one of its members by specifying pdsname(membername).

If the non-VSAM data set does not have an entry in a catalog, you can delete its format-1 DSCB from the VTOC by using the SCRATCH function of the IEHPROGM utility. See z/OS DFSMSdfp Utilities.

Use this parameter to delete generation data sets (GDSs). You can rerun the job step to reclaim a GDS that is in deferred roll-in state, if GDS reclaim processing is enabled (it is enabled by default). For more information about GDS reclaim processing, see z/OS DFSMSdfp Storage Administration.

SMS does not support temporary non-VSAM data sets.

Exception: You can use RACF commands to specify an ERASE attribute in a generic or discrete profile for a non-VSAM data set. Use of the attribute renders all allocated DASD tracks unreadable before space on the volume is made available for reallocation. Refer to the appropriate RACF publications for information about how to specify and use this facility.

Abbreviation: NVSAM

New/Changed documentation(same as current, except added a NOTE: at the bottom)

For example, the names of libraries for different releases or versions of products can contain the release or version information. An alias can be created without this information, so users are not aware when the underlying library changes. This minimizes the impact on job control language and TSO changes as a result of migrations.

As an example, if SYS1.V1R6M0.PRODUCT is the name of a product library, an alias of SYS1.PRODUCT is created by this IDCAMS DEFINE command:

    DEFINE ALIAS (NAME(SYS1.PRODUCT) RELATE(SYS1.V1R6M0.PRODUCT))

Users can now reference SYS1.PRODUCT, and if version 1 release 4 of the product is installed, the alias name can simply be changed to refer to the new library. This allows the new version of the library to be tested without disrupting current users.

A particular problem occurs in environments that share catalogs, particularly master catalogs. Different systems might be at different levels of software. Users would like to use the alias approach to minimize the effect of data set name changes. However, the actual data set name had to be specified when the ALIAS was defined; therefore all systems would see the same value.

A parameter for the DEFINE ALIAS command, SYMBOLICRELATE, allows the specification of the base data set name using system symbols. The above example could then be defined as:

       DEFINE ALIAS (NAME(SYS1.PRODUCT) -
            SYMBOLICRELATE('SYS1.&PRODVR..PRODUCT'))

If the system symbol '&PRODVR' was set to 'V1R5M0' on System A, and 'V1R6M0' on System B, then a reference to the name SYS1.PRODUCT would access the proper data set, depending on what system the alias name was used from. To set system symbols, see the z/OS MVS Initialization and Tuning Reference. In this case, the alias name is resolved at the time of use, rather than at the time of definition. As sharing systems are ready to upgrade to the new data set, they only need change the definition of the appropriate system symbol or symbols to access the new data set by the original alias.

This support is available for defining aliases of user catalogs, or for non-VSAM (non-GDS) data sets. If the string containing the system symbols cannot be resolved (for example, the symbol might not be defined on the referencing system), the reference will probably fail. This is because there would be no data set name that matched the value specified in the SYMBOLICRELATE keyword.

The actual resolution of the symbolic string to a data set name is done at two possible times:

• If the resolved name is a catalog, it is done at catalog address space initialization or when the multi-level alias table is reinitialized
• If the resolved name is a non-VSAM data set, it is done at the time of reference to the data set by a catalog request

NOTE: If the non VSAM data set has aliases that are defined using SYMBOLICRELATE parameter, the ALIAS entries are NOT deleted when you use the DELETE command. SYMBOLICRELATE aliases can resolve to different data sets depending on which system you are accessing and for this reason, DELETE will not remove the data set aliases defined using SYMBOLICRELATE as they may be valid on other systems.