Edward Jaffe wrote:
<snip>
However, when I experimented with this a while back, I found that it
worked as expected only when the HLQs of the base name and alias were
the same -- or more precisely -- expected to be in the same catalog.
I believe both the alias entry and the related object must be in the
same catalog for data set aliasing to work.
I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create
'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID
are cataloged in a user catalog. Data sets starting with SYS1 are
cataloged in the master catalog. Try as I might, I could not figure out
how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of
'MYUID.BASE'. (Perhaps I overlooked something.)
I think this is because you did not place the entry for
SYS1.ALIAS.OF.BASE in the usercat, but I don't have a system to test
that assumption on these days. You might try:
DEFINE -
NONVSAM( -
NAME('MYUID.BASE') -
VOLUMES(volser) -
UNIT(3390)) -
CATALOG('usercat.with.myuid.in.it')
DEFINE -
ALIAS( -
NAME(SYS1.ALIAS.OF.BASE) -
RELATE(MYUID.BASE)) -
CATALOG('usercat.with.myuid.in.it').
Omitting the CATALOG keyword will try to place the alias entry in the
master catalog, and I think you'll see a message that says INVALID
RELATED OBJECT.
Or...is this exactly what you tried, only to find that it didn't work?
The above restriction should not be important in most if not all system
data set cases. Indeed, the example of SYS1.SBLSxxx vs
SYS1.IPCS.SBLSxxxx is a classic example of where extended aliases would
be applicable. Seems like ServerPac could distribute a procedure/program
to create/issue the appropriate DEFINE ALIAS statements for any data
sets whose HLQs were changed from the delivered defaults.
Extended aliases (those defined with SYMBOLICRELATE) don't work well
(i.e., at all!) for entries in the master catalog. Did you mean data
set aliases?
I think you might recall the early days of the ADCD systems, for which I
made all the data sets start with SYS1 for simplicity's sake*. People
complained because the data set names didn't match the books (a fair
point!). In the next iteration I used data set aliass. Then, people
complained because they thought the solution complex and because the
allocated data set names didn't match those specified in JCL on on an
ISPF panel (also fair, but the alternatives seemed worse).
(*This all happened before we put a stop to release-related qualifiers
for z/OS data sets. People stopped complaining when they found that
migrations were dead easy from a catalog standpoint because the data set
names didn't change.)
In other words, it certainly *sounds* like an attractive solution, but
experience has shown me otherwise, and these days I aim for KISS-like
solutions.
I highly recommend the use of static data set names from a catalog
standpoint because it simplifies migration and removes opportunities for
error. Using the names we ship simplifies things more because one need
not edit the PROCs, etc., we ship that name the data sets. Of course,
if you've been using different names for a Long Time, there can be
significant migration effort needed to get there. Nonetheless, it will
probably pay you back...eventually.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
