Re: Linklst; 6 of 1/half dozen of the other?
Where can I find the pros and cons of controlling the content of the MC? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, June 26, 2010 10:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Linklst; 6 of 1/half dozen of the other? In 009066fa266f9b428db827deaa3c0e2701a6e...@exchangevs-04.ad.wsu.edu, on 06/14/2010 at 12:13 PM, Gibney, Dave gib...@wsu.edu said: I prefer to have the ISV datasets in LINKLST statements in PROGxx cataloged in the master catalog and not use volume references. And others prefer to keep them out of the MC. 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? There are legitimate reasons for keeping as much as possible out of the MC. Have you considered using static system symbols for the volsers? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, 28 Jun 2010 11:40:35 -0400, Don Williams donb...@gmail.com wrote: Where can I find the pros and cons of controlling the content of the MC? I don't think you'll find what you are looking for (a pros/cons list). It's mostly common sense. There is paragraph in DFSMS Managing Catalogs in the planning a configuration chapter that states this: For ease of backup and recovery of the master catalog, no user data sets should be cataloged in the master catalog. If you deny update access to the master catalog for most of your users, there is typically much less update activity for the master catalog. You might want to have a look at that chapter and the rest of the manual. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
--- On Mon, 6/28/10, Mark Zelden mzel...@flash.net wrote: From: Mark Zelden mzel...@flash.net Subject: Re: Linklst; 6 of 1/half dozen of the other? To: IBM-MAIN@bama.ua.edu Date: Monday, June 28, 2010, 11:19 AM On Mon, 28 Jun 2010 11:40:35 -0400, Don Williams donb...@gmail.com wrote: Where can I find the pros and cons of controlling the content of the MC? I don't think you'll find what you are looking for (a pros/cons list). It's mostly common sense. There is paragraph in DFSMS Managing Catalogs in the planning a configuration chapter that states this: For ease of backup and recovery of the master catalog, no user data sets should be cataloged in the master catalog. If you deny update access to the master catalog for most of your users, there is typically much less update activity for the master catalog. You might want to have a look at that chapter and the rest of the manual. Mark Mark: I will agree with your points. Plus I would add that giving update out to anyone is a way to play russian roulette and you won't feel a thing till the system will not IPL. Also it does not allow users (assuming your RACF is set up correctly) to put things in the MC. Way back when (before RACF) our users had a tendency to name their data sets john.q.accounts.receivables (or some such nonsense). When we had to move the catalog one day we had to clean it up and found lots of old stuff in there. So We first put a password on the master catalog and at least 2-3 a day we saw someone trying to update the catalog. We did not give the operators the password so it always failed. The users we furious but we stuck to our guns and said use the HLQ(s) you have. We stopped migration of any foreign datasets in the catalog after that and the user(s) got the message. We also did this unannounced so we got them good. They finally got the message and stopped doing it. The password is the easiest way. BTW I think we set attempts to 0 so the operator would not get involved. This was before console automation. From then on that is what I did. Others might find it a bit harsh but rules are rules. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
---snip I don't think you'll find what you are looking for (a pros/cons list). It's mostly common sense. There is paragraph in DFSMS Managing Catalogs in the planning a configuration chapter that states this: For ease of backup and recovery of the master catalog, no user data sets should be cataloged in the master catalog. If you deny update access to the master catalog for most of your users, there is typically much less update activity for the master catalog. You might want to have a look at that chapter and the rest of the manual. -unsnip- You also want to limit access to the MC for other reasons. Mainly, you want to prevent some amatuer from doing something that might inadvertantly delete datasets from that catalog. Loss of some datasets from the MC can render your system un-ipl-able, precipitating a disaster scenario maybe. The fewer people that update the MC, whether explicitly or implicitly, the lower your risks of a potentially serious problem, perhaps even a disaster. If you're providing the procs and JCL for use of these OEM products, there's no reason you can't insert a STEPLIB statement. A slight inconvenience is far more bearable that an unplanned outage, possibly of significant duration. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
In 009066fa266f9b428db827deaa3c0e2701a6e...@exchangevs-04.ad.wsu.edu, on 06/14/2010 at 12:13 PM, Gibney, Dave gib...@wsu.edu said: I prefer to have the ISV datasets in LINKLST statements in PROGxx cataloged in the master catalog and not use volume references. And others prefer to keep them out of the MC. 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? There are legitimate reasons for keeping as much as possible out of the MC. Have you considered using static system symbols for the volsers? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, 14 Jun 2010 21:12:54 +, Ted MacNEIL wrote: Keeping versions in files in the link list, or any other PARMLIB members, requires editing with every installed release. It depends upon how you do it. Consider product foobar. The product is installed in ISV.FOOBAR.V3R2M0.LOADLIB, which has an alias of ISV.FOOBAR.LOADLIB. This is defined with SYMBOLICRELATE using system symbol VFOOBAR, which is set to V3R2M0. In PROGxx, the data set is listed as ISV.FOOBAR.VFOOBAR..LOADLIB. No editing of PROGxx is required, nor a change of the alias definition, just a symbol change. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Monday, June 14, 2010 4:13 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Linklst; 6 of 1/half dozen of the other? I agree with you about versions. My manager, OTOH, totally disagrees. So we do it his way. Don't you just hate it when managers make technical decisions? Staff should be smart enough to determine the best way to organise the products. Managers should be smart enough to let staff do their jobs to the best of their abilities, and determine what is the best way to do it. Keeping versions in files in the link list, or any other PARMLIB members, requires editing with every installed release. Great way to introduce finger checks! Actually, my boss is a very good technician. ex-UCCEL developer. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Actually, my boss is a very good technician. ex-UCCEL developer. He should be managing, now. Not micro-managing. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
We have our CICS, DB2 and IMS system datasets residing on Non-SMS volumes that are not cataloged in the master catalog. The datasets are shared among fourteen (14) LPARs without any problems. We are an ISV. On Mon, Jun 14, 2010 at 12:13 PM, Gibney, Dave gib...@wsu.edu wrote: 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Daniel Allen | Serena Software, Inc. | Senior Systems Programmer - Mainframe Services Phone: 1-800-457-3736x11241 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Just to be clear, I know that either technique works perfectly well. I am asking if there is any real argument that one or the other is superior in anyway. Like I said, I might just be excessively anal about the issue. I find volume references (parm, JCL, etc.), anywhere there is a choice not to use them, irritating. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Daniel Allen Sent: Monday, June 14, 2010 12:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Linklst; 6 of 1/half dozen of the other? We have our CICS, DB2 and IMS system datasets residing on Non-SMS volumes that are not cataloged in the master catalog. The datasets are shared among fourteen (14) LPARs without any problems. We are an ISV. On Mon, Jun 14, 2010 at 12:13 PM, Gibney, Dave gib...@wsu.edu wrote: 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Daniel Allen | Serena Software, Inc. | Senior Systems Programmer - Mainframe Services Phone: 1-800-457-3736x11241 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
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:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Monday, June 14, 2010 12:13 To: IBM-MAIN@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Like I said, I might just be excessively anal about the issue. I find volume references (parm, JCL, etc.), anywhere there is a choice not to use them, irritating. If you're anal, then so am I. I prefer things to be found through the catalogue, rather than having to remember, and maintain, where things are. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Either way works. It's more about what you are comfortable with (even if you are OCD/anal). I always felt the trick was to pick one and stick with it and not mix the two. Personally I prefer a unique HLQ for ISV datasets in the mastercat (e.g. SYSX.prodver.*) and non mastercat entries as MVS.prodver.* (for example). Alan, you run with 9 character qualifiers? -Original Message- Starr, Alan 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) Regards, Alan -Original Message- Gibney, Dave 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Personally I prefer a unique HLQ for ISV datasets in the mastercat (e.g. SYSX.prodver.*) and non mastercat entries as MVS.prodver.* (for example). I don't like versions in LNKLST datasets. I have no problem with them in maintenance or steplibs. But, regardless of the HLQ, they should not have versioning in the production environment, IMO. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Monday, June 14, 2010 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Linklst; 6 of 1/half dozen of the other? Personally I prefer a unique HLQ for ISV datasets in the mastercat (e.g. SYSX.prodver.*) and non mastercat entries as MVS.prodver.* (for example). I don't like versions in LNKLST datasets. I have no problem with them in maintenance or steplibs. But, regardless of the HLQ, they should not have versioning in the production environment, IMO. I agree with you about versions. My manager, OTOH, totally disagrees. So we do it his way. And we put the OEM products in the LNKLST so that the version numbers are hidden from the users. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, Jun 14, 2010 at 4:04 PM, McKown, John john.mck...@healthmarkets.com wrote: I don't like versions in LNKLST datasets. I have no problem with them in maintenance or steplibs. But, regardless of the HLQ, they should not have versioning in the production environment, IMO. I agree with you about versions. My manager, OTOH, totally disagrees. So we do it his way. And we put the OEM products in the LNKLST so that the version numbers are hidden from the users. It is mostly a religious issue, but for some products there are practical considerations. If you have (for example) something that starts really early during IPL processing you have a fairly limited set of choices. Now in fairness, there aren't too many such products, but it always pays to read the fine print. Every once in a while when the vendor says they need it to be a particular way they're right and a one size fits all approach will lead to tears. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
I agree with you about versions. My manager, OTOH, totally disagrees. So we do it his way. Don't you just hate it when managers make technical decisions? Staff should be smart enough to determine the best way to organise the products. Managers should be smart enough to let staff do their jobs to the best of their abilities, and determine what is the best way to do it. Keeping versions in files in the link list, or any other PARMLIB members, requires editing with every installed release. Great way to introduce finger checks! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
It is mostly a religious issue, but for some products there are practical considerations. I don't see it as 'religious'; just less editing of PARMLIB. I'm curious. Can you give an example of when the version should be included in the LNKLST? Or, am I reading too much into 'practical considerations'? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Actually our naming conventions are Production MVS.prod.*(.lpar) SYSX.prod.*(.lpar) (.lpar) if I need LPAR specific datasets Install/TestMVS.prodVnnn.* SYSX.prodV99.* which is a linklisted copy of a MVS.prodVnnn.* load although I could realistically use SYSX.prod.*.lpar for the sandbox Assuming the datasets are made large enough I never have to change linklist/lpalist or JCL/PROCs for production and only occasionally JCL/PROCs for testing -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Monday, June 14, 2010 4:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Linklst; 6 of 1/half dozen of the other? Personally I prefer a unique HLQ for ISV datasets in the mastercat (e.g. SYSX.prodver.*) and non mastercat entries as MVS.prodver.* (for example). I don't like versions in LNKLST datasets. I have no problem with them in maintenance or steplibs. But, regardless of the HLQ, they should not have versioning in the production environment, IMO. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
From: Starr, Alan alan_st...@calpers.ca.gov To: IBM-MAIN@bama.ua.edu Sent: Mon, June 14, 2010 2:42:35 PM Subject: Re: Linklst; 6 of 1/half dozen of the other? Hi Dave, ---SNIP I am against having any vendors library in the linklist (unless it MUST be). I would rather have people steplib to a dataset that contains the current version. Yes it may be extra work on the security side but if you have good conventions for names it does work well. The main reason is that I have run into vendors that use the same module name and it causes too much loss time trying to figure out what is going on. Nowdays it isn't too much of an issue but I have seen it occur. It would be great if vendors would agree on prefix's for module name but there is little chance of their even willing to agree to anything. My mind is blank at the moment as to which vendors I have run into with but it does occur. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Monday, June 14, 2010 2:24 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Linklst; 6 of 1/half dozen of the other? Hi Dave, ---SNIP I am against having any vendors library in the linklist (unless it MUST be). Current product in question is FDRABR. He has also done Syncsort like this. Both are needed early in the IPL and if there is a way to avoid link/lpa listing them, I don't know it. In many cases, I do prefer ISV in the system search concatentation, I don't like messing with large scale JCL search and change projects. If a product is not widely used, I prefer using a PROC to avoid widespread dataset references. I would rather have people steplib to a dataset that contains the current version. Yes it may be extra work on the security side but if you have good conventions for names it does work well. The main reason is that I have run into vendors that use the same module name and it causes too much loss time trying to figure out what is going on. Nowdays it isn't too much of an issue but I have seen it occur. It would be great if vendors would agree on prefix's for module name but there is little chance of their even willing to agree to anything Today, none of my ISV or IBM overlap module names (except MIGLIB and some LPALIB and LINKLIB/LINKLIBE) My mind is blank at the moment as to which vendors I have run into with but it does occur. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, 14 Jun 2010 14:34:25 -0700, Gibney, Dave wrote: Current product in question is FDRABR. He has also done Syncsort like this. Both are needed early in the IPL and if there is a way to avoid link/lpa listing them, I don't know it. In many cases, I do prefer ISV in the system search concatentation, I don't like messing with large scale JCL search and change projects. Would aliases help here? If a product is not widely used, I prefer using a PROC to avoid widespread dataset references. Yah, but you know users; they'll circumvent; copy the PROC to edit it, etc. I would rather have people steplib to a dataset that contains the current version. Yes it may be extra work on the security side but if you have good conventions for names it does work well. The main reason is that I have run into vendors that use the same module name and it causes too much loss time trying to figure out what Of course, STEPLIB is no solution if a single job step must ATTACH programs from both vendors. TASKLIB? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, June 14, 2010 2:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Linklst; 6 of 1/half dozen of the other? On Mon, 14 Jun 2010 14:34:25 -0700, Gibney, Dave wrote: Current product in question is FDRABR. He has also done Syncsort like this. Both are needed early in the IPL and if there is a way to avoid link/lpa listing them, I don't know it. In many cases, I do prefer ISV in the system search concatentation, I don't like messing with large scale JCL search and change projects. Would aliases help here? I've tried to promote fully qualified aliases to have a static name in the JCL and other places while supporting versioning in the actual dataset name. It's been successful with a different set of products/co-worker, but he recently took a job elsewhere. The alias concept seems to be more confusing to the remaining folks. :( The guy who left was the boss, right now we have no real authority (boss) I can appeal to correct my irritation with the other guy. And politically I can't really assert arbitrary direction on my own yet. If a product is not widely used, I prefer using a PROC to avoid widespread dataset references. Yah, but you know users; they'll circumvent; copy the PROC to edit it, etc. I would rather have people steplib to a dataset that contains the current version. Yes it may be extra work on the security side but if you have good conventions for names it does work well. The main reason is that I have run into vendors that use the same module name and it causes too much loss time trying to figure out what Of course, STEPLIB is no solution if a single job step must ATTACH programs from both vendors. TASKLIB? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, 14 Jun 2010 15:44:58 -0700, Gibney, Dave wrote: I've tried to promote fully qualified aliases to have a static name in the JCL and other places while supporting versioning in the actual dataset name. It's been successful with a different set of products/co-worker, but he recently took a job elsewhere. The alias concept seems to be more confusing to the remaining folks. :( There's much one could do with SET symbols in JCLLIB INCLUDE members. But one immediately wishes for longer set symbol names, such as: // SET ISV1$PAST$LINKLIB='...', // ISV1$CURRENT$LINKLIB='...', // ISV1$CURRENT$MACLIB='...', // ISV1$FUTURE$LINKLIB='...' ... etc. Would file tailoring help? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[Fwd: Re: Linklst; 6 of 1/half dozen of the other?]
-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---BeginMessage--- On Mon, 2010-06-14 at 18:46 -0500, Paul Gilmartin wrote: On Mon, 14 Jun 2010 15:44:58 -0700, Gibney, Dave wrote: I've tried to promote fully qualified aliases to have a static name in the JCL and other places while supporting versioning in the actual dataset name. It's been successful with a different set of products/co-worker, but he recently took a job elsewhere. The alias concept seems to be more confusing to the remaining folks. :( There's much one could do with SET symbols in JCLLIB INCLUDE members. But one immediately wishes for longer set symbol names, such as: // SET ISV1$PAST$LINKLIB='...', // ISV1$CURRENT$LINKLIB='...', // ISV1$CURRENT$MACLIB='...', // ISV1$FUTURE$LINKLIB='...' ... etc. Would file tailoring help? -- gil What I suggested was using ALIASes. Real DSN would be SYS3.product.version.LINKLIB . There would be SYS3.product.PROD.LINKLIB as an ALIAS to that. SYS3.product.PREV.LINKLIB pointing to the current or previous version. And SYS3.product.NEW.LINKLIB pointing to either the current or test version of the product. Everybody else thought it was stupid. And too much of a bother to maintain. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---End Message---
Re: Linklst; 6 of 1/half dozen of the other?
---snip--- 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. unsnip-- Dave, I'm partial to the PROGxx method. Makes it far easier to fall back if a serious problem is discovered at lunchtime, instead of an IPL. And by sticking to a single source, there's less chance of a mistake in library ordering, etc. YMMV (I switched to the PROGxx mechanism as soon as it was available and never looked back! Saved my b*tt several times.) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, 14 Jun 2010 12:13:04 -0700, Gibney, Dave gib...@wsu.edu wrote: 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. How did this discussion turn into a to lnklst or not to lnklst discussion? My client used to have a separate HLQ just for ISV lnklst data sets so they can be in the master catalog. But this sort of thing goes way back to the days when you couldn't code a volser. I think it wasn't until OS/390 1.3 where you could finally add a volser to LPALSTxx. The standard at my client (that I happen to like BTW) is to put everything we can in the LNKLST to shield users and even us from (possible) future JCL changes. That even allows using version numbers if preferred, but we don't since we indirectly catalog them to a secondary ISV sysres and we implement maintenance / upgrades via rolling IPLs. No LNKLST changes, no JCL changes. There are very few exceptions, but I'm sure there is an STC or 2 that use a STEPLIB and that library is not in the LNKLST. Back to the original question.I think the recommendation has always been to put as little in the master catalog as possible. That is why my client (and other shops I've been at) had a special HLQ for the LNKLST. For example, if the ISV HLQ was SYS2, they used a HLQ of SYSL just for the LNKLST / LPALST required data sets.But IBM has not required those data sets in the MCAT for a very long time, so we can have them follow the same standard as the rest of the product HLQs and keep them out of the master catalog. People don't build new MCATs for each release like they used to (in general, I know that some shops still do), so that isn't as much as a consideration as it used to be, but I still prefer to just keep the IBM sysres and OS data sets in there that must be. The only downside is needing to change volsers in PROGxx or LPALSTxx if the data sets are moved to another volume. In most shops, unlikely without you knowing since the LNKLST dsns are ENQed. Much more possible with LPALSTxx data sets. At my client it isn't a problem since the ISV products are on a secondary sysres and cataloged with symbolics as I mentioned earlier. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
