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:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Monday, December 18, 2017 4:02 PM
To: IBM-***@LISTSERV.UA.EDU
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
***@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: Monday, December 18, 2017 9:54 AM
To: IBM-***@LISTSERV.UA.EDU
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 <IBM-***@listserv.ua.edu> on behalf of Farley, Peter x23353 <***@BROADRIDGE.COM>
Sent: Saturday, December 16, 2017 1:26 AM
To: IBM-***@listserv.ua.edu
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:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Friday, December 15, 2017 7:16 PM
To: IBM-***@LISTSERV.UA.EDU
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 <IBM-***@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <***@BROADRIDGE.COM>
Sent: Friday, December 15, 2017 2:00 PM
To: IBM-***@LISTSERV.UA.EDU
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:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Friday, December 15, 2017 1:32 PM
To: IBM-***@LISTSERV.UA.EDU
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 <IBM-***@LISTSERV.UA.EDU> on behalf of Jake Anderson <***@GMAIL.COM>
Sent: Friday, December 15, 2017 5:50 AM
To: IBM-***@LISTSERV.UA.EDU
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 ***@listserv.ua.edu 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN