Discussion:
Cobol upgrade 6.2 linklist
(too old to reply)
Jake Anderson
2017-12-15 12:49:40 UTC
Permalink
Raw Message
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
Mike Schwab
2017-12-15 17:32:58 UTC
Permalink
Raw Message
Cobol 5+ objects must be in PDSE. Some early IPL functions can't
list a PDSE. Only restriction.
Post by Jake Anderson
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,
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-12-15 17:46:38 UTC
Permalink
Raw Message
As you will find out. Any Cobol program compiled from the Cobol Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.

If you have your application batch load library in the LINKLST then you will need to move it into the place where you start other PDS/E Dataset in the Linklst.

The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not have the SMSPDSx ASID available at the time the LINKLST is done. You have to build it after the SMSPDSx STC is up

Lizette
-----Original Message-----
Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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
Jousma, David
2017-12-15 18:10:35 UTC
Permalink
Raw Message
Are you sure you aren’t thinking of LPALSTxx? There are quite a few IBM supplied PDSE in linklist. SIEALNKE, SIEAMIGE, SHASLNKE....

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Friday, December 15, 2017 12:48 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

As you will find out. Any Cobol program compiled from the Cobol Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.

If you have your application batch load library in the LINKLST then you will need to move it into the place where you start other PDS/E Dataset in the Linklst.

The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not have the SMSPDSx ASID available at the time the LINKLST is done. You have to build it after the SMSPDSx STC is up

Lizette
-----Original Message-----
On Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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 **CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
2017-12-15 18:14:00 UTC
Permalink
Raw Message
Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never knew about the linklist restrictions with PDS/E , so what about IBM libraries in the linklist from my serverpac build?
alway had in CPAC.PARMLIB and migrated forward.....


SYS1.SHASLNKE



SYS1.SIEALNKE


SYS1.SIEAMIGE....etc
am I taking unnecessary chances?



Carmen Vitullo

----- Original Message -----

From: "Lizette Koehler" <***@MINDSPRING.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Friday, December 15, 2017 11:47:57 AM
Subject: Re: Cobol upgrade 6.2 linklist

As you will find out. Any Cobol program compiled from the Cobol Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.

If you have your application batch load library in the LINKLST then you will need to move it into the place where you start other PDS/E Dataset in the Linklst.

The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not have the SMSPDSx ASID available at the time the LINKLST is done. You have to build it after the SMSPDSx STC is up

Lizette
-----Original Message-----
Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2017-12-18 18:15:47 UTC
Permalink
Raw Message
It used to be that you couldn't have PDSE in LNKLSTxx, but could add a PDSE with an automatic SETPROG command. I don't know whether that restriction still exists.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Carmen Vitullo <***@HUGHES.NET>
Sent: Friday, December 15, 2017 1:15 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist

Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never knew about the linklist restrictions with PDS/E , so what about IBM libraries in the linklist from my serverpac build?
alway had in CPAC.PARMLIB and migrated forward.....


SYS1.SHASLNKE



SYS1.SIEALNKE


SYS1.SIEAMIGE....etc
am I taking unnecessary chances?



Carmen Vitullo

----- Original Message -----

From: "Lizette Koehler" <***@MINDSPRING.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Friday, December 15, 2017 11:47:57 AM
Subject: Re: Cobol upgrade 6.2 linklist

As you will find out. Any Cobol program compiled from the Cobol Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.

If you have your application batch load library in the LINKLST then you will need to move it into the place where you start other PDS/E Dataset in the Linklst.

The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not have the SMSPDSx ASID available at the time the LINKLST is done. You have to build it after the SMSPDSx STC is up

Lizette
-----Original Message-----
Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jerry Whitteridge
2017-12-18 18:20:46 UTC
Permalink
Raw Message
The issue with PDSE in the linklist is related to any PDSE that is in the
IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to
do dynamic maintenance to a product you can take the existing library out
of the linklist, but can't rename etc. You would then need to use a new
Library name to put the product back into linklist.

If you are not in the habit of doing dynamic maintenance the PDSE in the
IPL linklist isn't an issue, and if you can use different names it's also
not an issue.


--
Jerry Whitteridge

IBM Global Services
Delivery Manager
e-Mail: ***@ibm.com
Cell: 602 527 4871 <---- Note New Phone Number
Date: 12/18/2017 11:17 AM
Subject: Re: Cobol upgrade 6.2 linklist
It used to be that you couldn't have PDSE in LNKLSTxx, but could add
a PDSE with an automatic SETPROG command. I don't know whether that
restriction still exists.
--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?
u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx-
siA1ZOg&r=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E&m=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo&s=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64&e=
________________________________________
Sent: Friday, December 15, 2017 1:15 PM
Subject: Re: Cobol upgrade 6.2 linklist
Hum , I know COBOL object modules 5+ need to be PDS/E, but I've
never knew about the linklist restrictions with PDS/E , so what
about IBM libraries in the linklist from my serverpac build?
alway had in CPAC.PARMLIB and migrated forward.....
SYS1.SHASLNKE
SYS1.SIEALNKE
SYS1.SIEAMIGE....etc
am I taking unnecessary chances?
Carmen Vitullo
----- Original Message -----
Sent: Friday, December 15, 2017 11:47:57 AM
Subject: Re: Cobol upgrade 6.2 linklist
As you will find out. Any Cobol program compiled from the Cobol
Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.
If you have your application batch load library in the LINKLST then
you will need to move it into the place where you start other PDS/E
Dataset in the Linklst.
The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do
not have the SMSPDSx ASID available at the time the LINKLST is done.
You have to build it after the SMSPDSx STC is up
Lizette
-----Original Message-----
Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
2017-12-18 18:36:03 UTC
Permalink
Raw Message
I see your points, for me, it's never been in a habit of upgrading any target lib's that are linklisted, did that once with some older XX products (PDS) that didn't act well after trying dynamically refreshing LLA and the linklist, so I've built my linklist lib's from my target libs, and IPL most times.


Carmen Vitullo

----- Original Message -----

From: "Jerry Whitteridge" <***@IBM.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, December 18, 2017 12:21:55 PM
Subject: Re: Cobol upgrade 6.2 linklist

The issue with PDSE in the linklist is related to any PDSE that is in the
IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to
do dynamic maintenance to a product you can take the existing library out
of the linklist, but can't rename etc. You would then need to use a new
Library name to put the product back into linklist.

If you are not in the habit of doing dynamic maintenance the PDSE in the
IPL linklist isn't an issue, and if you can use different names it's also
not an issue.
--
Jerry Whitteridge

IBM Global Services
Delivery Manager
e-Mail: ***@ibm.com
Cell: 602 527 4871 <---- Note New Phone Number
Date: 12/18/2017 11:17 AM
Subject: Re: Cobol upgrade 6.2 linklist
It used to be that you couldn't have PDSE in LNKLSTxx, but could add
a PDSE with an automatic SETPROG command. I don't know whether that
restriction still exists.
--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?
u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx-
siA1ZOg&r=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E&m=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo&s=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64&e=
________________________________________
Sent: Friday, December 15, 2017 1:15 PM
Subject: Re: Cobol upgrade 6.2 linklist
Hum , I know COBOL object modules 5+ need to be PDS/E, but I've
never knew about the linklist restrictions with PDS/E , so what
about IBM libraries in the linklist from my serverpac build?
alway had in CPAC.PARMLIB and migrated forward.....
SYS1.SHASLNKE
SYS1.SIEALNKE
SYS1.SIEAMIGE....etc
am I taking unnecessary chances?
Carmen Vitullo
----- Original Message -----
Sent: Friday, December 15, 2017 11:47:57 AM
Subject: Re: Cobol upgrade 6.2 linklist
As you will find out. Any Cobol program compiled from the Cobol
Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.
If you have your application batch load library in the LINKLST then
you will need to move it into the place where you start other PDS/E
Dataset in the Linklst.
The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do
not have the SMSPDSx ASID available at the time the LINKLST is done.
You have to build it after the SMSPDSx STC is up
Lizette
-----Original Message-----
Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-12-15 18:30:38 UTC
Permalink
Raw Message
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-12-15 20:59:23 UTC
Permalink
Raw Message
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

EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

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
--


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
Frank Swarbrick
2017-12-16 00:15:09 UTC
Permalink
Raw Message
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

EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

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
--


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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-12-16 06:25:27 UTC
Permalink
Raw Message
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
--

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
Jesse 1 Robinson
2017-12-16 17:35:56 UTC
Permalink
Raw Message
At a previous shop, auditors pressed us to include the main (consolidated) application load library in LINKLIST. Their argument was that LINKLIST was a known commodity, while STEPLIB could point anywhere at any time. Nothing to do with performance.

.
.
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 Farley, Peter x23353
Sent: Friday, December 15, 2017 10:27 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):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
Seymour J Metz
2017-12-17 16:56:47 UTC
Permalink
Raw Message
ObAllanShermanGoodAdvice Getting technical advice from auditors is usually Russian Roulette; when the balloon goes up, you'll be the one taking the heat. Any chance of asking for an auditor who understands MVS, or at least knows what he doesn't know?

The truth is that a qualified security auditor would flag you one several counts if you did as your current auditor suggests.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Jesse 1 Robinson <***@SCE.COM>
Sent: Saturday, December 16, 2017 12:37 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist

At a previous shop, auditors pressed us to include the main (consolidated) application load library in LINKLIST. Their argument was that LINKLIST was a known commodity, while STEPLIB could point anywhere at any time. Nothing to do with performance.

.
.
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 Farley, Peter x23353
Sent: Friday, December 15, 2017 10:27 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-12-17 16:06:47 UTC
Permalink
Raw Message
<various snips>
auditors pressed us to include the main (consolidated) application load
library in LINKLIST. Their argument was that LINKLIST was a known
commodity

I've been told that "user libraries" like this should never be in the
linklist.

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...
</snips>

One might say that it is never appropriate to put something like this into
the LNKLST unless running with LNKAUTH=APFTAB, in the name of system
integrity.
Otherwise, when accessed through the LNKLST the modules are treated as
APF-authorized, and the modules within such a library might well not have
been "blessed" as conforming to the integrity requirements of such an
environment. We almost always find integrity flaws in code that was
written for an unauthorized environment that then gets moved unchanged (or
at least unexamined) to an authorized environment.

If an auditor "pressed", then (if not also insisting on LNKAUTH=APFTAB),
that auditor most likely was wrong.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-12-18 06:19:14 UTC
Permalink
Raw Message
Post by Peter Relson
If an auditor "pressed", then (if not also insisting on LNKAUTH=APFTAB),
that auditor most likely was wrong.


IMHO, those auditors were wrong. Full stop. Auditors should investigate, document, and suggest. Auditors should never be allowed to force something.


--
Peter Hunkeler




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-12-18 13:33:57 UTC
Permalink
Raw Message
Post by Peter Relson
Post by Peter Relson
If an auditor "pressed", then (if not also insisting on LNKAUTH=APFTAB),
that auditor most likely was wrong.
IMHO, those auditors were wrong. Full stop. Auditors should investigate,
document, and suggest. Auditors should never be allowed to force something.
​I'm no longer allowed around auditors. I have two problems. The first is
that I tell them the absolute truth, as best as I know it. The second is
that I tell them to shove off if they start pestering me to "get this done
now, I demand you drop everything to do this for me."​
Post by Peter Relson
--
Peter Hunkeler
--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-12-18 21:00:48 UTC
Permalink
Raw Message
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
Farley, Peter x23353
2017-12-18 22:11:34 UTC
Permalink
Raw Message
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
Clark Morris
2017-12-19 02:39:33 UTC
Permalink
Raw Message
[Default] On 18 Dec 2017 14:11:34 -0800, in bit.listserv.ibm-main
Post by Farley, Peter x23353
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.
Do those levels of control encourage people to move applications to
other platforms or the cloud?

Clark Morris
Post by Farley, Peter x23353
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-----
Sent: Monday, December 18, 2017 4:02 PM
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
-----Original Message-----
Sent: Monday, December 18, 2017 9:54 AM
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
________________________________________
Sent: Saturday, December 16, 2017 1:26 AM
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-----
Sent: Friday, December 15, 2017 7:16 PM
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...
________________________________
Sent: Friday, December 15, 2017 2:00 PM
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-----
Sent: Friday, December 15, 2017 1:32 PM
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.
________________________________
Sent: Friday, December 15, 2017 5:50 AM
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
R.S.
2017-12-19 13:07:13 UTC
Permalink
Raw Message
What is the risk of putting COBOL-compiled code into LINKLIST?
Let's assume LNKAUTH=LNKLST.
Such code will not perform any authorized instructions. It can be called
from another AC=1 code, but the problem is the module, not the COBOL
code called.
What I'm missing?
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-12-19 19:10:54 UTC
Permalink
Raw Message
So, my opinion

Once a dataset is in the linkst - depending on how it is controlled - someone could put other code in there that is not system friendly.

So I have dataset, MYHLQ.USER.LOADLIB in the linklist.

Now it is apf authorized.

I use a package like Changemen to deploy to it, but it does not know what should not go there. I use all valid naming conventions for the process. But the code could be something "special".

So USERA decides to create a program with an assembler subroutine that can filter data in a database and send to an unknown site.

Or set up other issues in the system. USERA has the authority to deploy to that dataset. But who is controlling the source to ensure it does not do bad things.


Just my thought

Lizette
-----Original Message-----
Behalf Of R.S.
Sent: Tuesday, December 19, 2017 6:08 AM
Subject: Re: Cobol upgrade 6.2 linklist
What is the risk of putting COBOL-compiled code into LINKLIST?
Let's assume LNKAUTH=LNKLST.
Such code will not perform any authorized instructions. It can be called from
another AC=1 code, but the problem is the module, not the COBOL code called.
What I'm missing?
--
Radoslaw Skorupka
Lodz, Poland
NFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-12-19 20:15:25 UTC
Permalink
Raw Message
Peer review is a powerful tool for protection from this kind of abuse. Technically competent managers who can read and understand code (even if they don't actually do it any more) are another level that can be added. Senior-level technical code reviewers is another possible level of protection.

Where I work we use several of those protective mechanisms. I have been particularly grateful for peer review that saved me from embarrassing mistakes more than once.

If you fear abuse you must allocate the resources to help prevent it. TAANSTAFL

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, December 19, 2017 2:12 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Cobol upgrade 6.2 linklist

So, my opinion

Once a dataset is in the linkst - depending on how it is controlled - someone could put other code in there that is not system friendly.

So I have dataset, MYHLQ.USER.LOADLIB in the linklist.

Now it is apf authorized.

I use a package like Changemen to deploy to it, but it does not know what should not go there. I use all valid naming conventions for the process. But the code could be something "special".

So USERA decides to create a program with an assembler subroutine that can filter data in a database and send to an unknown site.

Or set up other issues in the system. USERA has the authority to deploy to that dataset. But who is controlling the source to ensure it does not do bad things.


Just my thought

Lizette
-----Original Message-----
Behalf Of R.S.
Sent: Tuesday, December 19, 2017 6:08 AM
Subject: Re: Cobol upgrade 6.2 linklist
What is the risk of putting COBOL-compiled code into LINKLIST?
Let's assume LNKAUTH=LNKLST.
Such code will not perform any authorized instructions. It can be called from
another AC=1 code, but the problem is the module, not the COBOL code called.
What I'm missing?
--
Radoslaw Skorupka
Lodz, Poland
--


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
Joel C. Ewing
2017-12-19 20:23:52 UTC
Permalink
Raw Message
Lets NOT assume LNKAUTH=LNKLST! 

There are good reasons for putting data sets that do not need to
APF-authorization into the LNKLST.  I would think that now days it would
be regarded as a bad practice to specify anything other than
LNKAUTH=APFTAB and explicitly APF-authorize only those LNKLST data sets
that really should be authorized.  A loadlib that is not intended to be
authorized might contain modules that would be unsafe to load into an
environment running APF-authorized code.

That being said, control of the LNKAUTH parameter, the APF Table, adding
data sets to the Link List, and control of the contents of any data set
that is APF-authorized must be restricted to Sys Progs that can be
trusted and who understand system security issues or your system
integrity is non-existent.

No MVS Sys Prog worthy of the name would allow any data set to acquire
APF status, either by explicit addition to the  APF Table or implicitly
by addition to LNKLST where LNKAUTH=LNKLST is in effect, without first
insuring that update authority to that data set is restricted only to
qualified Sys Progs.

A corollary to that is that no data set with a HLQ that implies
ownership by an individual user or a user group, rather than ownership
by the MVS system or by other vendor products maintained by Sys Progs,
should EVER be allowed to become APF-authorized, because the DS name
could cause a RACF administrator to incorrectly assume it was OK to
allow non-SysProgs to have update access.

So, an arbitrary USERA who is  not a qualified Sys Prog, should never
find himself with UPDATE access to a LOADLIB that is APF-authorized. Period!

I'm not familiar with Changeman, but if it is a product that allows one
to indirectly deploy modules to a LOADLIB to which one lacks direct
UPDATE access, that product cannot be configured to permit or enabled to
allow any updates to an APF-authorized library to be introduced by a
non-SysProg.  If there is no way to disable that capability, the product
is unsafe.
    Joel C Ewing
Post by Lizette Koehler
So, my opinion
Once a dataset is in the linkst - depending on how it is controlled - someone could put other code in there that is not system friendly.
So I have dataset, MYHLQ.USER.LOADLIB in the linklist.
Now it is apf authorized.
I use a package like Changemen to deploy to it, but it does not know what should not go there. I use all valid naming conventions for the process. But the code could be something "special".
So USERA decides to create a program with an assembler subroutine that can filter data in a database and send to an unknown site.
Or set up other issues in the system. USERA has the authority to deploy to that dataset. But who is controlling the source to ensure it does not do bad things.
Just my thought
Lizette
-----Original Message-----
Behalf Of R.S.
Sent: Tuesday, December 19, 2017 6:08 AM
Subject: Re: Cobol upgrade 6.2 linklist
What is the risk of putting COBOL-compiled code into LINKLIST?
Let's assume LNKAUTH=LNKLST.
Such code will not perform any authorized instructions. It can be called from
another AC=1 code, but the problem is the module, not the COBOL code called.
What I'm missing?
--
Radoslaw Skorupka
Lodz, Poland
--
Joel C. Ewing, Bentonville, AR ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2017-12-19 20:11:05 UTC
Permalink
Raw Message
That's a false dichotomy. A dataset used as a steplib is no different than any other dataset; you should protect it with appropriate security rules. Developers should not have access to datasets used by production jobs unless the production control groups has determined that there is no risk of data compromise or loss.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Jesse 1 Robinson <***@SCE.COM>
Sent: Monday, December 18, 2017 4:01 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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-12-19 03:41:48 UTC
Permalink
Raw Message
We steer away from dynamic linklist update as well. When Omegamon could do it decades ago, I chided IBM for lagging behind. Nowadays I have a different perspective: not how to move forward, but how to move back in case of unexpected trouble. So we invariably create a new library and IPL with it. In case of (possible but unlikely) chaos, we IPL back the old library. Whatever the original problem was, it could hardly be worse than getting stuck in a hot mess purgatory with no clear exit.

.
.
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 Carmen Vitullo
Sent: Monday, December 18, 2017 10:37 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Cobol upgrade 6.2 linklist

I see your points, for me, it's never been in a habit of upgrading any target lib's that are linklisted, did that once with some older XX products (PDS) that didn't act well after trying dynamically refreshing LLA and the linklist, so I've built my linklist lib's from my target libs, and IPL most times.


Carmen Vitullo

----- Original Message -----

From: "Jerry Whitteridge" <***@IBM.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, December 18, 2017 12:21:55 PM
Subject: Re: Cobol upgrade 6.2 linklist

The issue with PDSE in the linklist is related to any PDSE that is in the IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to do dynamic maintenance to a product you can take the existing library out of the linklist, but can't rename etc. You would then need to use a new Library name to put the product back into linklist.

If you are not in the habit of doing dynamic maintenance the PDSE in the IPL linklist isn't an issue, and if you can use different names it's also not an issue.


--
Jerry Whitteridge

IBM Global Services
Delivery Manager
e-Mail: ***@ibm.com
Cell: 602 527 4871 <---- Note New Phone Number
Date: 12/18/2017 11:17 AM
Subject: Re: Cobol upgrade 6.2 linklist Sent by: IBM Mainframe
It used to be that you couldn't have PDSE in LNKLSTxx, but could add a
PDSE with an automatic SETPROG command. I don't know whether that
restriction still exists.
--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?
u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx-
siA1ZOg&r=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E&m=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo&s=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64&e=
________________________________________
Sent: Friday, December 15, 2017 1:15 PM
Subject: Re: Cobol upgrade 6.2 linklist
Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never
knew about the linklist restrictions with PDS/E , so what about IBM
libraries in the linklist from my serverpac build?
alway had in CPAC.PARMLIB and migrated forward.....
SYS1.SHASLNKE
SYS1.SIEALNKE
SYS1.SIEAMIGE....etc
am I taking unnecessary chances?
Carmen Vitullo
----- Original Message -----
Sent: Friday, December 15, 2017 11:47:57 AM
Subject: Re: Cobol upgrade 6.2 linklist
As you will find out. Any Cobol program compiled from the Cobol
Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD.
If you have your application batch load library in the LINKLST then
you will need to move it into the place where you start other PDS/E
Dataset in the Linklst.
The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not
have the SMSPDSx ASID available at the time the LINKLST is done.
You have to build it after the SMSPDSx STC is up
Lizette
-----Original Message-----
From: IBM Mainframe Discussion List
On
Behalf Of Jake Anderson
Sent: Friday, December 15, 2017 5:51 AM
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
Tom Marchant
2017-12-19 19:57:47 UTC
Permalink
Raw Message
Post by Lizette Koehler
Once a dataset is in the linkst - depending on how it is controlled - someone could put other code in there that is not system friendly.
So I have dataset, MYHLQ.USER.LOADLIB in the linklist.
Now it is apf authorized.
Maybe yes, maybe no.

See LNKAUTH=APFTAB
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2017-12-19 20:12:36 UTC
Permalink
Raw Message
Correct; with LNKAUTH=APFTAB that particular risk goes away.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tom Marchant <0000000a2a8c2020-dmarc-***@listserv.ua.edu>
Sent: Tuesday, December 19, 2017 2:59 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Cobol upgrade 6.2 linklist
Post by Lizette Koehler
Once a dataset is in the linkst - depending on how it is controlled - someone could put other code in there that is not system friendly.
So I have dataset, MYHLQ.USER.LOADLIB in the linklist.
Now it is apf authorized.
Maybe yes, maybe no.

See LNKAUTH=APFTAB

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-12-19 22:34:35 UTC
Permalink
Raw Message
A linklist data set need not be authorized. If you specify LNKAUTH=APFTAB in IEASYSxx, then an application library would be authorized only if you created an APF entry for it. Assuming that SYS2.PRODLIB is not APF, then there is no more danger in linklisting it than allowing users to STEPLIB to it.

The exposure that my ancient Audit department focused on was devious code that could be slipped into production in some random library being STEPLIBed to in an individual job. Code like the legendary (fairytale?) case of diverting fractions of a cent from accounts payable into a private fund. Someone would have to vet the source code, of course, but at least there was an audit trail from source to production.

.
.
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 Lizette Koehler
Sent: Tuesday, December 19, 2017 11:12 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Cobol upgrade 6.2 linklist

So, my opinion

Once a dataset is in the linkst - depending on how it is controlled - someone could put other code in there that is not system friendly.

So I have dataset, MYHLQ.USER.LOADLIB in the linklist.

Now it is apf authorized.

I use a package like Changemen to deploy to it, but it does not know what should not go there. I use all valid naming conventions for the process. But the code could be something "special".

So USERA decides to create a program with an assembler subroutine that can filter data in a database and send to an unknown site.

Or set up other issues in the system. USERA has the authority to deploy to that dataset. But who is controlling the source to ensure it does not do bad things.


Just my thought

Lizette
-----Original Message-----
On Behalf Of R.S.
Sent: Tuesday, December 19, 2017 6:08 AM
Subject: Re: Cobol upgrade 6.2 linklist
What is the risk of putting COBOL-compiled code into LINKLIST?
Let's assume LNKAUTH=LNKLST.
Such code will not perform any authorized instructions. It can be
called from another AC=1 code, but the problem is the module, not the COBOL code called.
What I'm missing?
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2017-12-19 22:56:24 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
The exposure that my ancient Audit department focused on was devious code that could be slipped into production in some random library being STEPLIBed to in an individual job. Code like the legendary (fairytale?) case of diverting fractions of a cent from accounts payable into a private fund. Someone would have to vet the source code, of course, but at least there was an audit trail from source to production.
I'm not sure I buy that. It seems like linklist would greatly increase
the number of people who could slip in a substitute module. I imagine it
would be easier and less obvious to add a module into a usermod or 3rd
party product installation than to change a STEPLIB in production JCL.

The problem that I am aware of is almost the opposite - where users with
less authorization can add modules that will be executed by uses with
more authorization. E.g. an application person adds a module that just
happens to match a likely misspelling of a RACF command. If called, it
checks authority, performs some nefarious action if allowed, then either
calls the real module or issues the expected error message according to
preference.

In theory code should be vetted, but I suspect the number of cases where
this is possible on z/OS means there would be a lot of stuff that goes
unvetted. On z/OS, you would have to include update access to any clist,
panel etc. libraries in any logon proc as well as any libraries which
are dynamically allocated.
--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bruce Hewson
2017-12-20 03:42:12 UTC
Permalink
Raw Message
Hi,

So Production Control will manage the promotion of modules to the linklisted datasets.

Since it is a PDSE dataset it will always have an active connection and so will not be able to perform automatic compression.
Thus it will get full.

The same Production Control group would be responsible for promotion of Production JCL, and therefore can AUDIT such JCl for valid JOBLIB/STEPLIB specifications.

Therefore the AUDITORs recommendations regarding misuse of STEPLIB must be considered unfounded.

Promotion of JCL containing "bad" STEPLIB datasets, or promotion of "bad" program modules, follows the same Production Control validation/auditing processes, and would therefore be just as susceptible to misuse no matter which process was followed.

Use of JCL check products can assist validation of STEPLIB dataset specifications.

The Auditor's basically "cried wolf".

Regards
Bruce

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
2017-12-20 14:14:19 UTC
Permalink
Raw Message
ok, so along the lines of COBOL 6.2 we're getting prepared to install and test, we found an LE PTF required for 6.2, so on to IBMLINK and ordered all pre reqs PE fixes, superseding, superseded....PTF's for this PTF, for a while now I've been getting nothing but the PTF I order, so during my apply, guess what 'CONDITIONAL REQUISITE SYSMOD UI49212 WAS MISSING.' so has the order process changed or is SRD not working as it use to? I remember a day (years ago), I'd order a PTF and get 10 maybe 20 requisite PTF's not anymore, so am I not selecting all the correct options?



Carmen Vitullo

----- Original Message -----

From: "Bruce Hewson" <***@HOTMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Tuesday, December 19, 2017 9:43:28 PM
Subject: Re: Cobol upgrade 6.2 linklist

Hi,

So Production Control will manage the promotion of modules to the linklisted datasets.

Since it is a PDSE dataset it will always have an active connection and so will not be able to perform automatic compression.
Thus it will get full.

The same Production Control group would be responsible for promotion of Production JCL, and therefore can AUDIT such JCl for valid JOBLIB/STEPLIB specifications.

Therefore the AUDITORs recommendations regarding misuse of STEPLIB must be considered unfounded.

Promotion of JCL containing "bad" STEPLIB datasets, or promotion of "bad" program modules, follows the same Production Control validation/auditing processes, and would therefore be just as susceptible to misuse no matter which process was followed.

Use of JCL check products can assist validation of STEPLIB dataset specifications.

The Auditor's basically "cried wolf".

Regards
Bruce

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
2017-12-20 14:22:38 UTC
Permalink
Raw Message
I think I may have answered my own question, I'm at an RSU1709 level, the PTF' was at a PUT1708 level, my selection on SRD I selected a PUT level of 1709, I believe SRD saw I selected a PUT 1709 level and thus not selected any PRE- or SUP's from before that level?
DUH !



Carmen Vitullo

----- Original Message -----

From: "Carmen Vitullo" <***@HUGHES.NET>
To: IBM-***@LISTSERV.UA.EDU
Sent: Wednesday, December 20, 2017 8:15:14 AM
Subject: Re: Cobol upgrade 6.2 linklist

ok, so along the lines of COBOL 6.2 we're getting prepared to install and test, we found an LE PTF required for 6.2, so on to IBMLINK and ordered all pre reqs PE fixes, superseding, superseded....PTF's for this PTF, for a while now I've been getting nothing but the PTF I order, so during my apply, guess what 'CONDITIONAL REQUISITE SYSMOD UI49212 WAS MISSING.' so has the order process changed or is SRD not working as it use to? I remember a day (years ago), I'd order a PTF and get 10 maybe 20 requisite PTF's not anymore, so am I not selecting all the correct options?



Carmen Vitullo

----- Original Message -----

From: "Bruce Hewson" <***@HOTMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Tuesday, December 19, 2017 9:43:28 PM
Subject: Re: Cobol upgrade 6.2 linklist

Hi,

So Production Control will manage the promotion of modules to the linklisted datasets.

Since it is a PDSE dataset it will always have an active connection and so will not be able to perform automatic compression.
Thus it will get full.

The same Production Control group would be responsible for promotion of Production JCL, and therefore can AUDIT such JCl for valid JOBLIB/STEPLIB specifications.

Therefore the AUDITORs recommendations regarding misuse of STEPLIB must be considered unfounded.

Promotion of JCL containing "bad" STEPLIB datasets, or promotion of "bad" program modules, follows the same Production Control validation/auditing processes, and would therefore be just as susceptible to misuse no matter which process was followed.

Use of JCL check products can assist validation of STEPLIB dataset specifications.

The Auditor's basically "cried wolf".

Regards
Bruce

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-12-20 16:08:33 UTC
Permalink
Raw Message
Since it is a PDSE dataset it will always have an active connection and so will not be able to perform >automatic compression.
Thus it will get full.
Compress PDSE's? This is the (single, maybe) advantage of PDSEs: There is no need to compress.


--
Peter Hunkeler


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
AlanWatthey , GMAIL
2017-12-25 06:57:09 UTC
Permalink
Raw Message
Peter,

PDSE's cannot be compressed by anyone but they still are compressed by the
system automagically (compress here being the term IBM use for the space
reclaim). PDSEs get fragmented and the fragments can become unusable. Free
space (from deleted or replaced members) is not immediately added to the
spare pool as there may still be pointers into the PDSE to members that have
been deleted (connections). This compress is done at open for output when
it is the only open for output and there are no connections. ISPF has some
recovery trickery built in to invoke this rule.

I first ran into this issue with Netview. I was updating my Rexx and
eventually it said there was no room left in the PDSE (D37 I believe). I
read up on it then. Netview luckily provides a command to free and
reallocate all its libraries so they get compressed at the next open for
output I did (from ISPF).

Regards,
Alan Watthey

-----Original Message-----
From: Peter Hunkeler [mailto:***@GMX.CH]
Sent: 20 December 2017 7:09 pm
Subject: AW: Re: Cobol upgrade 6.2 linklist
Post by Bruce Hewson
Since it is a PDSE dataset it will always have an active connection and so
will not be able to perform >automatic compression.
Post by Bruce Hewson
Thus it will get full.
Compress PDSE's? This is the (single, maybe) advantage of PDSEs: There is no
need to compress.


--
Peter Hunkeler


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...