Re: LINK vs LOAD/CALL
On Mon, 8 Feb 2021 03:12:25 +, CM Poncelet wrote: > >Never heard of REFRPROT or how it differs from REFR. Perhaps it's after I >retired (7+ years ago) > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieae200/progref.htm -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
>From Michael Stein's excellent summary of REFR: refreshable: all or part of the module can be replaced at any time without notice by the operating system. *therefore* must not modify itself in any way. Never heard of REFRPROT or how it differs from REFR. Perhaps it's after I retired (7+ years ago) Chris Poncelet (retired sysprog) On 08/02/2021 02:10, Seymour J Metz wrote: > If REFRPROT is not specified then a refreshable module can modify itself. > Don't do it at home. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Sunday, February 7, 2021 5:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > Of course. I have never suggested that it was *reasonable* to ENQ/DEQ or > otherwise serialize code in a RENT module, but only that it was > *possible* to do so without compromising an LMOD's RENT attribute. > Likewise, when I said a REFR LMOD could be "swapped out", I meant its > page(s) could be "stolen" by the O/S at any time without its having > first to "back up" the LMOD to a paging dataset or cache. > > Michael Stein provided an excellent summary of the meanings of REUS, > RENT and REFR in his "load module search order and attributes" post. > > I recommended that ASM modules should always be coded as RSECTs (not as > CSECTs) to allow the assembler to trap, whenever possible, any code that > could modify itself. > > AFAIR Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies > itself during execution. > > Chris Poncelet (retired sysprog) > > > > On 07/02/2021 16:52, Seymour J Metz wrote: >> It's a bit more complicated. First, you can decouple REFR from RENT by using >> the linkage editor. Second, you can write code that is reentrant and >> refreshable, modifies itself and does not use ENQ/DEQ. However, I suspect >> that at some point REFRPR"OT will be mandatory. >> >> BTW, just because it is possible doesn't mean that it is a reasonable thing >> to do; absent compelling reasons otherwise, I would red flag it in a code >> review. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> CM Poncelet [ponce...@bcs.org.uk] >> Sent: Friday, February 5, 2021 9:57 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LINK vs LOAD/CALL >> >> No. RENT implies REUS. Meanwhile RENT *may* be modified IFF an ENQ is >> first issued on the code to be modified, provided that code is then >> restored to what it was before it was ENQ'd and then DEQ'd. Only REFR >> prohibits any code modification (because REFR means that an LMOD can be >> swapped out and refreshed from its original copy on DASD, at any time >> during execution and without interruption) - and REFR implies RENT >> implies REUS, but RENT does not imply REFR. >> >> >> >> On 05/02/2021 20:02, Joseph Reichman wrote: >>> Sorry to jump in here but can you have rent without reus >>> >>> >>> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: If the module is not REUS then every LOAD will get a different copy. If the module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I would use LINK(X). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Friday, February 5, 2021 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL I would like to add: while LINK is functionally the same as LOAD - CALL - DELETE, there is an important difference: the transfer of control with LINK is known to the operating system, but with LOAD - CALL - DELETE, it is NOT known. In fact, CALL is not a supervisor action, it is simple machine instructions (very cheap). This means that if a module is not RENT and not REUS (for example), a call using LOAD - CALL - DELETE is not safe, because the system does not know that the module is in use. Another subtask can easily call the same module at the same time, if it knows the address, and it will never get another copy. You are responsible yourself for doing things right. With LINK, on the contrary, if the module is not RENT and not REUS, the system will ALWAYS fetch a new copy, when you do another LINK. (There is a "use count" in the control blocks, which is incremented and decremented during LINK processing, but of course not, when doing a CALL). Kind regards
Re: LINK vs LOAD/CALL
This is refreshable, and even runs on S/360 L R15,PTR LTR R15,R15 BNZ CALLIT ......Code that always leaves the same value in R15 STR15,PTR CALLIT BALR R14,R15 ... PTR DCA(0) This is reentrant, and requires at least S/370 RETRYL R1,COUNTER LAR0,1(,R1) CSR1,,R0,COUNTER BNE RETRY ... COUNTER DCF'0' I would consider either to be bad form. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [bdis...@dissensoftware.com] Sent: Sunday, February 7, 2021 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On Sun, 7 Feb 2021 16:52:55 + Seymour J Metz wrote: :>Second, you can write code that is reentrant and refreshable, modifies itself ... Only possible if it modifies itself but pays no attention to the modified area. Not really relevant. -- Binyamin Dissen http://secure-web.cisco.com/19fzBBFfAFBx8PysD0V3qJwF9qE3g50-el2X9G9hk1S6e6J1OJCsS3iW5Z4sW_eIxmVeSUtphiZ1F_hVA17R0eQ0sISoKmaje1LKLxW5hXXG57Bhp2jgb7tfsyTUCz7uR3oi_3QvypHyqrkZbk90NkCCElTsVY_WlQLUN3ZGkDG1kO6WKuK6QjZMrhjWBiYf0C9yl8O8I4qv3EpHVq2VRzt08kpxpmxsg6gnybjtHX8YvBuUnV69On_Zzc0LY2kT7e31qhCg19eAfUSCspghB948WQ7TW-XVS3W0hjnawFDJuSq_Gu6Ik-pJsBZ9JBai6AHJCbw-0jDqyvmh1mpiJaD4SemvF8t211o_Xhkk4-K9gYDgDLDpWbiole96yIwNk6hI6rfM33dkqiO-w6cJY6yIpcdBe1cjlMlsHJsUJGWjQHoOCTBflbOxTayrH2erW/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: LINK vs LOAD/CALL
If it were me I'd ask IBM to set what they considered the most reasonable precedence and document it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, February 7, 2021 5:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On Sun, 7 Feb 2021 17:53:28 +, Seymour J Metz wrote: >... IMHO a warn option would be highly desirable. >Why JOB instead of EXEC? > Good suggestion. How about both; but which dominates? > >From: Paul Gilmartin >Sent: Sunday, February 7, 2021 12:46 PM > >REFRPROT should be an opt-in (but not opt-out) option on the JOB >statement. --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: LINK vs LOAD/CALL
If REFRPROT is not specified then a refreshable module can modify itself. Don't do it at home. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Sunday, February 7, 2021 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Of course. I have never suggested that it was *reasonable* to ENQ/DEQ or otherwise serialize code in a RENT module, but only that it was *possible* to do so without compromising an LMOD's RENT attribute. Likewise, when I said a REFR LMOD could be "swapped out", I meant its page(s) could be "stolen" by the O/S at any time without its having first to "back up" the LMOD to a paging dataset or cache. Michael Stein provided an excellent summary of the meanings of REUS, RENT and REFR in his "load module search order and attributes" post. I recommended that ASM modules should always be coded as RSECTs (not as CSECTs) to allow the assembler to trap, whenever possible, any code that could modify itself. AFAIR Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. Chris Poncelet (retired sysprog) On 07/02/2021 16:52, Seymour J Metz wrote: > It's a bit more complicated. First, you can decouple REFR from RENT by using > the linkage editor. Second, you can write code that is reentrant and > refreshable, modifies itself and does not use ENQ/DEQ. However, I suspect > that at some point REFRPR"OT will be mandatory. > > BTW, just because it is possible doesn't mean that it is a reasonable thing > to do; absent compelling reasons otherwise, I would red flag it in a code > review. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Friday, February 5, 2021 9:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > No. RENT implies REUS. Meanwhile RENT *may* be modified IFF an ENQ is > first issued on the code to be modified, provided that code is then > restored to what it was before it was ENQ'd and then DEQ'd. Only REFR > prohibits any code modification (because REFR means that an LMOD can be > swapped out and refreshed from its original copy on DASD, at any time > during execution and without interruption) - and REFR implies RENT > implies REUS, but RENT does not imply REFR. > > > > On 05/02/2021 20:02, Joseph Reichman wrote: >> Sorry to jump in here but can you have rent without reus >> >> >> >>> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: >>> >>> If the module is not REUS then every LOAD will get a different copy. If >>> the module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. >>> Using LOAD, SYNCH, DELETE is left as an excise for the reader. In most >>> cases I would use LINK(X). >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >>> Bernd Oppolzer [bernd.oppol...@t-online.de] >>> Sent: Friday, February 5, 2021 1:41 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: LINK vs LOAD/CALL >>> >>> I would like to add: >>> >>> while LINK is functionally the same as LOAD - CALL - DELETE, >>> there is an important difference: >>> >>> the transfer of control with LINK is known to the operating system, >>> but with LOAD - CALL - DELETE, it is NOT known. >>> In fact, CALL is not a supervisor action, it is simple machine >>> instructions (very cheap). >>> This means that if a module is not RENT and not REUS (for example), >>> a call using LOAD - CALL - DELETE is not safe, because the system does >>> not know that >>> the module is in use. Another subtask can easily call the same module at >>> the same time, >>> if it knows the address, and it will never get another copy. You are >>> responsible yourself >>> for doing things right. >>> >>> With LINK, on the contrary, if the module is not RENT and not REUS, the >>> system >>> will ALWAYS fetch a new copy, when you do another LINK. >>> >>> (There is a "use count" in the control blocks, which is incremented and >>> decremented >>> during LINK processing, but of course not, when doing a CALL). >>> >>> Kind regards >>> >>> Bernd >>> >>> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: I am not a systems programmer. I am a COBOL programmer who knows only enough assembler to be dangerous. What is the "difference" between doing a LOAD and a CALL to perform a dynamic call and doing a LINK? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>
Re: Coupling Facility and z/OS SysPlex LPARs moving to new hardware
W dniu 07.02.2021 o 19:34, Arye Shemer pisze: Installation I work with is going to move Coupling Facilities and z/OS LPARs to new hardware. To best of my recollections after defining the IODFs for the new systems (z15) which should (could) include definitions for old and new systems.system programmers can rely on system commands to remove CF LPAR and activate the new one on the new hardware. At last my question, is this assumption correct (using System Commands to remove old and activate new CF LPARs) ? I do not expect a list of commands, just approval (or not) :-) First: you can replace any CPC in a sysplex with no disruption. It covers both z/OS and CF images. However there are several assumptions to be met. In very general: Put new hardware to the server room and connect channels: z/OS images need access to DASD and other devices. CF and z/OS LPARs need sysplex links. Detailed sysplex link connectivity need to be planned, however in general every z/OS LPAR has to be connected to every CF LPAR. Assumption: one sysplex is considered. Reality is usually more complex. Activate new IODF - it should be modified version of your old IODF with addictions of new hardware and channels. Change logical sysplex definitions (policies, GRS, etc.) - that will introduce new logical CF. Also add new z/OS images to the sysplex. It can be done later. Now you have a sysplex with old and new CFs. Then move (rebuild) structures on new CF. As a result you will have new CFs in use and old CFs as dummy. Then you can logically delete old CFs. And then offline the channels and deactivate CF LPARs. For z/OS - you already have new sysplex members on new hardware. Just shutdown old members. Deactivate old z/OS LPARs. Finally you can power down old hardware. Very short description of quite long and complex project. Of course if you can accept outage, the process would be much easier and shorter. :-) HTH -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
Of course. I have never suggested that it was *reasonable* to ENQ/DEQ or otherwise serialize code in a RENT module, but only that it was *possible* to do so without compromising an LMOD's RENT attribute. Likewise, when I said a REFR LMOD could be "swapped out", I meant its page(s) could be "stolen" by the O/S at any time without its having first to "back up" the LMOD to a paging dataset or cache. Michael Stein provided an excellent summary of the meanings of REUS, RENT and REFR in his "load module search order and attributes" post. I recommended that ASM modules should always be coded as RSECTs (not as CSECTs) to allow the assembler to trap, whenever possible, any code that could modify itself. AFAIR Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. Chris Poncelet (retired sysprog) On 07/02/2021 16:52, Seymour J Metz wrote: > It's a bit more complicated. First, you can decouple REFR from RENT by using > the linkage editor. Second, you can write code that is reentrant and > refreshable, modifies itself and does not use ENQ/DEQ. However, I suspect > that at some point REFRPR"OT will be mandatory. > > BTW, just because it is possible doesn't mean that it is a reasonable thing > to do; absent compelling reasons otherwise, I would red flag it in a code > review. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Friday, February 5, 2021 9:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > No. RENT implies REUS. Meanwhile RENT *may* be modified IFF an ENQ is > first issued on the code to be modified, provided that code is then > restored to what it was before it was ENQ'd and then DEQ'd. Only REFR > prohibits any code modification (because REFR means that an LMOD can be > swapped out and refreshed from its original copy on DASD, at any time > during execution and without interruption) - and REFR implies RENT > implies REUS, but RENT does not imply REFR. > > > > On 05/02/2021 20:02, Joseph Reichman wrote: >> Sorry to jump in here but can you have rent without reus >> >> >> >>> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: >>> >>> If the module is not REUS then every LOAD will get a different copy. If >>> the module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. >>> Using LOAD, SYNCH, DELETE is left as an excise for the reader. In most >>> cases I would use LINK(X). >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >>> Bernd Oppolzer [bernd.oppol...@t-online.de] >>> Sent: Friday, February 5, 2021 1:41 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: LINK vs LOAD/CALL >>> >>> I would like to add: >>> >>> while LINK is functionally the same as LOAD - CALL - DELETE, >>> there is an important difference: >>> >>> the transfer of control with LINK is known to the operating system, >>> but with LOAD - CALL - DELETE, it is NOT known. >>> In fact, CALL is not a supervisor action, it is simple machine >>> instructions (very cheap). >>> This means that if a module is not RENT and not REUS (for example), >>> a call using LOAD - CALL - DELETE is not safe, because the system does >>> not know that >>> the module is in use. Another subtask can easily call the same module at >>> the same time, >>> if it knows the address, and it will never get another copy. You are >>> responsible yourself >>> for doing things right. >>> >>> With LINK, on the contrary, if the module is not RENT and not REUS, the >>> system >>> will ALWAYS fetch a new copy, when you do another LINK. >>> >>> (There is a "use count" in the control blocks, which is incremented and >>> decremented >>> during LINK processing, but of course not, when doing a CALL). >>> >>> Kind regards >>> >>> Bernd >>> >>> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: I am not a systems programmer. I am a COBOL programmer who knows only enough assembler to be dangerous. What is the "difference" between doing a LOAD and a CALL to perform a dynamic call and doing a LINK? -- 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 >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO
Re: LINK vs LOAD/CALL
doesn’t matter, by the time the code reaches the branch to address, address is a value that will work. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Sunday, February 07, 2021 2:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > On Sun, 7 Feb 2021 21:32:36 +0200, Binyamin Dissen wrote: > > >On Sun, 7 Feb 2021 19:04:16 + "Gibney, Dave" wrote: > >... > >:>Classic "bad" code > >:>IF address = 0 > >:>Determine and store address > >:>End-if > >:>Branch to address > > > Beware TOCTTOU! > > >I guess you can add the case where the value calculated will always calculate > >to the exact same value, such as an address in the module or the value of a > >name/token, where if it is not set, check if it exists and restore it. > > > The test must be performed on a value loaded in temporary storage > or a register, and that value used if non-zero; else loop back and > try again. (Once may not be enough. But limit the number of retries.) > > -- 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: LINK vs LOAD/CALL
On Sun, 7 Feb 2021 17:53:28 +, Seymour J Metz wrote: >... IMHO a warn option would be highly desirable. >Why JOB instead of EXEC? > Good suggestion. How about both; but which dominates? > >From: Paul Gilmartin >Sent: Sunday, February 7, 2021 12:46 PM > >REFRPROT should be an opt-in (but not opt-out) option on the JOB >statement. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
On Sun, 7 Feb 2021 21:32:36 +0200, Binyamin Dissen wrote: >On Sun, 7 Feb 2021 19:04:16 + "Gibney, Dave" wrote: >... >:>Classic "bad" code >:>IF address = 0 >:>Determine and store address >:>End-if >:>Branch to address > Beware TOCTTOU! >I guess you can add the case where the value calculated will always calculate >to the exact same value, such as an address in the module or the value of a >name/token, where if it is not set, check if it exists and restore it. > The test must be performed on a value loaded in temporary storage or a register, and that value used if non-zero; else loop back and try again. (Once may not be enough. But limit the number of retries.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
On Sun, 7 Feb 2021 19:04:16 + "Gibney, Dave" wrote: :>REFR means reloadable without changing function or behavior :>RENT means multiple users without changing function or behavior, :>Classic "bad" code :>IF address = 0 :>Determine and store address :>End-if :>Branch to address :>When refreshed, the address has to be redetermined, but program still works :>And, RENT only sets it once when first encountered. But, program works the same for all callers :>I didn't write it, but one of our interface routines to Adabas has done this for more than 40 years. Which is similar what I wrote: "Only possible if it modifies itself but pays no attention to the modified area" I guess you can add the case where the value calculated will always calculate to the exact same value, such as an address in the module or the value of a name/token, where if it is not set, check if it exists and restore it. :>> -Original Message- :>> From: IBM Mainframe Discussion List On :>> Behalf Of Binyamin Dissen :>> Sent: Sunday, February 07, 2021 10:40 AM :>> To: IBM-MAIN@LISTSERV.UA.EDU :>> Subject: Re: LINK vs LOAD/CALL :>> On Sun, 7 Feb 2021 16:52:55 + Seymour J Metz :>> wrote: :>> :>Second, you can write code that is reentrant and refreshable, modifies :>> itself ... :>> Only possible if it modifies itself but pays no attention to the modified :>> area. :>> Not really relevant. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PRECIS Tape Mapping Program from UNC
Dear Folks, I just put up an old tape mapping program named PRECIS from "UNC", which I presume is the University of North Carolina. The load module was linkedited in 1986, so it is old. But it works beautifully, the report is concise, and it displays the beginning of each data block, which most tape mapping programs don't do. I posted it on File 1004 of the CBT Updates page. www.cbttape.org I am looking to see if anyone has source code for this program, because I try to fix all the tape mapping and tape copying programs to read the largest tape block size possible, and in order to do that, I have to muck with the I/O. It is much easier to do that when you have source code. So if you have source code for the PRECIS tape mapping program, please send it to me, and we can have a better product for everyone to use. Meanwhile, enjoy it the way it is. Below is some sample output from this program. Thank you very much. All the best of everything to all of you... Sincerely, Sam UNC TAPE PRECIS UTILITY--OPTIONS: SKIP 000, PROCESS ALL. VOLUME C500MU, PAGE 001. DATA BLOCK NO. 01: VOL1C500MU SAMGOLOB EDDFCFFFDE444ECDCDDDC444 563135004400021476362000 DATA BLOCK NO. 02: HDR1FILE0001 C500MU00010001 020353 9800IBM OS/VS 370 CCDFCCDC4CFFFDE44FF4CCD4DE6EE4FFF444 8491693500010350044000100010002035309800924062152037 DATA BLOCK NO. 03: HDR2F32728000SBGOLOB1/COPY1 B 0 CCDFCECCDDDCF6CDDEF444C444F4 84926327280002276362113678100020 TAPE MARK NO. 001 ENCOUNTERED AFTER 03 DATA BLOCKS - SMALLEST BLOCK READ WAS 00080 BYTES - LARGEST WAS 00080 BYTES. DATA BLOCK NO. 01: //MVSMODS1 JOB 527TEC000S0003,TEC,CLASS=8,MSGCLASS=5,PRTY=10, DOC FILE 66DEEDDCEF4DDC4FFFECCFFFE6ECC6CDCEE7F6DECCDCEE7F6DDEE7FF6444CDC4CCDC 11452464210162052735300020003B353B33122E8B42733122E5B7938E10B00046306935 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling Facility and z/OS SysPlex LPARs moving to new hardware
You will need to define new cf's along with the existing ones in the cfrm policy and activate it before you move. From: IBM Mainframe Discussion List on behalf of Arye Shemer Sent: Sunday, February 7, 2021 1:34:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Coupling Facility and z/OS SysPlex LPARs moving to new hardware **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Installation I work with is going to move Coupling Facilities and z/OS LPARs to new hardware. To best of my recollections after defining the IODFs for the new systems (z15) which should (could) include definitions for old and new systems.system programmers can rely on system commands to remove CF LPAR and activate the new one on the new hardware. At last my question, is this assumption correct (using System Commands to remove old and activate new CF LPARs) ? I do not expect a list of commands, just approval (or not) :-) Thank you, Arye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
REFR means reloadable without changing function or behavior RENT means multiple users without changing function or behavior, Classic "bad" code IF address = 0 Determine and store address End-if Branch to address When refreshed, the address has to be redetermined, but program still works And, RENT only sets it once when first encountered. But, program works the same for all callers I didn't write it, but one of our interface routines to Adabas has done this for more than 40 years. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Binyamin Dissen > Sent: Sunday, February 07, 2021 10:40 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > On Sun, 7 Feb 2021 16:52:55 + Seymour J Metz > wrote: > > :>Second, you can write code that is reentrant and refreshable, modifies > itself ... > > Only possible if it modifies itself but pays no attention to the modified > area. > > Not really relevant. > > -- > Binyamin Dissen > https://urldefense.com/v3/__http://www.dissensoftware.com__;!!JmPEgB > Y0HMszNaDT!9x6YjT3JlqQJChYD69knAR0J2ywn- > 9fcR3uB0z9gubfishZVSDaKLLIqS9wLHw$ > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > 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: Coupling Facility and z/OS SysPlex LPARs moving to new hardware
Assuming that your active CFRM policy allows structure movement from the old CF LPAR(s) to the new, then yes. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Sunday, February 7th, 2021 at 1:34 PM, Arye Shemer wrote: > Installation I work with is going to move Coupling Facilities and z/OS > > LPARs to new hardware. > > To best of my recollections after defining the IODFs for the new systems > > (z15) > > which should (could) include definitions for old and new systems.system > > programmers can rely on system commands to remove CF LPAR and activate the > > new one on the new hardware. > > At last my question, > > is this assumption correct (using System Commands to remove old and > > activate new CF LPARs) ? > > I do not expect a list of commands, just approval (or not) :-) > > Thank you, > > Arye. > > --- > > 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: LINK vs LOAD/CALL
On Sun, 7 Feb 2021 16:52:55 + Seymour J Metz wrote: :>Second, you can write code that is reentrant and refreshable, modifies itself ... Only possible if it modifies itself but pays no attention to the modified area. Not really relevant. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Coupling Facility and z/OS SysPlex LPARs moving to new hardware
Installation I work with is going to move Coupling Facilities and z/OS LPARs to new hardware. To best of my recollections after defining the IODFs for the new systems (z15) which should (could) include definitions for old and new systems.system programmers can rely on system commands to remove CF LPAR and activate the new one on the new hardware. At last my question, is this assumption correct (using System Commands to remove old and activate new CF LPARs) ? I do not expect a list of commands, just approval (or not) :-) Thank you, Arye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
No, but IMHO a warn option would be highly desirable. Why JOB instead of EXEC? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, February 7, 2021 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On Sun, 7 Feb 2021 16:52:55 +, Seymour J Metz wrote: >..., I suspect that at some point REFRPR"OT will be mandatory. > The effect of REFRPROT has long been enforced for modules loaded from APF libraries. IBM suspects that there are so many dusty-deck modules incorrectly marked REFR in non-APF libraries that REFRPROT would be catastrophic. Does REFRPROT have a "warn" setting? REFRPROT should be an opt-in (but not opt-out) option on the JOB statement. -- 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: LINK vs LOAD/CALL
On Sun, 7 Feb 2021 16:52:55 +, Seymour J Metz wrote: >..., I suspect that at some point REFRPR"OT will be mandatory. > The effect of REFRPROT has long been enforced for modules loaded from APF libraries. IBM suspects that there are so many dusty-deck modules incorrectly marked REFR in non-APF libraries that REFRPROT would be catastrophic. Does REFRPROT have a "warn" setting? REFRPROT should be an opt-in (but not opt-out) option on the JOB statement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
It's a bit more complicated. First, you can decouple REFR from RENT by using the linkage editor. Second, you can write code that is reentrant and refreshable, modifies itself and does not use ENQ/DEQ. However, I suspect that at some point REFRPR"OT will be mandatory. BTW, just because it is possible doesn't mean that it is a reasonable thing to do; absent compelling reasons otherwise, I would red flag it in a code review. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Friday, February 5, 2021 9:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL No. RENT implies REUS. Meanwhile RENT *may* be modified IFF an ENQ is first issued on the code to be modified, provided that code is then restored to what it was before it was ENQ'd and then DEQ'd. Only REFR prohibits any code modification (because REFR means that an LMOD can be swapped out and refreshed from its original copy on DASD, at any time during execution and without interruption) - and REFR implies RENT implies REUS, but RENT does not imply REFR. On 05/02/2021 20:02, Joseph Reichman wrote: > Sorry to jump in here but can you have rent without reus > > > >> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: >> >> If the module is not REUS then every LOAD will get a different copy. If the >> module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using >> LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I >> would use LINK(X). >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> Bernd Oppolzer [bernd.oppol...@t-online.de] >> Sent: Friday, February 5, 2021 1:41 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LINK vs LOAD/CALL >> >> I would like to add: >> >> while LINK is functionally the same as LOAD - CALL - DELETE, >> there is an important difference: >> >> the transfer of control with LINK is known to the operating system, >> but with LOAD - CALL - DELETE, it is NOT known. >> In fact, CALL is not a supervisor action, it is simple machine >> instructions (very cheap). >> This means that if a module is not RENT and not REUS (for example), >> a call using LOAD - CALL - DELETE is not safe, because the system does >> not know that >> the module is in use. Another subtask can easily call the same module at >> the same time, >> if it knows the address, and it will never get another copy. You are >> responsible yourself >> for doing things right. >> >> With LINK, on the contrary, if the module is not RENT and not REUS, the >> system >> will ALWAYS fetch a new copy, when you do another LINK. >> >> (There is a "use count" in the control blocks, which is incremented and >> decremented >> during LINK processing, but of course not, when doing a CALL). >> >> Kind regards >> >> Bernd >> >> >>> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >>> I am not a systems programmer. I am a COBOL programmer who knows only >>> enough assembler to be dangerous. >>> What is the "difference" between doing a LOAD and a CALL to perform a >>> dynamic call and doing a LINK? >>> >>> -- >>> 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 >> >> -- >> 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 > . > -- 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: load module search order and attributes
It is possible to write a module that is refreshable but not read only.
However, it will fail once you turn on REFRPROT, and is bad form even if you
don't.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Michael Stein [m...@zlvfc.com]
Sent: Saturday, February 6, 2021 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: load module search order and attributes
On Fri, Feb 05, 2021 at 03:53:17PM -0500, Joseph Reichman wrote:
> I opened a dcb load library with the same load mod name as the first
> Did an attach DCB= TASKLIB=
>
> Didn’t pick it up from there as the module from the first load lib
> with same name was linked REUS
It helps to know where to look things up:
** module reusability
z/OS Version 2 Release 3
MVS Program Management: User's Guide and Reference
SA23-1393-30
ieab100_v2r3.pdf
see pdf page 48, page 28
nonreusable:
single use only, need a new copy if used (or in use)
serially reusable:
only a single use at a time, later requestors need to wait for use
to complete {ATTACH/LINK/XCTL/SVC 3-exit keep track of module
in use status, note that when using LOAD/CALL/DELETE the system
doesn't t known when you call or return from the module}
{In the case of the system keeping track of the module use, it
may delay start of an execution until the current use is complete}
reenterable (reentrant):
concurent execution by multiple tasks. If modifies it's own
data areas it must do it's own serialization.
refreshable:
all or part of the module can be replaced at any time without notice
by the operating system. *therefore* must not modify itself in
any way.
{** beware **
some module attributes and authority levels force modules to
beloaded into different key storage and/or protected storage.
This may affect fetch access too}
Linkage editor processing of attributes:
refer rent reus are all treated as separate attributes
Binder
only a single attribute and implies/overrides lower attributes
refer > rent > reus > none {guess, doesn't explicitly say}
** module search order
z/OS Version 2 Release 3
MVS Programming: Assembler Services Guide
SA23-1368-30
ieaa600_v2r3.pdf
see pdf page 69, page 43
The search for a load module:
- requesting tasks' load list
- job pack area
- requesting task's task library (and up parent tree of tasklibs)
- steplib
- link pack area
- link library
{I think of joblib/steplib as a tasklib set by the attacher of the
job step task...}
--
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
