@John, most excellent. I should have asked the guru of catalogs to begin
with. Thanks,

Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Eells
Sent: Tuesday, August 30, 2016 6:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Elementary dataset alias question

Yes, you can do what you want.

But first, you have to understand the notion of "catalog orientation."

All searches start in the master catalog.  If catalog connector alias is
found (for example, "EELLS") pointing to a user catalog (such as
"CATALOG.SVPLEX4.USERCAT"), then the search is redirected to the user
catalog, and *no matter what happens next (with one exception)*, it is
performed only within that user catalog.  So if JOEBLOW has an alias
pointing to a user catalog, the related-to data set entry being searched for
has to be in the *same* user catalog.  It can *also* be in the master
catalog, which can be sort of handy sometimes and sort of confusing at other
times, but the search for it in this case will ignore the entry in the
master catalog.  (If the SYS1.* data set is specified, the entry would be
found there, though, of course.)

With the foregoing in mind:

First, I defined a data set, SYS1.DELETEME.TEST, which was cataloged in the
master catalog as one might reasonably expect.  It can be found using the
master catalog in all the usual ways.

Then I issued these commands under ISPF OPT6:
 

define nonvsam(name('sys1.deleteme.test') volumes(d83xl2) devt(3390))
catalog('CATALOG.SVPLEX4.USERCAT')  <== This one adds the entry to the user
catalog my user ID's alias points to.

define alias(name('eells.deleteme.test') relate('sys1.deleteme.test'))
catalog('CATALOG.SVPLEX4.USERCAT') <== This one creates the data set alias.

So now, the system finds the EELLS alias entry, goes to the user catalog,
finds the EELLS.DELETEME.TEST alias entry, and searches within the *same
catalog* for the related-to SYS1.DELETEME.TEST entry, and finds the data
set.

I used ISPF 3.4 to display EELLS.DELETEME.TEST:
           EELLS.DELETEME.TEST 
   *ALIAS

When you issue the "I" line command, it shows the data set information for
SYS1.DELETEME.TEST.

And, then I used ISPF OPT2 to edit it (it was of course empty), which worked
fine too:

  EDIT       SYS1.DELETEME.TEST                     Columns 00001 00072

And, finally, I used IEFBR14 to allocate it:

//EELLS2   JOB 'C8402P,B9222070,S=I','JOHN EELLS',
//      CLASS=J,MSGCLASS=H,NOTIFY=&SYSUID,
//      MSGLEVEL=(1,1),REGION=0M
//*
//S0    EXEC PGM=IEFBR14
//DD1   DD DSN=EELLS.DELETEME.TEST,
//         DISP=SHR

...and all this works as expected, with these allocation messages:

IEF236I ALLOC. FOR EELLS2 S0
IEF237I A116 ALLOCATED TO DD1
IEF285I EELLS.DELETEME.TEST KEPT
IEF285I VOL SER NOS= D83XL2.

(The data set is never opened by BR14, of course, but it could be by another
program.)

To get rid of the data set, I will shortly:

- DELETE EELLS.DELETEME.TEST ALIAS
- DELETE SYS1.DELETEME.TEST NOSCRATCH CATALOG(CATALOG.SVPLEX4.USERCAT)
- Delete SYS1.DELETEME.TEST in ISPF OPT3.4 to finish the job.

I mentioned an exception.  When you use a system symbol in the related-to
field specified by SYMBOLICRELATE, the system will *start
over* at the master catalog, or "reorient the search to the master catalog."
It will then look for entries as if the search (e.g., LOCATE) request were
new, rather than a continuation of an existing search.  I think we did this
in z/OS V2.1 but I did not check to be certain.

With the exception of SYMBOLICRELATE, which we did change, I think there is
vanishingly little chance that we will ever change this behavior. 
For one thing, such a change would be incompatible.  For another, the way it
works now can be really, really handy sometimes and I'd hate to see us
remove the function!

Charles Mills wrote:
> I'm a coder -- I barely know how to spell catalog -- but there are 
> those of you on this list who have forgotten more about catalogs than 
> I will ever know.
>
> Here's the question. (And like all these things, there is a long story 
> reason why doing things this way seems to make sense.)
>
> SYS1.FOOBAR is a dataset cataloged in the master catalog. It's not 
> "real special" like SYS1.LINKLIB or anything. It's an SMP/E-managed 
> IBM product library. I don't think it is APF-authorized. I think it is 
> linklisted if that makes a difference.
>
> JOEBLOW is an ordinary userid.
>
> Is it possible to create a catalog entry such that JOEBLOW.MY.FOO.BAR 
> is an alias for SYS1.FOOBAR and batch DD references to 
> JOEBLOW.MY.FOO.BAR will actually allocate SYS1.FOOBAR?
>
<snip>

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to