Like Skip, we are a financial institution with serious client responsibilities, and we also use a separate-from-development production control group as the only authorized updaters of the main application libraries. AFAIK no auditor has ever complained about our controls or our procedures.
We also use several layers of approvals and reviews for all application code, which provides additional levers and control points to help protect against both accidental and intentional application shenanigans. Shmuel is right to chide me for sounding like I was implying that nothing *could* happen. I did not intend to say or imply that, as I am old and experienced enough to know Murphy all too well in all his various incarnations. I was simply stating that there has not (yet) been any serious incident with our setup and controls as they are. Our ingrained culture of caring seriously and continuously about clients helps keep a person and an organization on their toes. I'm not sure if we use the LNKLST APF feature that Peter Relson mentioned, but I would imagine we do, as I am darn sure that nothing I can do lets me run any authorized code anywhere on z/OS. Our PARMLIB datasets are protected, so I cannot look to see if we use it or not. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jesse 1 Robinson Sent: Monday, December 18, 2017 4:02 PM To: [email protected] Subject: Re: Cobol upgrade 6.2 linklist To clarify my post about putting a consolidated application library in LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that Audit exhortations can be resisted if you don't mind going on the defensive all the way up the flagpole. In our case, this production library contained modules for all major applications. Update access to this library was managed by production control people, a segment of the Operations group. Audit felt that this was better control than allowing production jobs to STEPLIB to anything in the house. Concern in this case was not for mischief performed by AC=1 programs but by devious logic in unauthorized programs. Banks have to so darn careful. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Seymour J Metz Sent: Monday, December 18, 2017 9:54 AM To: [email protected] Subject: (External):Re: Cobol upgrade 6.2 linklist "He jests at scars that never felt a wound." But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Farley, Peter x23353 <[email protected]> Sent: Saturday, December 16, 2017 1:26 AM To: [email protected] Subject: Re: Cobol upgrade 6.2 linklist Some folks have probably been burned by the abuse of user libraries in the LINKLIST and so preach fire and brimstone against it. To others it is just "business as usual" because they have not experienced such abuse or its consequences. I am one of them. As I said, YMMV. Each company is a mini-culture unto itself, and our beliefs and fears are ruled by culture and experience. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 7:16 PM To: [email protected] Subject: Re: Cobol upgrade 6.2 linklist I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a heretic for suggesting that user application libraries be placed in the linklist... ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Farley, Peter x23353 <[email protected]> Sent: Friday, December 15, 2017 2:00 PM To: [email protected] Subject: Re: Cobol upgrade 6.2 linklist Re: #3, that is not necessarily true. Depends heavily on the shop-standard STEPLIB rules (use or don't use production "user library" in STEPLIB's). As long as the "normal" rule is NOT to use production "user library" in STEPLIB's and you choose to use the "two library" approach to migration, putting the PDSE ahead of the PDS in the LINKLIST makes sense and does what you need it to do. As usual, I think it is a case of YMMV depending on your shop's historical STEPLIB rules. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 1:32 PM To: [email protected] Subject: Re: Cobol upgrade 6.2 linklist I am surprised no one yet as asked, is the OP referring to 1) The COBOL compiler library, 2) the COBOL runtime library, or 3) user libraries with COBOL programs. 1) Don't see any real need for this. 2) Probably already done, as the COBOL runtime library is CEE.SCEERUN 3) I've been told that "user libraries" like this should never be in the linklist. ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Jake Anderson <[email protected]> Sent: Friday, December 15, 2017 5:50 AM To: [email protected] Subject: Cobol upgrade 6.2 linklist Hi A general question Do you still cobol load module in linklist post upgrade to 6.2 ? Regards Jake -- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
