There might be a difference between the z/OS and Linux in processing updates to an aliased file. On Linux, if you update any of the file names, the new copy gets a new storage location. The old location goes away when all pointers to it have been updated to new locations. On z/OS, any update gets applied to all copies.
On Thu, Dec 11, 2014 at 3:12 PM, Neil Duffee <[email protected]> wrote: > Caveat: insert Daily Digest delay here... > > Charles: in addition to gil's notes [1], be advised that {any, some} > catalogue changes to .COMMON will lose all the aliases. For example, I have > daily processing to create FDR exclusion commands for all aliases in the > system [2] that are included in *all* my archiving jobs. In the past, when > FDR archived the base dataset, the alias(es) disappeared and were not > re-constructed on recall. (not surprising) I'll gamble that similar stuff > might occur with HSM. So, any process you have that creates .COMMON should > also have the Define Alias commands imbedded with it ie. batch IDCAms. > > If it's for your own use and helps your processes, why not? If something > fails because .A, .B, or .C are missing, you'll be the one to fix it anyway. > (unless you should be re-thinking the use of .A, .B, & .C anyway) > > [1] that I've accidentally deleted already. Oh, yeah, I remember. We, too, > use aliases for versioning of product datasets particularly DB2 loadlibs [3] > which are found in JCL all over the place. > [2] easily done in 30 seconds with FDReport. > [3] which was how I learned about the conflict between aliases and > archiving. The testing/install environments wouldn't use their DB2 loadlibs > for more than 2 years causing migration to occur. That led to DSN Not Found > errors because the aliases disappear as part of the process. > > --------> signature = 6 lines follows <-------- > Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada > telephone:1 613 562 5800 x4585 fax:1 613 562 5161 > mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee > "How *do* you plan for something like that?" Guardian Bob, Reboot > "For every action, there is an equal and opposite criticism." > "Systems Programming: Guilty, until proven innocent" John Norgauer 2004 > > > -----Original Message----- > From: Charles Mills [mailto:[email protected]] > Sent: December 10, 2014 19:49 > Subject: Dataset alias advice > > I've never used dataset aliases. (Well, I'm sure I have; it would probably be > more correct to say "I have never been involved with the administration of > dataset aliases.") > > I have a situation where I am going to have several sets of datasets; one set > each for "situation" A, one for B, one for C, and so forth. So I might have > > HLQ.FOO.A > HLQ.FOO.B > HLQ.FOO.C > etc. > > HLQ.BAR.A > etc. > > In many cases these will be PDSes with multiple members. For *some* of these > sets, the A, B and C PDSes will be the same. I only need the A, B, and C to > make the big picture scheme work. > > These are for my own use, basically -- this is not for an entire datacenter. > > 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? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
