Around 1980 when I first got into Systems, I was given an assembler program that processed SMF data. One particular record type had changed recently: the offset of some data of interest had shifted. The previous program owner had chosen to accommodate this change by checking some upfront flag to determine format. If new format, alter some MVC instructions accordingly (!), otherwise run as originally written. I was scandalized. It worked but violated most every principle I had adopted as an application programmer. My first action was to impose civility on the program. Sheesh.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, May 27, 2018 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory? There's the definition of reentrant and then there's the handling of the RENT option in various contexts. Don't expect the Binder to be consistent with the Linkage Editor, or that the behavior of load modules, program objects and Unix files will be consistent. But it would be nice if IBM ever disentangled the mess. BTW, I consider it bad form for code to modify itself, even if it is in fact reentrant or refreshable. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 25, 2018 7:49 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory? 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
