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