Extended Alias Support

Alias entries are defined to allow a reference to a particular name to be translated to a different name for the actual data. This provides a means for users to access their data by a particular name without having to know the actual name of the data set that contains their data. This technique is particularly useful for migration from release to release of products.

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

The symbolic string must not exceed 44 characters, including all name segments and periods.

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.