Re: LINK vs LOAD/CALL
No, it was my mistake. The code was 'all over the place' and I did not realign the PTR label correctly. Anyways, this thread has run its course and I'm now dropping out of it. Chris Poncelet (r) On 09/02/2021 16:36, Seymour J Metz wrote: > That's not my dog; it comes from Michael Stein. My code did not have a PTR > opcode and had a DC at the end, after the second ..., and yes, if the DC were > in a full page rsect then it would fail. > > > -- > 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: Tuesday, February 9, 2021 12:22 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieab100/reus.htm > > > BTW Your 'refreshable' ... > > PTR DCA(0) > label L R15,PTR > LTR R15,R15 > BNZ CALLIT > ...... Code that always leaves the same value in R15 > STR15,PTR > CALLITBALR R14,R15 > > ... would not assemble with a CC=00 if coded as an *RSECT* methinks. > > Chris Poncelet (retired etc.) > > > > On 08/02/2021 22:47, Seymour J Metz wrote: >> That "therefore" is incorrect. Nor would refreshing my example cause an >> incorrect branch. If you'll give me the URL I'll submit a RCF. >> >> There's now way that z/OS will refresh anything smaller than a page, much >> less smaller than a word. >> >> >> -- >> 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: Monday, February 8, 2021 5:33 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LINK vs LOAD/CALL >> >>>> This is refreshable, and even runs on S/360 >>> PTR DCA(0) >>> label L R15,PTR >>> LTR R15,R15 >>> BNZ CALLIT >>> ...... Code that always leaves the same value in R15 >>> STR15,PTR >>> CALLIT BALR R14,R15 >> According to the manual no. >> >> 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. >> >> So if part of your address got refreshed (to 0) you would then branch >> to some wrong address... >> >> Most likely the way it is/would be implemented it wouldn't just refresh >> a part of a fullword on a fullword boundary. But that's not the what >> the manual says it might do. >> >> The first I saw of REFR was OS/MVT 360. Aactual refreshing was only >> mentioned as action by the machine check handler for storage errors in >> parts of the nucleus. >> >> -- >> 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: LINK vs LOAD/CALL
On Tue, 9 Feb 2021 11:52:31 -0500, Joseph Reichman wrote: >One caveat Had an experience running under test >The program I was running had the same name as the one I was attaching to > >The attach had taskib and dcb pointing to a different library because the >parent task was linked as REUS it attached the copy in core >Had to relink without REUS to get library from DCB= TASKLIB= >Thanks > It's a fundamental design deficiency ever since OS/360, that one can't simply load an object from a fully-qualified pathname. E.g." //STEP EXEC PGM='SYS1.LINKLIB(IEFBR14)' or: //STEP EXEC 'SYS1.SAMPLIB(ASMACLG)' or: //STEP EXEC PGM=IRXJCL,PARM='SYS1.SAMPLIB(REXXSAMP)' (Is my UNIX showing?) -- 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
One caveat Had an experience running under test The program I was running had the same name as the one I was attaching to The attach had taskib and dcb pointing to a different library because the parent task was linked as REUS it attached the copy in core Had to relink without REUS to get library from DCB= TASKLIB= Thanks > On Feb 7, 2021, at 12:53 PM, Seymour J Metz wrote: > > 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 -- 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
That's not my dog; it comes from Michael Stein. My code did not have a PTR opcode and had a DC at the end, after the second ..., and yes, if the DC were in a full page rsect then it would fail. -- 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: Tuesday, February 9, 2021 12:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieab100/reus.htm BTW Your 'refreshable' ... PTR DCA(0) label L R15,PTR LTR R15,R15 BNZ CALLIT ...... Code that always leaves the same value in R15 STR15,PTR CALLITBALR R14,R15 ... would not assemble with a CC=00 if coded as an *RSECT* methinks. Chris Poncelet (retired etc.) On 08/02/2021 22:47, Seymour J Metz wrote: > That "therefore" is incorrect. Nor would refreshing my example cause an > incorrect branch. If you'll give me the URL I'll submit a RCF. > > There's now way that z/OS will refresh anything smaller than a page, much > less smaller than a word. > > > -- > 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: Monday, February 8, 2021 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > >>> This is refreshable, and even runs on S/360 >> PTR DCA(0) >> label L R15,PTR >> LTR R15,R15 >> BNZ CALLIT >> ...... Code that always leaves the same value in R15 >> STR15,PTR >> CALLIT BALR R14,R15 > According to the manual no. > > 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. > > So if part of your address got refreshed (to 0) you would then branch > to some wrong address... > > Most likely the way it is/would be implemented it wouldn't just refresh > a part of a fullword on a fullword boundary. But that's not the what > the manual says it might do. > > The first I saw of REFR was OS/MVT 360. Aactual refreshing was only > mentioned as action by the machine check handler for storage errors in > parts of the nucleus. > > -- > 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: LINK vs LOAD/CALL
On Tue, 9 Feb 2021 10:13:36 -0500, Peter Relson wrote: >Regarding page-protecting only the "whole pages", there really are only >two viable choices. >One is to do what we do; the other is to round up the module to a >whole-page multiple. > Or, leave the rest of the page unused, or use it only for other modules with similar charactristics. >The latter can conceivably break applications. > >Other options that you might submit an RFE for, but that are not "safe" if >you have code that is nominally reentrant but does (let's hope correctly) >store into itself are: >-- always put reentrant code into key 0 storage, regardless of APF state >(this does happen for a KEY=NINE task) >-- always page-protect reentrant code >either of these will break non-key-0 reentrant code that stores into >itself. > You're discussing RENT. The concern should be with REFR. -- 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
Regarding page-protecting only the "whole pages", there really are only two viable choices. One is to do what we do; the other is to round up the module to a whole-page multiple. The latter can conceivably break applications. Other options that you might submit an RFE for, but that are not "safe" if you have code that is nominally reentrant but does (let's hope correctly) store into itself are: -- always put reentrant code into key 0 storage, regardless of APF state (this does happen for a KEY=NINE task) -- always page-protect reentrant code either of these will break non-key-0 reentrant code that stores into itself. I wonder if anything in zOS considers that a non-LPA page of a REFR module need not be backed to paging, because if it is needed to be refreshed, can the operating system really count on being able to reload the page from the original load library? The operating system cannot count on being able to reload from the original load library. Yes it's true that if the module were paged out it would not need to be paged out again. I suspect that remembering that would be extremely problematic (in terms of the space needed to track such situations). In other words, does REFR mean anything to the OS other than the possibility of loading the module into page protected storage? No it doesn't, and prior to REFRPROT I think that it meant nothing. If it were up to me REFRPROT would be the default, but IBM has better data than I do and doesn't agree. That would be incompatible. So unless there was data to prove that nothing would break (and that no one would care about the extra cycles of page-protecting). I cannot imagine ever changing to make REFRPROT be the default. A disturbing number of posts seem to ignore the fact that a significant part of the reason that we still have a z/OS operating system is because of the impressive amount of long-term compatibility that it provides. And, yes, that does put burden on new things to deal with decisions made long ago that we dare not change. We do live with the "sins" of our past design decisions. Yes, of course, we do make incompatible changes when deemed appropriate. The last I looked, MVS does not write back a modified PLPA page before stealing it. I don't know how difficult it would be to do the same for full page RENT code. MVS does not ever page out a PLPA page aside from what it does during IPL. This only works because the bounds of LPA are unchangeable within an IPL and the storage can be mapped to the page data set that contains the initial PLPA pages. If you modify a PLPA page you'd better make sure it's page-fixed. 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: LINK vs LOAD/CALL
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieab100/reus.htm BTW Your 'refreshable' ... PTR DCA(0) label L R15,PTR LTR R15,R15 BNZ CALLIT ...... Code that always leaves the same value in R15 STR15,PTR CALLITBALR R14,R15 ... would not assemble with a CC=00 if coded as an *RSECT* methinks. Chris Poncelet (retired etc.) On 08/02/2021 22:47, Seymour J Metz wrote: > That "therefore" is incorrect. Nor would refreshing my example cause an > incorrect branch. If you'll give me the URL I'll submit a RCF. > > There's now way that z/OS will refresh anything smaller than a page, much > less smaller than a word. > > > -- > 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: Monday, February 8, 2021 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > >>> This is refreshable, and even runs on S/360 >> PTR DCA(0) >> label L R15,PTR >> LTR R15,R15 >> BNZ CALLIT >> ...... Code that always leaves the same value in R15 >> STR15,PTR >> CALLIT BALR R14,R15 > According to the manual no. > > 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. > > So if part of your address got refreshed (to 0) you would then branch > to some wrong address... > > Most likely the way it is/would be implemented it wouldn't just refresh > a part of a fullword on a fullword boundary. But that's not the what > the manual says it might do. > > The first I saw of REFR was OS/MVT 360. Aactual refreshing was only > mentioned as action by the machine check handler for storage errors in > parts of the nucleus. > > -- > 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: LINK vs LOAD/CALL
The refreshable code in OS/360 ran in key 0. There wa no APF, and Fetch didn't look at the RENT attribute. Fetch loaded code from the link list into SP 252, which was key 0, but some of that code was self modifying. -- 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: Monday, February 8, 2021 5:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On Mon, 8 Feb 2021 22:35:13 +, Seymour J Metz wrote: >IBM initially only used REFR in the Machine Check Handler (MCH), which could >recover from a parity error in, e.g., a transient SVC, by reading in a fresh >copy. There was no non-modifiable storage at the time. > Couldn't storage keys prevent modification? >REFR stopped being relevant in SVS, and only became relevant with the support >of REFRPROT. > Weren't REFR modules in APF-authorized libraries loaded into a protected subpool? >What happens if you have an RSECT but don't bind with REFR? > Binder or assembler should mark RSECTs REFR. That may require scatter-loading. -- 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
That "therefore" is incorrect. Nor would refreshing my example cause an incorrect branch. If you'll give me the URL I'll submit a RCF. There's now way that z/OS will refresh anything smaller than a page, much less smaller than a word. -- 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: Monday, February 8, 2021 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL > > This is refreshable, and even runs on S/360 > > PTR DCA(0) > label L R15,PTR > LTR R15,R15 > BNZ CALLIT > ...... Code that always leaves the same value in R15 > STR15,PTR > CALLIT BALR R14,R15 According to the manual no. 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. So if part of your address got refreshed (to 0) you would then branch to some wrong address... Most likely the way it is/would be implemented it wouldn't just refresh a part of a fullword on a fullword boundary. But that's not the what the manual says it might do. The first I saw of REFR was OS/MVT 360. Aactual refreshing was only mentioned as action by the machine check handler for storage errors in parts of the nucleus. -- 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 Mon, 8 Feb 2021 22:35:13 +, Seymour J Metz wrote: >IBM initially only used REFR in the Machine Check Handler (MCH), which could >recover from a parity error in, e.g., a transient SVC, by reading in a fresh >copy. There was no non-modifiable storage at the time. > Couldn't storage keys prevent modification? >REFR stopped being relevant in SVS, and only became relevant with the support >of REFRPROT. > Weren't REFR modules in APF-authorized libraries loaded into a protected subpool? >What happens if you have an RSECT but don't bind with REFR? > Binder or assembler should mark RSECTs REFR. That may require scatter-loading. -- 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
Discarded from main storage. If it were up to me REFRPROT would be the default, but IBM has better data than I do and doesn't agree. The last I looked, MVS does not write back a modified PLPA page before stealing it. I don't know how difficult it would be to do the same for full page RENT code. -- 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: Monday, February 8, 2021 5:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On Mon, 8 Feb 2021 21:47:06 +, Seymour J Metz wrote: >AFAIK nothing from OS/360 through z/OS has ever discarded modified pages >containing refreshable coded other than PLPA and SVC transient areas. > "Discarded" from main storage or from page data sets? A Modest Proposal: o Retain page data set frames for REFR modules indefinitely. o When a main storage page of a REFR module is reassigned and a page data set copy exists, don't write it again. Do it! Programmers will learn quickly enough and paging I/O will be optimized. And programmers will beg for REFRPROT. -- 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 Mon, 8 Feb 2021 17:15:36 -0500, Steve Smith wrote: > >z/OS (and ancestors) already decided RENT means a module can be loaded into >non-modifiable storage, so what is the point of REFR anyway? > Not quite. A RENT module may modify itself provided that it serializes (Lock, ENQ, CS, ...) to protect against other threads. A REFR module can always be reloaded from a pristine DASD copy. >And technically, a non-self-modifying program can be made non-reentrant... >I've seen it happen by accident. A "clever" programmer used a common >global area for a few non-global variables, leading to the >all-too-predictable unpredictable results when you screw up multi-tasking. > +1 -- 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
IBM initially only used REFR in the Machine Check Handler (MCH), which could recover from a parity error in, e.g., a transient SVC, by reading in a fresh copy. There was no non-modifiable storage at the time. REFR stopped being relevant in SVS, and only became relevant with the support of REFRPROT. What happens if you have an RSECT but don't bind with REFR? Yes, what makes a program reentrant is proper serialization of shared data, whether4 those data be in the module or elsewhere. What some perceives as nits become important when somebody breaks things through not understanding them. Getting serialization wrong can cost your employer a lot of money, or worse. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Monday, February 8, 2021 5:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL That's what I've been wondering. If, as in 99.99% of the cases, a REFR module does *not* modify itself, then ASM/RSM will know that when it matters, and will *not* page it out (after the first time). Logically, it would seem REFR would imply that OK, I know I've diddled myself, but it's OK, no need to page me out. And that is nonsense. z/OS (and ancestors) already decided RENT means a module can be loaded into non-modifiable storage, so what is the point of REFR anyway? They should have made the (or an) attribute NMOD, so there wouldn't be any need for endless discussion of what reentrant and refreshable really mean, practically and technically. And yes, technically, both can be implemented in a self-modifying program, given certain constraints. But practically, RENT or REFR modules at least some times are prevented from being modified. And technically, a non-self-modifying program can be made non-reentrant... I've seen it happen by accident. A "clever" programmer used a common global area for a few non-global variables, leading to the all-too-predictable unpredictable results when you screw up multi-tasking. sas On Mon, Feb 8, 2021 at 4:32 PM Binyamin Dissen wrote: > ... > In other words, does REFR mean anything to the OS other than the > possibility > of loading the module into page protected storage? > > -- 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
> > This is refreshable, and even runs on S/360 > > PTR DCA(0) > label L R15,PTR > LTR R15,R15 > BNZ CALLIT > ...... Code that always leaves the same value in R15 > STR15,PTR > CALLIT BALR R14,R15 According to the manual no. 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. So if part of your address got refreshed (to 0) you would then branch to some wrong address... Most likely the way it is/would be implemented it wouldn't just refresh a part of a fullword on a fullword boundary. But that's not the what the manual says it might do. The first I saw of REFR was OS/MVT 360. Aactual refreshing was only mentioned as action by the machine check handler for storage errors in parts of the nucleus. -- 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
That's what I've been wondering. If, as in 99.99% of the cases, a REFR module does *not* modify itself, then ASM/RSM will know that when it matters, and will *not* page it out (after the first time). Logically, it would seem REFR would imply that OK, I know I've diddled myself, but it's OK, no need to page me out. And that is nonsense. z/OS (and ancestors) already decided RENT means a module can be loaded into non-modifiable storage, so what is the point of REFR anyway? They should have made the (or an) attribute NMOD, so there wouldn't be any need for endless discussion of what reentrant and refreshable really mean, practically and technically. And yes, technically, both can be implemented in a self-modifying program, given certain constraints. But practically, RENT or REFR modules at least some times are prevented from being modified. And technically, a non-self-modifying program can be made non-reentrant... I've seen it happen by accident. A "clever" programmer used a common global area for a few non-global variables, leading to the all-too-predictable unpredictable results when you screw up multi-tasking. sas On Mon, Feb 8, 2021 at 4:32 PM Binyamin Dissen wrote: > ... > In other words, does REFR mean anything to the OS other than the > possibility > of loading the module into page protected storage? > > -- 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 Mon, 8 Feb 2021 21:47:06 +, Seymour J Metz wrote: >AFAIK nothing from OS/360 through z/OS has ever discarded modified pages >containing refreshable coded other than PLPA and SVC transient areas. > "Discarded" from main storage or from page data sets? A Modest Proposal: o Retain page data set frames for REFR modules indefinitely. o When a main storage page of a REFR module is reassigned and a page data set copy exists, don't write it again. Do it! Programmers will learn quickly enough and paging I/O will be optimized. And programmers will beg for REFRPROT. -- 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
AFAIK nothing from OS/360 through z/OS has ever discarded modified pages containing refreshable coded other than PLPA and SVC transient areas. -- 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: Monday, February 8, 2021 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On Mon, 8 Feb 2021 18:44:39 + "Farley, Peter x23353" <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: :>There is a potentially meaningful performance hit only if the load module / program object is marked refreshable. For the non-refreshable case, the one--time performance hist (the first time ST R15,PTR is executed) is trivial compared to the potential cost of getting the called program address. :>Don't mark such code refreshable and you will be fine. I wonder if anything in zOS considers that a non-LPA page of a REFR module need not be backed to paging, because if it is needed to be refreshed, can the operating system really count on being able to reload the page from the original load library? In other words, does REFR mean anything to the OS other than the possibility of loading the module into page protected storage? -- Binyamin Dissen http://secure-web.cisco.com/17VkzUCiamsLNbqL16Ks3l80TX5DrVCpaXsyqVd6hNoyMeZXLKKsJQRHxu5zpQ_3GDPTowwRfzUUvRyGXtBL7jy2aejzQHLYcLu3YLbk2L2C05ypPEWGKfPGbWPWf_yhpXd5u7q_pwq39as9KTwvmDbG33sOVw1j2adrzWD_U010AtCKzuUrrDz6P8sCXJxOZ3dawEvrpBLZALd3VR5Hd5REKsYyOSaDEWWrMjlaXhhidE5wqmMB1UoY5uHbZef-4T70pw2dCvlVFS99J496WdhbBuqVtO10YD51eqdiMuUpXoumiQHN-dBnhUvkPgOn0rTKFfBG9YAWpypOPCHSEMw8vnEToF8FH8Raxlom5WN0cmtnrxPSVwoRg-Mn6C_BAXjigY4xCZam7xn8JxFMbsII6sBC2WW1UoFkOCL-Wbhx8J7GcW_BHk6laWLgWTZ2J/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
On Mon, 8 Feb 2021 18:44:39 + "Farley, Peter x23353" <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: :>There is a potentially meaningful performance hit only if the load module / program object is marked refreshable. For the non-refreshable case, the one--time performance hist (the first time ST R15,PTR is executed) is trivial compared to the potential cost of getting the called program address. :>Don't mark such code refreshable and you will be fine. I wonder if anything in zOS considers that a non-LPA page of a REFR module need not be backed to paging, because if it is needed to be refreshed, can the operating system really count on being able to reload the page from the original load library? In other words, does REFR mean anything to the OS other than the possibility of loading the module into page protected storage? -- 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
Re: LINK vs LOAD/CALL
The rule of thumb is to look at your hot spots first. If the monitoring doesn't narrow it down enough, you can always use SLIP PER SA on the address range. -- 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: Monday, February 8, 2021 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Thanks a lot, I didn't think of this ... of course it is very important when fixing such SIIS issues to check if the store is indeed done a significant part of the time or - as in this case - only once a day. In my customer's case there were/are other places to fix, but probably not these. Kind regards Bernd Am 08.02.2021 um 19:44 schrieb Farley, Peter x23353: > There is a potentially meaningful performance hit only if the load module / > program object is marked refreshable. For the non-refreshable case, the > one--time performance hist (the first time ST R15,PTR is executed) is trivial > compared to the potential cost of getting the called program address. > > Don't mark such code refreshable and you will be fine. > > This is an old, old technique used in probably thousands or more of "dynamic > call" assembler stub programs. Yes there are modern, reentrant and > refreshable techniques now - name/token pair comes to mind - but they are not > without their own cost in CPU time. > > I wouldn't call the technique ugly, just necessary and (relatively) efficient. > > If it ain't broke, don't fix it. > > Peter > -- 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
Thanks a lot, I didn't think of this ... of course it is very important when fixing such SIIS issues to check if the store is indeed done a significant part of the time or - as in this case - only once a day. In my customer's case there were/are other places to fix, but probably not these. Kind regards Bernd Am 08.02.2021 um 19:44 schrieb Farley, Peter x23353: There is a potentially meaningful performance hit only if the load module / program object is marked refreshable. For the non-refreshable case, the one--time performance hist (the first time ST R15,PTR is executed) is trivial compared to the potential cost of getting the called program address. Don't mark such code refreshable and you will be fine. This is an old, old technique used in probably thousands or more of "dynamic call" assembler stub programs. Yes there are modern, reentrant and refreshable techniques now - name/token pair comes to mind - but they are not without their own cost in CPU time. I wouldn't call the technique ugly, just necessary and (relatively) efficient. If it ain't broke, don't fix it. Peter -- 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
There is a potentially meaningful performance hit only if the load module / program object is marked refreshable. For the non-refreshable case, the one--time performance hist (the first time ST R15,PTR is executed) is trivial compared to the potential cost of getting the called program address. Don't mark such code refreshable and you will be fine. This is an old, old technique used in probably thousands or more of "dynamic call" assembler stub programs. Yes there are modern, reentrant and refreshable techniques now - name/token pair comes to mind - but they are not without their own cost in CPU time. I wouldn't call the technique ugly, just necessary and (relatively) efficient. If it ain't broke, don't fix it. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, February 8, 2021 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL EXTERNAL EMAIL My original code had the DC after everything else. But if the DC is too close to the code, then there will be a performance hit. Even if not, it's ugly. Not everything that is possible is desirable. -- From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gibney, Dave [gib...@wsu.edu] Sent: Monday, February 8, 2021 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Would > This is refreshable, and even runs on S/360 PTR DCA(0) label L R15,PTR LTR R15,R15 BNZ CALLIT ......Code that always leaves the same value in R15 STR15,PTR CALLIT BALR R14,R15 Still incur cache flush? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Sunday, February 07, 2021 6:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
On Feb 8, 2021, at 12:04 PM, Seymour J Metz wrote: > > My original code had the DC after everything else. But if the DC is too close > to the code, then there will be a performance hit. Even if not, it's ugly. > Not everything that is possible is desirable. > The ugliness may be more desirable than loading and deleting the called module every time this module is called. -- Pew, Curtis G curtis@austin.utexas.edu -- 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
My original code had the DC after everything else. But if the DC is too close to the code, then there will be a performance hit. Even if not, it's ugly. Not everything that is possible is desirable. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gibney, Dave [gib...@wsu.edu] Sent: Monday, February 8, 2021 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Would > This is refreshable, and even runs on S/360 PTR DCA(0) label L R15,PTR LTR R15,R15 BNZ CALLIT ......Code that always leaves the same value in R15 STR15,PTR CALLIT BALR R14,R15 Still incur cache flush? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Sunday, February 07, 2021 6:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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 > https://secure-web.cisco.com/1feWvZFsSbJts0NYF-Q8Nluq95tL0Trk6hBO-asOPn6RuZI-vrFaXbFBZR88WZMWJ9fWoUJVt5UWMatlnv4Fgscw32j0ohjz4y1d0UWo0dULpdUa0-i0L9_dXrsdLuHp0E_-ANQpsncpn-EbBnJPhs6OvNh2f3qCXJ0opU-GoWbU5Pp2Ei-EKyhizB4Bx2O2nq7UFOGursLHfpGnX86WxvjRzUYAymVYupTTeqgvyUZmRNgIz5vctuUG0BJxQfzAdFo_jPh5OXXS2pl37gZ9Kxu1qbKAZhqj0naADAs5rhrSz86F2BdXP8OHqYLipoYl2RJ8BPOTSBDrIpyML6jHHhWCNdmOi9jUUOMPzXyVKafx2ic6MZ2-QVMpCdS7OywKQkZG4kwq7zt-H335Fe3KZnberzP9gdoP4DHKV8rerjx7QM2Ful-EgFMPM8ENRRGEb_2P5G7aTa_NvPv3ohoqSSA/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F%2Asmetz3__%3Bfg%21%21JmPEg > BY0HMszNaDT!- > 1NaByIe2DdFVQi57azbuR3UW5HAMXlA4KDajF5k5WLAnbGJyoxt244VTE368g > $ > > > 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 > https://secure-web.cisco.com/1fCQGE2F7JizPmib2Jd_2oHFLyT1Bng991szujyCDYg8NGuW5abZWei81QR8X4VjuZblH4bJdDOJCKcY7uVOPk3Jyga9z6Pl5A-tKJw_2Mym2Vfma6Sq_9vdM1iSb9u5CEmx0BKFd4B8_dxYgp1lpLj3FcnQfL-Wz8TYAdvU8IcFSFE-Xp_dx3Wr4jtgX9itPATHeDlZAVwv_keub2oL7WiIb9OFVTAdHKYZYdUZ-y4ydSbtKC_J5lzeuv4Y_jRyVP4ieQdDwOqxhrFYoD59LEO8IjIauiS_Uxx1SgKHH6RLXoInWkPIMi0Xy2S-0xq0c47GEut3-QKOL5ug2H4N-nYRHiyKHK2Mf8RMnxsU63ulvpFRJ6SXyXELrUokXGiT77YnmzW-7PMGPM_PEn68pciV3s4pZk5iGFVDKrvOCFvKxnmSoCqIN167CKM5IHF0ofvO1S4iZkQDd0i6_oIpXgA/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fsecure- > web.cisco.com/19fzBBFfAFBx8PysD0V3qJwF9qE3g50- > el2X9G9hk1S6e6J1OJCsS3iW5Z4sW_eIxmVeSUtphiZ1F_hVA17R0eQ0sISoKma > je1LKLxW5hXXG57Bhp2jgb7tfsyTUCz7uR3oi_3QvypHyqrkZbk90NkCCElTsVY_ > WlQLUN3ZGkDG1kO6WKuK6QjZMrhjWBiYf0C9yl8O8I4qv3EpHVq2VRzt08kpx > pmxsg6gnybjtHX8YvBuUnV69On_Zzc0LY2kT7e31qhCg19eAfUSCspghB948WQ > 7TW-XVS3W0hjnawFDJuSq_Gu6Ik-pJsBZ9JBai6AHJCbw- > 0jDqyvmh1mpiJaD4SemvF8t211o_Xhkk4- > K9gYDgDLDpWbiole96yIwNk6hI6rfM33dkqiO- > w6cJY6yIpcdBe1cjlMlsHJsUJGWjQHoOCTBflbOxTayrH2erW/http*3A*2F*2Fw > ww.dissensoftware.com__;JSUl!!JmPEgBY0HMszNaDT!- > 1NaByIe2DdFVQi57azbuR3UW5HAMXlA4KDajF5k5WLAnbGJyoxt2452VV_WR > A$ > > 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 / archi
Re: LINK vs LOAD/CALL
There are cases wher that code is bulletproof. But it's still ugly. -- 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: Monday, February 8, 2021 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL On 2021-02-08, at 09:59:44, Seymour J Metz wrote: > > If the calculated address is always the same then there is no TOCTTOU issue, > but I still consider it bad form. > As wrtten, no TOCTTOU. But if the address is re-fetched elsewhere in the module, TOCTTOU threatens. The test must be performed not just once at entry, but at every reference. > >> 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! -- 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 2021-02-08, at 09:59:44, Seymour J Metz wrote: > > If the calculated address is always the same then there is no TOCTTOU issue, > but I still consider it bad form. > As wrtten, no TOCTTOU. But if the address is re-fetched elsewhere in the module, TOCTTOU threatens. The test must be performed not just once at entry, but at every reference. > >> 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! -- 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 Feb 8, 2021, at 11:38 AM, Gibney, Dave wrote: > > > PTR DCA(0) > label L R15,PTR > LTR R15,R15 > BNZ CALLIT > ......Code that always > leaves the same value in R15 > STR15,PTR > CALLIT BALR R14,R15 > > Still incur cache flush? If PTR is in the same cache line as your code, then yes. -- Pew, Curtis G curtis@austin.utexas.edu -- 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
Would > This is refreshable, and even runs on S/360 PTR DCA(0) label L R15,PTR LTR R15,R15 BNZ CALLIT ......Code that always leaves the same value in R15 STR15,PTR CALLIT BALR R14,R15 Still incur cache flush? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Sunday, February 07, 2021 6:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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 > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY0HMszNaDT!- > 1NaByIe2DdFVQi57azbuR3UW5HAMXlA4KDajF5k5WLAnbGJyoxt244VTE368g > $ > > > 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 > https://urldefense.com/v3/__http://secure- > web.cisco.com/19fzBBFfAFBx8PysD0V3qJwF9qE3g50- > el2X9G9hk1S6e6J1OJCsS3iW5Z4sW_eIxmVeSUtphiZ1F_hVA17R0eQ0sISoKma > je1LKLxW5hXXG57Bhp2jgb7tfsyTUCz7uR3oi_3QvypHyqrkZbk90NkCCElTsVY_ > WlQLUN3ZGkDG1kO6WKuK6QjZMrhjWBiYf0C9yl8O8I4qv3EpHVq2VRzt08kpx > pmxsg6gnybjtHX8YvBuUnV69On_Zzc0LY2kT7e31qhCg19eAfUSCspghB948WQ > 7TW-XVS3W0hjnawFDJuSq_Gu6Ik-pJsBZ9JBai6AHJCbw- > 0jDqyvmh1mpiJaD4SemvF8t211o_Xhkk4- > K9gYDgDLDpWbiole96yIwNk6hI6rfM33dkqiO- > w6cJY6yIpcdBe1cjlMlsHJsUJGWjQHoOCTBflbOxTayrH2erW/http*3A*2F*2Fw > ww.dissensoftware.com__;JSUl!!JmPEgBY0HMszNaDT!- > 1NaByIe2DdFVQi57azbuR3UW5HAMXlA4KDajF5k5WLAnbGJyoxt2452VV_WR > A$ > > 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 -- 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 Mon, 8 Feb 2021 17:02:01 +, Farley, Peter x23353 wrote: >Obvious application-level solution: Make sure your program occupies whole >pages by adding adjusted DC XL at the end to get to a 4096-byte boundary. > Length is limited to 256. With hardware generations, pages get larger >-Original Message- >From: On Behalf Of Charles Mills >Sent: Monday, February 8, 2021 11:57 AM > >Storage protection is page by page. So ... design tradeoff decision: > >- Leave any part of the program that occupies a partial page unprotected. >- "Waste" the remainder of the partially-occupied page. > >IBM obviously chose the former. > Half-assed implementation. And Key 0 exemption? But some kernel code is historically or necessarily self-modifying. A co-worker once (successfully) claimed an exemption from our REFR coding standard, arguing (accurately) that his code never ran in a multi-threaded context. But ObEmerson. What is the performance tradeoff between voiding the I-Cache and GETMAIN/FREEMAIN for subroutine ENTRY/RETURN? > >-Original Message- >From: Seymour J Metz >Sent: Monday, February 8, 2021 8:51 AM > >> Therefore, any parts of the program that are on partial pages are not >page-protected. > >Ouch! Why? > > >From Peter Relson [rel...@us.ibm.com] >Sent: Monday, February 8, 2021 9:13 AM > > >The effect of REFRPROT has long been enforced for modules loaded from APF >libraries. > > >Only for non-key-0 programs. Putting code into key 0 storage is not all that >REFRPROT does. > > >Does REFRPROT have a "warn" setting? > >No. What would it warn about? That you loaded a refreshable program? You can't >know it won't work until it doesn't work. It is easy enough to scan your >libraries for things that are marked refreshable. > Harder to detect self-modification. > >But now there is an intrinsic penalty from mixing I-cache and D-cache but >presumably not enough to merit changing. -- 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.
When you design an OS you can do it that way ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 8, 2021 9:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. Why not have a separate subpool for page-protected storage with Fetch enabling store temporarily? -- 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.
Why not have a separate subpool for page-protected storage with Fetch enabling store temporarily? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Monday, February 8, 2021 11:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. Storage protection is page by page. So ... design tradeoff decision: - Leave any part of the program that occupies a partial page unprotected. - "Waste" the remainder of the partially-occupied page. IBM obviously chose the former. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 8, 2021 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. > Therefore, any parts of the program that are on partial pages are not page-protected. Ouch! Why? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Monday, February 8, 2021 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. The effect of REFRPROT has long been enforced for modules loaded from APF libraries. Only for non-key-0 programs. Putting code into key 0 storage is not all that REFRPROT does. Does REFRPROT have a "warn" setting? No. What would it warn about? That you loaded a refreshable program? You can't know it won't work until it doesn't work. It is easy enough to scan your libraries for things that are marked refreshable. ... one of our interface routines to Adabas has done this for more than 40 years. But now there is an intrinsic penalty from mixing I-cache and D-cache but presumably not enough to merit changing. Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. If not key 0, yes. If key 0, only if executing within one of the full pages of the load module. If the module storage occupies a partial page, that partial page is not protected: "Use the REFRPROT statement type to specify that REFR programs are protected from modification by placing them in key 0, non-fetch protected storage, and page protecting the full pages. Therefore, any parts of the program that are on partial pages are not page-protected." 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 -- 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.
Obvious application-level solution: Make sure your program occupies whole pages by adding adjusted DC XL at the end to get to a 4096-byte boundary. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Monday, February 8, 2021 11:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. Storage protection is page by page. So ... design tradeoff decision: - Leave any part of the program that occupies a partial page unprotected. - "Waste" the remainder of the partially-occupied page. IBM obviously chose the former. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 8, 2021 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. > Therefore, any parts of the program that are on partial pages are not page-protected. Ouch! Why? -- Shmuel (Seymour J.) Metz https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!apqdxr2kgy4OgUVhbDDDdXnsbRfElo2axM6Vn6NTRjbtS69vfcQNi7VAwPYOgk9z7iWnlA$ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Monday, February 8, 2021 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. The effect of REFRPROT has long been enforced for modules loaded from APF libraries. Only for non-key-0 programs. Putting code into key 0 storage is not all that REFRPROT does. Does REFRPROT have a "warn" setting? No. What would it warn about? That you loaded a refreshable program? You can't know it won't work until it doesn't work. It is easy enough to scan your libraries for things that are marked refreshable. ... one of our interface routines to Adabas has done this for more than 40 years. But now there is an intrinsic penalty from mixing I-cache and D-cache but presumably not enough to merit changing. Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. If not key 0, yes. If key 0, only if executing within one of the full pages of the load module. If the module storage occupies a partial page, that partial page is not protected: "Use the REFRPROT statement type to specify that REFR programs are protected from modification by placing them in key 0, non-fetch protected storage, and page protecting the full pages. Therefore, any parts of the program that are on partial pages are not page-protected." Peter Relson z/OS Core Technology Design -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
If the calculated address is always the same then there is no TOCTTOU issue, but I still consider it bad form. -- 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: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.
Storage protection is page by page. So ... design tradeoff decision: - Leave any part of the program that occupies a partial page unprotected. - "Waste" the remainder of the partially-occupied page. IBM obviously chose the former. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 8, 2021 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. > Therefore, any parts of the program that are on partial pages are not page-protected. Ouch! Why? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Monday, February 8, 2021 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. The effect of REFRPROT has long been enforced for modules loaded from APF libraries. Only for non-key-0 programs. Putting code into key 0 storage is not all that REFRPROT does. Does REFRPROT have a "warn" setting? No. What would it warn about? That you loaded a refreshable program? You can't know it won't work until it doesn't work. It is easy enough to scan your libraries for things that are marked refreshable. ... one of our interface routines to Adabas has done this for more than 40 years. But now there is an intrinsic penalty from mixing I-cache and D-cache but presumably not enough to merit changing. Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. If not key 0, yes. If key 0, only if executing within one of the full pages of the load module. If the module storage occupies a partial page, that partial page is not protected: "Use the REFRPROT statement type to specify that REFR programs are protected from modification by placing them in key 0, non-fetch protected storage, and page protecting the full pages. Therefore, any parts of the program that are on partial pages are not page-protected." 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 -- 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
Even where there is no perfomance hit I would consider it bad form. -- 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: Monday, February 8, 2021 3:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Thanks for that. I would like to add, that I was working for a customer which has the first coding at very many places in almost every module, because it is included in a global macro. The problem with modern processors is, that if the location PTR to store the address is in the same cache line (that is, less than 256 byte apart from the place where the ST operation is), you will get the I-cache invalidated, which leads to severe performance issues. The customer observed this by significant performance degradation in the LPAR where those ASSEMBLER programs are running. We then had to rework (at least recompile, after macro change) all these several thousand programs to remedy the problem. The problem is known as SIIS (store into instruction stream). Kind regards Bernd Am 08.02.2021 um 03:38 schrieb Seymour J Metz: > 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 -- 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.
> Therefore, any parts of the program that are on partial pages are not > page-protected. Ouch! Why? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Monday, February 8, 2021 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL. The effect of REFRPROT has long been enforced for modules loaded from APF libraries. Only for non-key-0 programs. Putting code into key 0 storage is not all that REFRPROT does. Does REFRPROT have a "warn" setting? No. What would it warn about? That you loaded a refreshable program? You can't know it won't work until it doesn't work. It is easy enough to scan your libraries for things that are marked refreshable. ... one of our interface routines to Adabas has done this for more than 40 years. But now there is an intrinsic penalty from mixing I-cache and D-cache but presumably not enough to merit changing. Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. If not key 0, yes. If key 0, only if executing within one of the full pages of the load module. If the module storage occupies a partial page, that partial page is not protected: "Use the REFRPROT statement type to specify that REFR programs are protected from modification by placing them in key 0, non-fetch protected storage, and page protecting the full pages. Therefore, any parts of the program that are on partial pages are not page-protected." 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: LINK vs LOAD/CALL.
The effect of REFRPROT has long been enforced for modules loaded from APF libraries. Only for non-key-0 programs. Putting code into key 0 storage is not all that REFRPROT does. Does REFRPROT have a "warn" setting? No. What would it warn about? That you loaded a refreshable program? You can't know it won't work until it doesn't work. It is easy enough to scan your libraries for things that are marked refreshable. ... one of our interface routines to Adabas has done this for more than 40 years. But now there is an intrinsic penalty from mixing I-cache and D-cache but presumably not enough to merit changing. Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. If not key 0, yes. If key 0, only if executing within one of the full pages of the load module. If the module storage occupies a partial page, that partial page is not protected: "Use the REFRPROT statement type to specify that REFR programs are protected from modification by placing them in key 0, non-fetch protected storage, and page protecting the full pages. Therefore, any parts of the program that are on partial pages are not page-protected." 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: LINK vs LOAD/CALL
Thanks for that. I would like to add, that I was working for a customer which has the first coding at very many places in almost every module, because it is included in a global macro. The problem with modern processors is, that if the location PTR to store the address is in the same cache line (that is, less than 256 byte apart from the place where the ST operation is), you will get the I-cache invalidated, which leads to severe performance issues. The customer observed this by significant performance degradation in the LPAR where those ASSEMBLER programs are running. We then had to rework (at least recompile, after macro change) all these several thousand programs to remedy the problem. The problem is known as SIIS (store into instruction stream). Kind regards Bernd Am 08.02.2021 um 03:38 schrieb Seymour J Metz: 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 -- 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 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). >&g
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
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
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
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: 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
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: 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
Re: LINK vs LOAD/CALL
RENT implies REUS; REUS does not imply RENT. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Friday, February 5, 2021 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL 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 > On Feb 5, 2021, at 3:48 PM, Seymour J Metz wrote: > > RENT implies REUS.. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Joseph Reichman [reichman...@gmail.com] > Sent: Friday, February 5, 2021 3:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > 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 -- 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
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 > On Feb 5, 2021, at 3:48 PM, Seymour J Metz wrote: > > RENT implies REUS.. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Joseph Reichman [reichman...@gmail.com] > Sent: Friday, February 5, 2021 3:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > 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: LINK vs LOAD/CALL
RENT implies REUS.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Friday, February 5, 2021 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL 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
Re: LINK vs LOAD/CALL
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
Re: LINK vs LOAD/CALL
OK, now I get it. That sequence would indeed almost exactly emulate LINK. And therefore, there's probably no reason to do it; but who knows. I didn't say that RBs were esoteric, only that the need to create one with SYNCH is. I think the typical case is for some authorized code to run a user exit somewhat safely. sas On Fri, Feb 5, 2021 at 2:39 PM Ed Jaffe wrote: > On 2/5/2021 11:06 AM, Steve Smith wrote: > > > > SYNCH could replace CALL, but the reasons for doing so are pretty > esoteric, > > and 99.99% of application programmers never have, and never need hear > about > > it (I realize the grammar is off, but I liked it this way... sorry). > > > My point is that LINK replaces SYNCH/LOAD/CALL/DELETE, not just > LOAD/CALL/DELETE. > > SYNCH runs a subroutine in a new PRB. In that subroutine you LOAD the > module and pass control to it. When it returns, you issue a DELETE for > the module and then an SVC 3. The new RB is deleted, and control resumes > at the instruction following the SYNCH macro. > > LINK does all of this in one macro. > > Creating a new RB to run some code is not esoteric at all. It's > fundamental to how MVS works. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system > into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > 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 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
Re: LINK vs LOAD/CALL
On 2/5/2021 11:06 AM, Steve Smith wrote: SYNCH could replace CALL, but the reasons for doing so are pretty esoteric, and 99.99% of application programmers never have, and never need hear about it (I realize the grammar is off, but I liked it this way... sorry). My point is that LINK replaces SYNCH/LOAD/CALL/DELETE, not just LOAD/CALL/DELETE. SYNCH runs a subroutine in a new PRB. In that subroutine you LOAD the module and pass control to it. When it returns, you issue a DELETE for the module and then an SVC 3. The new RB is deleted, and control resumes at the instruction following the SYNCH macro. LINK does all of this in one macro. Creating a new RB to run some code is not esoteric at all. It's fundamental to how MVS works. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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 Fri, Feb 5, 2021 at 1:28 PM Ed Jaffe wrote: > On 2/5/2021 10:04 AM, Steve Smith wrote: > > LINK is one step, rather than LOAD/CALL/DELETE. > > > I would say LINK takes the place of SYNCH/LOAD/CALL/DELETE. > > > Why? That sequence that makes no sense. SYNCH could replace CALL, but the reasons for doing so are pretty esoteric, and 99.99% of application programmers never have, and never need hear about it (I realize the grammar is off, but I liked it this way... sorry). sas -- 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
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
Re: LINK vs LOAD/CALL
On 2/5/2021 10:04 AM, Steve Smith wrote: LINK is one step, rather than LOAD/CALL/DELETE. I would say LINK takes the place of SYNCH/LOAD/CALL/DELETE. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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
Thank you! From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Friday, February 5, 2021 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL LINK is one step, rather than LOAD/CALL/DELETE. LINK will honor the target module's reusability attributes. It is more overhead for a frequently invoked program. Technically, LINK creates a new PRB, which is sometimes, if rarely, required. You would probably find out the first time if the called program does an XCTL or an EXIT and you crash. sas On Fri, Feb 5, 2021 at 12:54 PM Frank Swarbrick wrote: > 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
Re: LINK vs LOAD/CALL
LINK is one step, rather than LOAD/CALL/DELETE. LINK will honor the target module's reusability attributes. It is more overhead for a frequently invoked program. Technically, LINK creates a new PRB, which is sometimes, if rarely, required. You would probably find out the first time if the called program does an XCTL or an EXIT and you crash. sas On Fri, Feb 5, 2021 at 12:54 PM Frank Swarbrick wrote: > 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
Re: LINK vs LOAD/CALL
LOAD and CALL keeps the module you loaded resident in memory until and unless you manually delete it. LINK can (not always) load a new copy every time you use the LINK, which can be expensive. In time used. HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Friday, February 5, 2021 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LINK vs LOAD/CALL EXTERNAL EMAIL 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
