Hi Dave, I am an old dinosaur and, like you, prefer to isolate non-CPAC datasets in a separate user catalog. Once upon a time, I used different HLQs to permit me to do this AND list LNKLST / LPALST datasets is PARMLIB without a volume reference. Example:
SYSV.** for all ISV datasets except those which must be listed in PARMLIB (catalogued in a UCAT) SYSVL.** for all ISV datasets which must be listed in PARMLIB (catalogued in the MCAT) The only possible arguments that I can think of are: 1) I believe that UCATs are cached by VLF and the MCAT is cached in the CATALOG address space. VLF uses an LRU algorithm to determine what is in storage. The CATALOG address space caches the whole thing (I think). I suppose that an enormous MCAT could lead to paging. Also, I believe that an update to MCAT requires CATALOG to invalidate his entire cache copy and rebuild it. So, there may be performance implications when you've got everything in the MCAT. 2) The advent of MVS system symbols and SYMBOLICRELATE aliases have facilitated having your cake and eating it too. You can keep the ISVs in a UCAT and specify a "volser" in PARMLIB with minimal manual impact. I define a symbol called &SYSL1 which contains the volser of a volume that contains nothing but LNKLST and LPALST datasets related to some IBM product (but not the z/OS CPAC, which installs its LNKLST / LPALST datasets to a res volume). I define another symbol called &SYSL2 which contains the volser of a volume that contains nothing but LNKLST and LPALST datasets related to non-IBM products. When an ISV product is installed into an LPAR, the LNKLST / LPALIB datasets are placed on the volser specified via &SYSL2 and all other target / operational datasets are placed on other volumes. The associated PROGnn or LPALSTnn entries then specify VOLUME(&SYSL2). Multiple levels of any given product are handled by including a VnnRnnMnn qualifier in all DSNs and assigning SYMBOLICRELATE aliases to facilitate references to these DSNs without the level-specific DSN qualifier. Example: IEASYM00 defines &MVRVIEW as 'V01R11M00' SYSV.CAVIEW.V01R11M00.CAILINK is catalogued in a UCAT to VOL(&SYSL2) SYSV.CAVIEW.CAILINK is catalogued in a UCAT as an ALIAS SYMBOLICRELATE(SYSV.CAVIEW.&MVRVIEW..CAILINK) All CLISTs and JCL reference the ALIAS DSN (i.e. without vrl) SMP/E installation / maintenance references the real DSNs PROGnn specifies DSNAME(SYSV.CAVIEW.&MVRVIEW..CAILINK) VOLUME(&SYSL2) Regards, Alan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Gibney, Dave Sent: Monday, June 14, 2010 12:13 To: [email protected] Subject: Linklst; 6 of 1/half dozen of the other? I prefer to have the ISV datasets in LINKLST statements in PROGxx cataloged in the master catalog and not use volume references. My co-worker doesn't think it as a big deal and usually uses a load library cataloged in the ISV usercat and a volume reference. Am I just being anal (I really don't like volume references in parm members anywhere I can avoid them), or is the a legitimate concern that would support either position? We place such datasets on Non-SMS volumes shared between the four LPARS. We do not share master catalogs or in most cases user catalogs. Dave Gibney Information Technology Services Washington State University ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
