Hi R'Shmuel AMV"SH,
You said: "... That's why you have to rebuild from the object modules if
a reentrant module was incorrectly linked as REUS. ...".
If you have the PDS Command Processor (CBT File 182) or Startool, you
can "edit" the directory entry to add/remove these and other attributes
(e.g. AC(0)/AC(1)).
Shana Tovah
Regards,
David
On 2021-09-05 17:44, Seymour J Metz wrote:
There used to be a children's game called telegram, where a group of children
sat in a circle, one got a text and quietly read a short text to an adjacent
chile, who quietly repeated it to the next child, etc., until it came back to
the first child, who compared it to the original text. Those who know wrote
what they aactually wrote, not what was attributed to them.
BTW, the text that you cited is incorrect;it's not whether the icluded module
actually is refreshable or reentrant that affects the linkage editor, it's
whether it is flagged with the attribute. That's why you have to rebuild from
the object modules if a reentrant module was incorrectly linked as REUS.
--
Shmuel (Seymour J.) Metz
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7C%7C843fac68f3a241365cd808d970b6669c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637664751026547371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OKM89FQ1NHIocWcpseIqFif00l3K4gvK1QpKtrha4AQ%3D&reserved=0
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM
Poncelet [ponce...@bcs.org.uk]
Sent: Saturday, September 4, 2021 8:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RENT binder option
Sure. Thank you for confirming that those who know agree with what I
have said - for the benefit of those who do not know and who might
otherwise be misled into thinking that REFR and RENT LMODs need to be
'protected' from modifying themselves and/or can modify themselves or
whatever nonsense else.
BTW Off-topic, my hard-copy "MVS/Extended Architecture Linkage Editor
and Loader Users's Guide" version 2 release 2.0 (order number
GC26-4143-1) second edition (June 1986) agrees with your MVS/370 linkage
editor user's guide from 1985, as quoted. And I would most respectfully
point out that e.g. "If the refreshable attribute is specified, and any
load modules that are not refreshable become a part of the input to the
linkage editor, the attribute is negated" does indeed apply if any
module's OBJ code has not been link-edited with the REFR attribute but
is then included in the LMOD's link-edit SYSLIN cards, *then* the
resulting LMOD is marked not REFR regardless of all other link-edited
modules included in the said SYSLIN cards having been marked REFR.
Thanks again for 'absolving' me from having to defend and protect
systems programming from being reduced to mere systems administration,
then to level-2 and then level-1 tech support, then to help-desk support
- as per Micro$oft Windoze. I thoroughly appreciate your supporting
mainframe systems programming.
I can now gladly drop out of this thread.
Cheers, Chris Poncelet (retired etc.)
On 04/09/2021 11:31, Joe Monk wrote:
"A module is REFR or RENT - not if it is link-edited as REFR or RENT, but
if it never modifies its own storage."
Why do you keep lecturing us on things we already know?
Jim Mulder knows it best as he is the frickin author of z/OS (well he and
Peter Relson).
Please stop.
"But it is the
programmer/developer who is responsible for ensuring that the module's
code is indeed REFR or RENT - and it is not the linkage-editor or
binder's responsibility."
To quote the MVS/370 linkage editor user's guide from 1985:
"If the reenterable attribute is specified, and any load modules that are
not reenterable become a part of the input to the linkage editor, the
attribute is negated."
"If the refreshable attribute is specified, and any load modules that are
not refreshable become a part of the input to the linkage editor, the
attribute is negated."
So, it has been the case since 1985 that the linkage editor does check the
input load modules, and will not mark a non-RENT/REFR load module as having
those attributes. Jim Mulder has been at IBM for 42 years, so 1985 ... yeah
he would've been working on MVS then.
Thanks.
Joe
On Fri, Sep 3, 2021 at 9:05 PM CM Poncelet <ponce...@bcs.org.uk> wrote:
At the risk of inviting 'flak', I suspect that there is a misconception
of what RENT and REFR modules actually are.
By definition, RENT and REFR modules should never modify themselves
(excluding the peculiar case of a RENT module that ENQ's on part of its
code, modifies it, restores it to what it was, then DEQ's it - as this
would not violate the definition of RENT modules being concurrently
executable by multiple tasks.)
A module is REFR or RENT - not if it is link-edited as REFR or RENT, but
if it never modifies its own storage. In other words, all modifiable
storage must first be GETMAINed (including the module's savearea
storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs
etc. must then use the 'list' and 'executable' forms of these
macros/DSECTs to avoid modifying the module's own storage.)
As a 'first line of defence', such modules should be coded as RSECTs and
not as CSECTs - and the assembler will then trap (with a CC=08, IIRC)
any direct attempt to modify the module's own storage. But it is the
programmer/developer who is responsible for ensuring that the module's
code is indeed REFR or RENT - and it is not the linkage-editor or
binder's responsibility.
Arguing that REFR or RENT modules need to be 'protected' from modifying
themselves, or by others, is methinks beside the point - because such
modules should have been coded in such way that they *never* modify
themselves to begin with. If others can modify them, then it is these
other modules that should be investigated, not the REFR or RENT ones.
On 03/09/2021 13:34, Paul Gilmartin wrote:
On Thu, 2 Sep 2021 16:02:07 -0400, Jim Mulder wrote:
I found IBM RENT modules that modified themselves
15 years ago when I was experimenting to see what would
happen if we tried to page-protect RENT modules. I have a list:
Have you a similar list of IBM REFR modules that modify themselfes?
Does the setting of REFRPROT affect processing of modules
marked RENT but not REFR?
What were the reusability attributes of the module in OA25089?
ANTMAIN
ANTSDMLK
IEAVNIPX
EZATNF
IOEFSKN
FNMVZJV
FNMVZCVA
EZAXVMCF
DSNHDECP
DSN9PARM
DSN3INI
CNMINIT
CNMCSSIM
CNMCSSIC
We subsequently removed the unintended RENT from IEAVNIPX.
So we don't page-protect RENT modules (except for experimental
purposes under control of another undocumented DIAGxx TRAP name),
and we implemented REFRPROT instead. I haven't heard about
any IBM modules that get broken by 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
----------------------------------------------------------------------
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
