Thank you all. I have decided to just make multiple copies and skip the aliases. I think I was an engineer with a solution in search of a problem.
The killer was symbolic substitution. If I do copies in JCL I can use JCL set symbols in an INCLUDEd member. To use IDCAMS I would have to use system symbols. Modifying system symbols is not out of the question but it was the last nail in the coffin. The following are just idle comments and not really relevant to my original question. > You can't have an alias of an alias I can see the analogy to PDSes. Only members can have aliases; aliases can't have aliases, right? > At job initiation, the initiator ENQs on the alias name. At allocation > it ENQs on the related DSN. If there's an ENQ conflict at that point, > the job terminates with a JCL error That sounds terrible. So you are saying that if a long-running job has an exclusive ENQ on FOO.BAR.ACTUAL, then every job that wants FOO.BAR.ALIAS will take off and run, and then fail at execution time? That sounds like a real step backwards. One of the features of OS/360 was "jobs don't run until all of the resources that they need are available." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, December 10, 2014 5:20 PM To: [email protected] Subject: Re: Dataset alias advice On 2014-12-10 17:48, Charles Mills wrote: > > Question: Does the use of aliases make sense? Let's say HLQ.BAR is > identical across A, B and C. Should I make one HLQ.BAR.COMMON and > alias it as .A, .B and .C? Or is that overkill for a simple one-person > situation? Should I just make three identical PDSes and not over-complicate the problem? > > Disk space is not the issue -- these are relatively small datasets. I > guess it just bothers my engineering desire for elegance to have three > identical datasets when I could have three pointers to one dataset. I > guess "not mucking up the maintenance" -- changing one and failing to > change the others > -- is also a possible concern. > We use aliases with almost an opposite objective: During development, we will build to, e.g., HLQ.Dyymmdd.LINKLIB, then relate alias HLQ.CURRENT.LINKLIB to the newest of those so our testers needn't change JCL members chasing data set names. (I suppose JCL INCLUDE members would work as well, perhaps even better, but that's too innovative for some of us.) Caveats: o The HLQs must be the same, or at least in the same usercat, else catlog lookup will never find the related data set. I think this is an incredibly dumb rule, saving only one lookup in the master catalog, but my colleagues steeped in the MVS culture find it natural. o You can't have an alias of an alias. I think this is an incredibly dumb rule, saving the overhead of recursive lookups in the master catalog, but my colleagues steeped in the MVS culture find it natural. o At job initiation, the initiator ENQs on the alias name. At allocation it ENQs on the related DSN. If there's an ENQ conflict at that point, the job terminates with a JCL error. What else might a simple-minded initiator do. (JES2; I don't know if JES3 behaves otherwise.) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
