Men are from Mars. Women are from Venus. System programmers are from Earth, where a mature installation with a few decades of history under its belt has to deal with a multitude of HLQs each associated with an application and by implication a business unit, which BTW pays the bills. Our main production master catalog--the one I earlier mentioned that was created in 1983--has over a thousand aliases pointing (thankfully) to a far smaller number of user catalogs. We get by.
Catalogs on Mars or Venus may represent a simpler zoo to manage. One day mankind will get there and become transformed by the vision of what life was like in Eden. Meanwhile, back on the earthly ranch, we deal with things as they are today. I'm not sure in which afterthought of Creation aliases and user catalogs emerged, but thanks to Whomever for the kindness. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: "Joel C. Ewing" <[email protected]> To: [email protected], Date: 06/16/2014 08:20 PM Subject: Re: Catalog manipulation (was RE: DFDSS QUESTION - SEMI URGENT - EXPLANATION) Sent by: IBM Mainframe Discussion List <[email protected]> On 06/16/2014 07:10 PM, Paul Gilmartin wrote: > On Mon, 16 Jun 2014 11:44:53 -0500, Tony's Basement Computer wrote: > >> This brings back memories of a small zOS shop I worked at in the late 90s. >> They routinely built user catalogs whose entire name was 8 characters or >> less, and intentionally happened to match a high level qualifier(s). Their >> reasoning for this practice was that they did not have to define aliases. >> This shop supported a number of retail businesses whose datasets were all >> peculiar to their business, each branch having its own user catalog. When I >> inquired about the why and wherefore the response was "it's too much trouble >> to define an alias." Personally I never thought it was all that tough a >> task. >> > OTOH, what benefit results from using aliases? Aliases seem to introduce > needless complexity. Is the benefit in having fewer user catalogs, but > more aliases in the master catalog? Flexibility, in being able to swap > catalogs simply by redefining their aliases? > > (Drifting somewhat:) I learned (quite recently) that one defines aliases > to VSAM data sets not with the DEFINE ALIAS command, but with DEFINE > PATH. (Why? Emerson?) I believe catalogs are VSAM data sets. So, then, > does one use the DEFINE PATH command to define aliases of catalogs? > (IANASYSPROG. Obviously.) > > -- gil > > There are two types of "aliases": those that map the cataloging of all data sets beginning with a specific, possibly-multi-level prefix to a specific USERCAT; and those that map one specific data set name as an alias for another specific data set name (which must be located in the same user catalog). The DEFINE PATH is only used to set up an alternate data set name for a specific VSAM data set component, some times used when the same data set needs to be referred to by different HLQ's from different systems because of prefix-alias-to-USERCAT conflicts on one of the systems. I suspect VSAM is handled differently because VSAM data sets also existed on DOS/VS which did not have a catalog structure for non-VSAM datasets, but that's just a guess. The DEFINE ALIAS is used for both VSAM and non-VSAM data sets to establish the default USERCAT for cataloging datasets based on HL prefix. The same command is also used to define a full data-set-name alias for a specific non-VSAM data set. It certainly doesn't make sense to go to the overhead of creating a new USERCAT rather than a new alias to an existing USERCAT for each new TSO user -- unless perhaps you have a very small, fairly static number of TSO users. Whether it makes sense to map multiple application HL prefixes to the same USERCAT for other non-TSO-user data sets all depends on your installation DS naming standards and the number of data sets involved. In our case the overhead and complexity of creating and maintaining unique USERCATs for each HL prefix would have been much greater than mapping multiple aliases to one USERCAT and also inappropriate for our recovery requirements. Also having the number of USERCATs being a smaller and relatively stable list made it much easier to be sure we had multiple daily backups and suitable recovery procedures in place for all USERCATs. Renaming components of a VSAM sphere in ways that change the HL prefix cannot recatalog the component into a different USERCAT, so the new prefix would also need to be an ALIAS for the same USERCAT or very confusing things happen. Depending on installation DS renaming requirements, this may also be a strong argument for having multiple ALIAS prefixes mapping to the same USERCAT. I can't conceive of a production environment where you would want USERCAT choice to be left to users or application programmers rather than having it enforced via ALIAS definitions for HLQ(s); otherwise, you inevitably end up with user errors creating "lost" cataloged data sets that can't be found in the expected catalog. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
