OK, confusion in my own post.

'OSR21.SYS1.LINKLIB' is an alias in mcat pointing to maintenance ucat
'OSR21.SYS1.LINKLIB' is also an alias in maintenance ucat pointing to nvsam 
'SYS1.LINKLIB' in the same ucat with volser R21MNT, i.e. not the IPL volume

So the alias and true nvsam entries get resolved in the same catalog. In OP's 
case, 'SYS1.FOOBAR' is (must be?) in mcat, while the user-level alias is (must 
be?) the standard ucat for that HLQ. I don't think it can work. 


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
[email protected]


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, August 29, 2016 4:43 PM
To: [email protected]
Subject: (External):Re: Elementary dataset alias question

I think Gil's explanation covers my experiment. The alias 'TSOSKIP.xxx' lives 
in the master catalog although I can't explain why. If catalog search then 
tries to find the 'related' entry in the usual way, it will go the user catalog 
for HLQ TSOSKIP and not find 'SYS1.FOOBAR' there. We make extensive use of 
aliases here for z/OS maintenance:

'OSR21.SYS1.LINKLIB' in the master catalog --> 'SYS1.LINKLIB' in 
'MVSR21.ICF.MASTER', the SMPE maintenance catalog. That is, 'SYS1.LINKLIB' is 
found in the same catalog as the alias. In the FOOBAR case, the alias and the 
true entry are--must be--in separate catalogs. Doomed to fail. 

I did not try SYMBOLICRELATE. Too many letters. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
[email protected]


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Charles Mills
Sent: Monday, August 29, 2016 4:28 PM
To: [email protected]
Subject: (External):Re: Elementary dataset alias question

Oh no! My panel of experts disagrees.

> unless you tell it which user cat to look in, which largely negates my 
> purpose

Tell it when? A "batch JCL" time? Then yes, that largely negates the purpose. 
Or at "define the alias" time? Something like DEFINE ALIAS ... CATALOG(MASTER). 
That would be okay.

I just want a batch job to be able to say //STEPLIB DD 
DISP=SHR,DSN=JOEBLOW.MY.FOO.BAR and have it load programs from SYS1.FOOBAR. 
Isn't that what aliases are for? I guess you are saying "aliases are not 
system-wide -- they are intra-catalog aliases." Okay, well I guess I am 
learning something about catalogs.

What about @Lizette's SYMBOLICRELATE? Will that bridge catalog to catalog?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Paul Gilmartin
Sent: Monday, August 29, 2016 3:55 PM
To: [email protected]
Subject: Re: Elementary dataset alias question

On Mon, 29 Aug 2016 15:34:59 -0700, Charles Mills wrote:
>
>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?
> 
No.  Well, only if JOEBLOW and SYS1 identify the same user catalog, which is 
vanishingly unlikely.  Catalog always searches for the RELATED DSN in the same 
catalog in which it found the alias.  Well, unless you tell it which user cat 
to look in, which largely negates my purpose, and probably yours, for wanting 
an ALIAS

I have whined bitterly about this in these pages.  It seems to me that once 
catalog has found the ALIAS which identifies the RELATED it should begin the 
search anew to find the RELATED.

People who claim to know more about this than I say that if that were done you 
wouldn't be able to IPL, or spacetime would collapse into a black hole, or 
something.  I firmly believe that's only because it's done wrong.

BTW, why is an alias for a non-VSAM data set called ALIAS but an alias for a 
VSAM data set is called PATH?  It seems to me they should be interchangable.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to