om: 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
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
_
> 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
>
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
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
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
___
> 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
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 +
du/~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 ev
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
@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 storag
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
: 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
> > 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
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
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
@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.
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
-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
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
: 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
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
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)
la
...@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.
&g
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
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
>
ALR 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 refresha
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
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
...@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
@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
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:
>...
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?
--
Shmu
: 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
n [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 REFRPRO
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
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
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
://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 cou
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
[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?
...@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
3
>
>
> 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
>
>
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
> Su
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
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
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
:>>
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
>
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
-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 be
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
A.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
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,
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
gt; 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
@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,
n 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
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
/~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
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
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
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
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/
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
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
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
66 matches
Mail list logo
