Sneaky - but I like it Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 925 738 9443 Corporate Tieline - 89443
If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Eells Sent: Tuesday, August 30, 2016 6:10 AM To: [email protected] Subject: EXTERNAL: 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 [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ________________________________ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
