On Fri, 25 May 2018 22:23:09 +0200, Peter Hunkeler wrote:
>>> What was Peter H. (informally?) quoting without citation?
> >
>>In: z/OS IBM MVS Program Management: User's Guide and Reference
>>Version 2 Release 3 SA23-1393-30
>
>Re-read my post and you will find my citation. I admit I missed the word
>"Reference" and I did not include the pubs number. I thought it would be
>understood, nevertheless. It seems, not. I'm sorry for the confusion this may
>have caused.
>
OK. You posted from "Glossary" (which I hadn't noticed):
reenterable
The reusability attribute that allows a program to be used concurrently by
more
than one task. A reenterable module can modify its own data or other shared
resources, if appropriate serialization is in place to prevent interference
between
using tasks. See reusability.
>
That's how I recall the behavior from decades ago. But it appears to be
contradicted,
at least in spirit, by the "options reference":
On Fri, 25 May 2018 13:23:58 -0500, Paul Gilmartin wrote:
>On Tue, 22 May 2018 15:27:32 -0400, Thomas David Rivers wrote:
>
>>The BPX loadhfs function (BPX1LOD) loads an HFS executable
>>into memory.
>>
>>It seems, that sometimes, this is loaded into writable memory
>>and sometimes into read-only memory.
>>
>>There doesn't seem to be a way to indicate which is desired.. is there
>>some OS-interface that writable memory be used?
>>
>What was Peter H. (informally?) quoting without citation?
>
>In: z/OS IBM MVS Program Management: User's Guide and Reference
>Version 2 Release 3 SA23-1393-30
>
>Chapter 6. Binder options reference
>Binder options
>REUS: Reusability options`
>RENT
> The module is reenterable. It can be executed by more than one
> task at a time. A task can begin executing it before a previous
> task has completed execution. A reenterable module is ordinarily
> expected not to modify its own code. In some cases, MVS protects
> the reentrant module's virtual storage so that it cannot be
> modified except by a program running in key 0. These cases
> include programs which the system treats as having been loaded
> from an authorized library, and also programs running under UNIX
> unless a debugging environment has been specified.
>
> Reenterable modules are also serially reusable.
>
>So, WAD.
>
>I dislike some things about this:
>
>o "include" is undesirably vague. The Ref. should specify exactly
> the cases in which ... programs are [so] treated. A precise "are"
> is preferable to the imprecise "include". What other cases may
> there be? "[T]reats as having been ..." is likewise vague. Provide
> at least a citation of an explanation of what this means.
>
>o Simpler Is Better. I see no good reason to treat "programs running
> under UNIX" differently from other programs.
>
>o "ordinarily expected". Is this a retreat from the earlier well-known
> rule (cited by Peter) that a RENT program was allowed to modify its
> own code given proper serialization?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
