Re: Linklist and APF
> Would that have required two storage keys for each job, one for >writable and one for REFR? Yes. > Or, REFR modules could be loaded in key 0, but that might >compromise privacy (with no threat to integrity). I don't recall OS/360 setting the fetch protect bit in private storage. IAC, once you got to OS/VS2 R2 (MVS), that issue disappeared. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, July 16, 2018 12:20 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF On Mon, 16 Jul 2018 15:25:43 +, Seymour J Metz wrote: >Storage keys were available all the way back to OS/360. > Would that have required two storage keys for each job, one for writable and one for REFR? Or, REFR modules could be loaded in key 0, but that might compromise privacy (with no threat to integrity). If the OS chooses to remove a page to free the storage, I assume that if the page is valid in a page data set and has not been modified there's no need to write it out; just free it. And if the page is in a REFR module, it's an immediate candidate for replacement; no need even to check the modified flag. What if the module is marked REFR but the modified flag has been set? Shouldn't an error be reported? At the very least, the user should be given control of REFRPROT via an option on the JOB statement. > >From: Peter Relson >Sent: Sunday, July 15, 2018 8:54 PM > > >... How much extra would >it have cost to load user programs as well as system programs into >write-protected storage? > > >Page protection did not exist at the time that this logic was introduced. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
An unauthorized program can do EXCP with an appendage., as long as it's specified in PARMLIB. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Monday, July 16, 2018 12:35 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF > the main CPCS task had to run APF Didn't MICR-check-reading programs need authorized channel appendage routines to do pocket selection? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, July 16, 2018 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF The shop I worked in was a bank that ran IBM's CPCS check processing software. I don't know why, but the main CPCS task had to run APF and required that all called programs also come from APF libraries. Even the most ho-hum benign programs. Add to that requirement a corporate security policy against running production jobs from STEPLIB/JOBLIB on the grounds that link list libraries could be 'monitored', but who knew what might live in private libraries. The resulting effect on LNKLSTxx was significant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Mostly true, but there is a mechanism for authorized code to run unauthorized subtasks. If you know enough to do it safely then you already know who does it and how. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Monday, July 16, 2018 12:50 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF > even programs marked AC=0 but called in that fashion will run authorized It is the jobstep that is APF-authorized. Any code in the address space, no matter how it got there*, will effectively "run authorized." *Yes, I know there are restrictions on how you can get code there**, but having gotten it there, no matter how you got it there, it will "run authorized." **No fetches from unauthorized libraries, for example. But you could build machine code yourself in a GETMAIN area and it will "run authorized." No AC=anything at all. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 16, 2018 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF On Mon, 16 Jul 2018 16:07:38 +, Jesse 1 Robinson wrote: >The shop I worked in was a bank that ran IBM's CPCS check processing software. >I don't know why, but the main CPCS task had to run APF and required that all >called programs also come from APF libraries. Even the most ho-hum benign >programs. > Well, yes , but even programs marked AC=0 but called in that fashion will run authorized and must be subject to the same security scrutiny as the parent. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
If the exits are in a non-APF library then the concatenation will not be authorized. If the exits are in an authorized library and have not been audited, it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Monday, July 16, 2018 6:25 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF One consequence of 'APF inheritance' is that sometimes a whole product gets sucked in. For example, CPCS did a lot of software sorting, so the corporate sort product had to be authorized. Maybe not such a big deal, but sort products end to have exit points (E15, etc.) that could potentially be hijacked to do mischief. I would like to think that by now most of these problems have designed out... . . 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, July 16, 2018 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Linklist and APF > even programs marked AC=0 but called in that fashion will run > authorized It is the jobstep that is APF-authorized. Any code in the address space, no matter how it got there*, will effectively "run authorized." *Yes, I know there are restrictions on how you can get code there**, but having gotten it there, no matter how you got it there, it will "run authorized." **No fetches from unauthorized libraries, for example. But you could build machine code yourself in a GETMAIN area and it will "run authorized." No AC=anything at all. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 16, 2018 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF On Mon, 16 Jul 2018 16:07:38 +, Jesse 1 Robinson wrote: >The shop I worked in was a bank that ran IBM's CPCS check processing software. >I don't know why, but the main CPCS task had to run APF and required that all >called programs also come from APF libraries. Even the most ho-hum benign >programs. > Well, yes , but even programs marked AC=0 but called in that fashion will run authorized and must be subject to the same security scrutiny as the parent. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
One consequence of 'APF inheritance' is that sometimes a whole product gets sucked in. For example, CPCS did a lot of software sorting, so the corporate sort product had to be authorized. Maybe not such a big deal, but sort products end to have exit points (E15, etc.) that could potentially be hijacked to do mischief. I would like to think that by now most of these problems have designed out... . . 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, July 16, 2018 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Linklist and APF > even programs marked AC=0 but called in that fashion will run > authorized It is the jobstep that is APF-authorized. Any code in the address space, no matter how it got there*, will effectively "run authorized." *Yes, I know there are restrictions on how you can get code there**, but having gotten it there, no matter how you got it there, it will "run authorized." **No fetches from unauthorized libraries, for example. But you could build machine code yourself in a GETMAIN area and it will "run authorized." No AC=anything at all. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 16, 2018 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF On Mon, 16 Jul 2018 16:07:38 +, Jesse 1 Robinson wrote: >The shop I worked in was a bank that ran IBM's CPCS check processing software. >I don't know why, but the main CPCS task had to run APF and required that all >called programs also come from APF libraries. Even the most ho-hum benign >programs. > Well, yes , but even programs marked AC=0 but called in that fashion will run authorized and must be subject to the same security scrutiny as the parent. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
> even programs marked AC=0 but called in that fashion will run authorized It is the jobstep that is APF-authorized. Any code in the address space, no matter how it got there*, will effectively "run authorized." *Yes, I know there are restrictions on how you can get code there**, but having gotten it there, no matter how you got it there, it will "run authorized." **No fetches from unauthorized libraries, for example. But you could build machine code yourself in a GETMAIN area and it will "run authorized." No AC=anything at all. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 16, 2018 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF On Mon, 16 Jul 2018 16:07:38 +, Jesse 1 Robinson wrote: >The shop I worked in was a bank that ran IBM's CPCS check processing software. >I don't know why, but the main CPCS task had to run APF and required that all >called programs also come from APF libraries. Even the most ho-hum benign >programs. > Well, yes , but even programs marked AC=0 but called in that fashion will run authorized and must be subject to the same security scrutiny as the parent. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
> the main CPCS task had to run APF Didn't MICR-check-reading programs need authorized channel appendage routines to do pocket selection? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, July 16, 2018 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF The shop I worked in was a bank that ran IBM's CPCS check processing software. I don't know why, but the main CPCS task had to run APF and required that all called programs also come from APF libraries. Even the most ho-hum benign programs. Add to that requirement a corporate security policy against running production jobs from STEPLIB/JOBLIB on the grounds that link list libraries could be 'monitored', but who knew what might live in private libraries. The resulting effect on LNKLSTxx was significant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Mon, 16 Jul 2018 16:07:38 +, Jesse 1 Robinson wrote: >The shop I worked in was a bank that ran IBM's CPCS check processing software. >I don't know why, but the main CPCS task had to run APF and required that all >called programs also come from APF libraries. Even the most ho-hum benign >programs. > Well, yes , but even programs marked AC=0 but called in that fashion will run authorized and must be subject to the same security scrutiny as the parent. >Add to that requirement a corporate sucurity policy against running production >jobs from STEPLIB/JOBLIB on the grounds that link list libraries could be >'monitored', but who knew what might live in private libraries. The resulting >effect on LNKLSTxx was significant. > There's something dreadfully wrong with IBM's security model. But I guess you're not allowed to shoot them; they did the best they could with the resources they had. >-Original Message- >From: Seymour J Metz >Sent: Monday, July 16, 2018 8:22 AM > >Be careful what you ask for; you might get it. Some APF programs invoke >non-APF programs. > > >From: Charles Mills >Sent: Sunday, July 15, 2018 10:04 PM > >Putting on my security preacher hat, I might argue that programs that do not >need APF (i.e., test successfully without it) should not be in an APF library. >Granted, your story is from simpler times (I would assume). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Mon, 16 Jul 2018 15:25:43 +, Seymour J Metz wrote: >Storage keys were available all the way back to OS/360. > Would that have required two storage keys for each job, one for writable and one for REFR? Or, REFR modules could be loaded in key 0, but that might compromise privacy (with no threat to integrity). If the OS chooses to remove a page to free the storage, I assume that if the page is valid in a page data set and has not been modified there's no need to write it out; just free it. And if the page is in a REFR module, it's an immediate candidate for replacement; no need even to check the modified flag. What if the module is marked REFR but the modified flag has been set? Shouldn't an error be reported? At the very least, the user should be given control of REFRPROT via an option on the JOB statement. > >From: Peter Relson >Sent: Sunday, July 15, 2018 8:54 PM > > >... How much extra would >it have cost to load user programs as well as system programs into >write-protected storage? > > >Page protection did not exist at the time that this logic was introduced. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
The shop I worked in was a bank that ran IBM's CPCS check processing software. I don't know why, but the main CPCS task had to run APF and required that all called programs also come from APF libraries. Even the most ho-hum benign programs. Add to that requirement a corporate security policy against running production jobs from STEPLIB/JOBLIB on the grounds that link list libraries could be 'monitored', but who knew what might live in private libraries. The resulting effect on LNKLSTxx was significant. . . 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, July 16, 2018 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Linklist and APF Be careful what you ask for; you might get it. Some APF programs invoke non-APF programs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Sunday, July 15, 2018 10:04 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF Putting on my security preacher hat, I might argue that programs that do not need APF (i.e., test successfully without it) should not be in an APF library. Granted, your story is from simpler times (I would assume). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Sunday, July 15, 2018 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF My very first oh-dark-thirty support call as a sysprog was for a program I had just updated. I had cluelessly assembled it using JCL that had RENT,REFR in the link edit step. After testing, I moved it from the non-APF test library to the APF production library. Big S0C4. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Storage keys were available all the way back to OS/360. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Sunday, July 15, 2018 8:54 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF There's also REFRPROT nowadays. But that should have never been needed as an option; it should have been the universal behaior ab ovo. How much extra would it have cost to load user programs as well as system programs into write-protected storage? Page protection did not exist at the time that this logic was introduced. So "ab ovo" was not possible if used the way I interpret it. Changing the behavior when page protection was added would be viewed, properly, as incompatible and thus unacceptable. And the extra storage utilization (page multiple on page boundary) might have been felt to be unacceptable too (perhaps no longer). Users are creative and might have chosen to rely on the existing documented behavior. It is also well known that the system does not "protect" against reentrant programs writing into themselves, just makes it harder. And it is also well known that a program could write into itself and still be reentrant (although that is surely frowned upon these days). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
I've been bitching about that for half a century, long before there was such a thing as REFRPROT. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Sunday, July 15, 2018 9:41 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF On Mon, 16 Jul 2018 01:21:06 +, Jesse 1 Robinson wrote: >My very first oh-dark-thirty support call as a sysprog was for a program I had >just updated. I had cluelessly assembled it using JCL that had RENT,REFR in >the link edit step. After testing, I moved it from the non-APF test library to >the APF production library. Big S0C4. > >All inadvertent. A set of lessons I have never forgotten. > If something like the function of REFRPROT had operated on non-APF libraries the problem would have been discovered during testing rather than production. I consider this uniformity a powerful argument for universal REFRPROT. >-Original Message- >From: Behalf Of Peter Relson >Sent: Sunday, July 15, 2018 5:55 PM > > >There's also REFRPROT nowadays. But that should have never been needed as an >option; it should have been the universal behaior ab ovo. How much extra >would it have cost to load user programs as well as system programs into >write-protected storage? > > >Page protection did not exist at the time that this logic was introduced. >So "ab ovo" was not possible if used the way I interpret it. > How, then, was it possible to protect code loaded from APF authorized libraries but not from other libraries? >Changing the behavior when page protection was added would be viewed, >properly, as incompatible and thus unacceptable. > It is always proper to report errors, even those that had never been detected before. >And the extra storage utilization (page multiple on page boundary) might have >been felt to be unacceptable too (perhaps no longer). > Understood. I don't know how great an impact it would have been. Apparently it was deemed acceptable for APF libraries. >Users are creative and might have chosen to rely on the existing documented >behavior. It is also well known that the system does not "protect" against >reentrant programs writing into themselves, just makes it harder. And it is >also well known that a program could write into itself and still be reentrant >(although that is surely frowned upon these days). > Are you conflating RENT and REFR? I understand the long-standing exception for RENT, but was it ever documented that a program could write into itself and still be REFR? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Be careful what you ask for; you might get it. Some APF programs invoke non-APF programs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Sunday, July 15, 2018 10:04 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF Putting on my security preacher hat, I might argue that programs that do not need APF (i.e., test successfully without it) should not be in an APF library. Granted, your story is from simpler times (I would assume). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Sunday, July 15, 2018 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF My very first oh-dark-thirty support call as a sysprog was for a program I had just updated. I had cluelessly assembled it using JCL that had RENT,REFR in the link edit step. After testing, I moved it from the non-APF test library to the APF production library. Big S0C4. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Linklist and APF
>It depends on your definition of "fairly recent". LNKAUTH=APFTAB was >introduced in MVS/XA SP2.1.1, about 35 years ago.. He wrote "I believe..." and you can always believe what you want . (No offence intended; just couln't resist). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Classification: Public There you are, that's what he said, fairly recent. A bit like those new-fangled PDSEs and new format JES2 commands.. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: 16 July 2018 04:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF -- This email has reached the Bank via an external source -- It depends on your definition of "fairly recent". LNKAUTH=APFTAB was introduced in MVS/XA SP2.1.1, about 35 years ago.. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > I believe that until a fairly recent OS release LNKLST did not > support a mixture > of APF and non-APF libraries. So if you wanted your program > accessible without > STEPLIB it was (almost) necessary to put it in an APF library. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
It depends on your definition of "fairly recent". LNKAUTH=APFTAB was introduced in MVS/XA SP2.1.1, about 35 years ago.. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > I believe that until a fairly recent OS release LNKLST did not > support a mixture > of APF and non-APF libraries. So if you wanted your program > accessible without > STEPLIB it was (almost) necessary to put it in an APF library. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
This was the 70s. As I recall it was all or nothing at that time. I never made that mistake again. ;-) . . 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, July 15, 2018 7:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Linklist and APF On Mon, 16 Jul 2018 02:09:20 +, Jesse 1 Robinson wrote: >Program did not need APF. Shared production library contained other programs >that did need it. Until my bad JCL, it had never been a problem. I guess times >were simpler then... > I believe that until a fairly recent OS release LNKLST did not support a mixture of APF and non-APF libraries. So if you wanted your program accessible without STEPLIB it was (almost) necessary to put it in an APF library. >-Original Message- >From: Charles Mills >Sent: Sunday, July 15, 2018 7:05 PM > >Putting on my security preacher hat, I might argue that programs that do not >need APF (i.e., test successfully without it) should not be in an APF library. >Granted, your story is from simpler times (I would assume). > There's the dilemma of how faithfully the test environment should mimic the production environment. Should the program have been tested at oh-dark-thirty, from an authorized library, with live data ...? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Mon, 16 Jul 2018 02:09:20 +, Jesse 1 Robinson wrote: >Program did not need APF. Shared production library contained other programs >that did need it. Until my bad JCL, it had never been a problem. I guess times >were simpler then... > I believe that until a fairly recent OS release LNKLST did not support a mixture of APF and non-APF libraries. So if you wanted your program accessible without STEPLIB it was (almost) necessary to put it in an APF library. >-Original Message- >From: Charles Mills >Sent: Sunday, July 15, 2018 7:05 PM > >Putting on my security preacher hat, I might argue that programs that do not >need APF (i.e., test successfully without it) should not be in an APF library. >Granted, your story is from simpler times (I would assume). > There's the dilemma of how faithfully the test environment should mimic the production environment. Should the program have been tested at oh-dark-thirty, from an authorized library, with live data ...? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Program did not need APF. Shared production library contained other programs that did need it. Until my bad JCL, it had never been a problem. I guess times were simpler then... . . 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Sunday, July 15, 2018 7:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Linklist and APF Putting on my security preacher hat, I might argue that programs that do not need APF (i.e., test successfully without it) should not be in an APF library. Granted, your story is from simpler times (I would assume). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Sunday, July 15, 2018 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF My very first oh-dark-thirty support call as a sysprog was for a program I had just updated. I had cluelessly assembled it using JCL that had RENT,REFR in the link edit step. After testing, I moved it from the non-APF test library to the APF production library. Big S0C4. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Putting on my security preacher hat, I might argue that programs that do not need APF (i.e., test successfully without it) should not be in an APF library. Granted, your story is from simpler times (I would assume). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Sunday, July 15, 2018 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF My very first oh-dark-thirty support call as a sysprog was for a program I had just updated. I had cluelessly assembled it using JCL that had RENT,REFR in the link edit step. After testing, I moved it from the non-APF test library to the APF production library. Big S0C4. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Mon, 16 Jul 2018 01:21:06 +, Jesse 1 Robinson wrote: >My very first oh-dark-thirty support call as a sysprog was for a program I had >just updated. I had cluelessly assembled it using JCL that had RENT,REFR in >the link edit step. After testing, I moved it from the non-APF test library to >the APF production library. Big S0C4. > >All inadvertent. A set of lessons I have never forgotten. > If something like the function of REFRPROT had operated on non-APF libraries the problem would have been discovered during testing rather than production. I consider this uniformity a powerful argument for universal REFRPROT. >-Original Message- >From: Behalf Of Peter Relson >Sent: Sunday, July 15, 2018 5:55 PM > > >There's also REFRPROT nowadays. But that should have never been needed as an >option; it should have been the universal behaior ab ovo. How much extra >would it have cost to load user programs as well as system programs into >write-protected storage? > > >Page protection did not exist at the time that this logic was introduced. >So "ab ovo" was not possible if used the way I interpret it. > How, then, was it possible to protect code loaded from APF authorized libraries but not from other libraries? >Changing the behavior when page protection was added would be viewed, >properly, as incompatible and thus unacceptable. > It is always proper to report errors, even those that had never been detected before. >And the extra storage utilization (page multiple on page boundary) might have >been felt to be unacceptable too (perhaps no longer). > Understood. I don't know how great an impact it would have been. Apparently it was deemed acceptable for APF libraries. >Users are creative and might have chosen to rely on the existing documented >behavior. It is also well known that the system does not "protect" against >reentrant programs writing into themselves, just makes it harder. And it is >also well known that a program could write into itself and still be reentrant >(although that is surely frowned upon these days). > Are you conflating RENT and REFR? I understand the long-standing exception for RENT, but was it ever documented that a program could write into itself and still be REFR? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
My very first oh-dark-thirty support call as a sysprog was for a program I had just updated. I had cluelessly assembled it using JCL that had RENT,REFR in the link edit step. After testing, I moved it from the non-APF test library to the APF production library. Big S0C4. All inadvertent. A set of lessons I have never forgotten. . . 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, July 15, 2018 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Linklist and APF There's also REFRPROT nowadays. But that should have never been needed as an option; it should have been the universal behaior ab ovo. How much extra would it have cost to load user programs as well as system programs into write-protected storage? Page protection did not exist at the time that this logic was introduced. So "ab ovo" was not possible if used the way I interpret it. Changing the behavior when page protection was added would be viewed, properly, as incompatible and thus unacceptable. And the extra storage utilization (page multiple on page boundary) might have been felt to be unacceptable too (perhaps no longer). Users are creative and might have chosen to rely on the existing documented behavior. It is also well known that the system does not "protect" against reentrant programs writing into themselves, just makes it harder. And it is also well known that a program could write into itself and still be reentrant (although that is surely frowned upon these days). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
There's also REFRPROT nowadays. But that should have never been needed as an option; it should have been the universal behaior ab ovo. How much extra would it have cost to load user programs as well as system programs into write-protected storage? Page protection did not exist at the time that this logic was introduced. So "ab ovo" was not possible if used the way I interpret it. Changing the behavior when page protection was added would be viewed, properly, as incompatible and thus unacceptable. And the extra storage utilization (page multiple on page boundary) might have been felt to be unacceptable too (perhaps no longer). Users are creative and might have chosen to rely on the existing documented behavior. It is also well known that the system does not "protect" against reentrant programs writing into themselves, just makes it harder. And it is also well known that a program could write into itself and still be reentrant (although that is surely frowned upon these days). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Fri, 6 Jul 2018 07:31:51 -0700, Charles Mills wrote: >Let me put on my security preacher hat for a moment. > >Yes, what Eileen says is a fact: there is no z/OS "enforcement" of RENT unless >the program is from an APF library. You can easily get surprised by "where did >that S0C4 come from?" > There's also REFRPROT nowadays. But that should have never been needed as an option; it should have been the universal behaior ab ovo. How much extra would it have cost to load user programs as well as system programs into write-protected storage? >But that is not the big issue. > >If you are getting "surprised" by "oh gosh, look at that, it's getting loaded >from an APF library" then you do not have proper controls over what is >probably THE most critical aspect of mainframe integrity, ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Actually, there is no enforcement of RENT, period. A module linked with RENT can be shared between tasks, even if it updates common data without proper serialization. It didn't help thet Fetch ignored REFR. BTW. OS/360 had some reentrant modules that were not refreshable. IMHO that is extremely bad form. AFAIK all of those have been cleaned up. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Friday, July 6, 2018 10:31 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Linklist and APF Let me put on my security preacher hat for a moment. Yes, what Eileen says is a fact: there is no z/OS "enforcement" of RENT unless the program is from an APF library. You can easily get surprised by "where did that S0C4 come from?" But that is not the big issue. If you are getting "surprised" by "oh gosh, look at that, it's getting loaded from an APF library" then you do not have proper controls over what is probably THE most critical aspect of mainframe integrity, and as Barry Schrager observed at the dawn of mainframe security, without integrity there is no security. APF libraries are the keys to the kingdom. If I worked for you, and I were a malicious programmer, and I observed that if I did X and Y and Z then my program would end up in an APF library without any management or security review, then I OWN your mainframe. An APF-authorized program can do ANYTHING. Ray Overby and others have demonstrated at SHARE that just a few lines of obscure binary in an authorized program can give the user RACF SPECIAL and/or OPERATIONS/PRIVILEGED with NO AUDIT TRAIL WHATSOEVER, and from there on out the sky is the limit. There are two pieces to APF authorization, AC=1 and the library. There are no controls over AC=1 -- any programmer can do it. It is up to you to control APF libraries rigorously. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Friday, July 6, 2018 6:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF I am not sure if this is still true, but a while ago we had a problem whereby a program would only work from steplib and not a linklib. It turned out that certain options such as RENT were only enforced if the module resided in an apf authorized linklib. So our module had been link-edited with the RENT option but was not really reentrant, so it abended when the RENT attribute was enforced. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Let me put on my security preacher hat for a moment. Yes, what Eileen says is a fact: there is no z/OS "enforcement" of RENT unless the program is from an APF library. You can easily get surprised by "where did that S0C4 come from?" But that is not the big issue. If you are getting "surprised" by "oh gosh, look at that, it's getting loaded from an APF library" then you do not have proper controls over what is probably THE most critical aspect of mainframe integrity, and as Barry Schrager observed at the dawn of mainframe security, without integrity there is no security. APF libraries are the keys to the kingdom. If I worked for you, and I were a malicious programmer, and I observed that if I did X and Y and Z then my program would end up in an APF library without any management or security review, then I OWN your mainframe. An APF-authorized program can do ANYTHING. Ray Overby and others have demonstrated at SHARE that just a few lines of obscure binary in an authorized program can give the user RACF SPECIAL and/or OPERATIONS/PRIVILEGED with NO AUDIT TRAIL WHATSOEVER, and from there on out the sky is the limit. There are two pieces to APF authorization, AC=1 and the library. There are no controls over AC=1 -- any programmer can do it. It is up to you to control APF libraries rigorously. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Friday, July 6, 2018 6:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF I am not sure if this is still true, but a while ago we had a problem whereby a program would only work from steplib and not a linklib. It turned out that certain options such as RENT were only enforced if the module resided in an apf authorized linklib. So our module had been link-edited with the RENT option but was not really reentrant, so it abended when the RENT attribute was enforced. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Human mistake, please disregard. -- 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: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
I am not sure if this is still true, but a while ago we had a problem whereby a program would only work from steplib and not a linklib. It turned out that certain options such as RENT were only enforced if the module resided in an apf authorized linklib. So our module had been link-edited with the RENT option but was not really reentrant, so it abended when the RENT attribute was enforced. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Thursday, July 05, 2018 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF What does the PGM= do as coded? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, July 5, 2018 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF Radoslaw Skorupka wrote: >I have job with the following steplib: >//STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1 >//DD DISP=SHR,DSN=HLQ.LNKLST.LIB2 >//DD DISP=SHR,DSN=HLQ.NONLNK.LIB3 >LIB1, and LIB2 reside in LNKLST, but not on APF. >LIB3 is not on LNKLST, but is APF-authorized. >The job works when all 3 libraries are in steplib concatenation. In this concatenation, all or none should be APFed depending on the requirement of the program(s). I am a$$uming ALL the programs required for that job is sitting in any of those STEPLIB libraries. >When I remove LIB1 and LIB2 it doesn't work. How so? Any messages or abends? >Is it because lack of explicit APF authirization? Perhaps, but it depends where the program modules are fetched from. If a program is NOT fetched at all from any of those STEPLIB libraries, then Linklist is searched instead. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Thu, 5 Jul 2018 17:18:24 +0200, R.S. wrote: > >The job works when all 3 libraries are in steplib concatenation. When I >remove LIB1 and LIB2 it doesn't work. Maybe there is a same-name-different-content module in one of the other libs in linklist before lib1 and 2 ? Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
What does the PGM= do as coded? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, July 5, 2018 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and APF Radoslaw Skorupka wrote: >I have job with the following steplib: >//STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1 >//DD DISP=SHR,DSN=HLQ.LNKLST.LIB2 >//DD DISP=SHR,DSN=HLQ.NONLNK.LIB3 >LIB1, and LIB2 reside in LNKLST, but not on APF. >LIB3 is not on LNKLST, but is APF-authorized. >The job works when all 3 libraries are in steplib concatenation. In this concatenation, all or none should be APFed depending on the requirement of the program(s). I am a$$uming ALL the programs required for that job is sitting in any of those STEPLIB libraries. >When I remove LIB1 and LIB2 it doesn't work. How so? Any messages or abends? >Is it because lack of explicit APF authirization? Perhaps, but it depends where the program modules are fetched from. If a program is NOT fetched at all from any of those STEPLIB libraries, then Linklist is searched instead. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Thu, 5 Jul 2018 17:18:24 +0200, R.S. wrote: >I have job with the following steplib: > >//STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1 >// DD DISP=SHR,DSN=HLQ.LNKLST.LIB2 >// DD DISP=SHR,DSN=HLQ.NONLNK.LIB3 > >LIB1, and LIB2 reside in LNKLST, but not on APF. >LIB3 is not on LNKLST, but is APF-authorized. > >The job works when all 3 libraries are in steplib concatenation. When I >remove LIB1 and LIB2 it doesn't work. Is it because lack of explicit APF >authirization? >LNKLST is authorized by IEASYS default entry. It would help to know what you mean by "works" and "doesn't work". But for a start, remember that LNKAUTH=LNKLST means that the libraries in the link list are all authorized *when they are accessed as part of the link list*. Therefore, your STEPLIB concatenation is *not* APF-authorized, because it contains LIB1 and LIB2 which are not APF-authorized in your usage. My guess about what you mean by "doesn't work" is that once the job step is running APF-authorized (which will happen when you remove LIB1 and LIB2 from STEPLIB) you're getting an S0C4 abend because some program you're running claims to be RENT but isn't. When run APF-authorized it's loaded into protected storage, and when it tries to store into itself it gets the S0C4. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
Radoslaw Skorupka wrote: >I have job with the following steplib: >//STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1 >//DD DISP=SHR,DSN=HLQ.LNKLST.LIB2 >//DD DISP=SHR,DSN=HLQ.NONLNK.LIB3 >LIB1, and LIB2 reside in LNKLST, but not on APF. >LIB3 is not on LNKLST, but is APF-authorized. >The job works when all 3 libraries are in steplib concatenation. In this concatenation, all or none should be APFed depending on the requirement of the program(s). I am a$$uming ALL the programs required for that job is sitting in any of those STEPLIB libraries. >When I remove LIB1 and LIB2 it doesn't work. How so? Any messages or abends? >Is it because lack of explicit APF authirization? Perhaps, but it depends where the program modules are fetched from. If a program is NOT fetched at all from any of those STEPLIB libraries, then Linklist is searched instead. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and APF
On Thu, 5 Jul 2018 17:18:24 +0200, R.S. wrote: >I have job with the following steplib: > >//STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1 >// DD DISP=SHR,DSN=HLQ.LNKLST.LIB2 >// DD DISP=SHR,DSN=HLQ.NONLNK.LIB3 > >LIB1, and LIB2 reside in LNKLST, but not on APF. >LIB3 is not on LNKLST, but is APF-authorized. So, the concatenation is not authorized. >The job works when all 3 libraries are in steplib concatenation. When I >remove LIB1 and LIB2 it doesn't work. Is it because lack of explicit APF >authirization? "Doesn't work" in what way? >LNKLST is authorized by IEASYS default entry. You mean you have LNKAUTH=LNKLST defaulted? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Linklist and APF
I have job with the following steplib: //STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1 // DD DISP=SHR,DSN=HLQ.LNKLST.LIB2 // DD DISP=SHR,DSN=HLQ.NONLNK.LIB3 LIB1, and LIB2 reside in LNKLST, but not on APF. LIB3 is not on LNKLST, but is APF-authorized. The job works when all 3 libraries are in steplib concatenation. When I remove LIB1 and LIB2 it doesn't work. Is it because lack of explicit APF authirization? LNKLST is authorized by IEASYS default entry. -- 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: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN