The linkage editor treated the reusability attributes individually and they could potentially be set independently (NORENT and REFR). The binder treats reusability as a hierarchy, REFR implies RENT, RENT implies SERIALLY REUSABLE, so it will never set them that way. In GOFF object modules and program objects reusability is treated as a single-value field, not individual bits.
The binder simply sets the attributes, there's no attempt by the binder to do anything but complain if the sections (CSECTs) are not consistent with the REUSability option set by the user. If the option specified is more restrictive the binder will give a warning message (IEW2609W) , but still set the module reusability according to the option specified. The default is always REUS=NONE. Unlike the binder, the linkage editor may honor the module reusability over the option set by the user. Note that while it is only in the PDSDE directory entry of load modules (not in the ESD information of load modules or OBJ object modules), it is available to the binder in the ESD information in program objects and GOFF object modules, as well as in the PDS and PDSE (PMAR) directory entries. And actually the binder can be told to honor the reusability within the module as well, by using the option COMPAT(LKED). Then the binder will issue an informational message (IEW2664I) instead of a warning message, and honor the "downgraded" reusability. Also the binder will take the most restrictive reusability specified as a simple option name, regardless of order (I know of no other binder options that work this way). So PARM='REFR,NORENT' gets you REFR. To "reset" to non-reentrant you'd have to use the binder syntax REUS(NONE) (or equally REUS=NONE). To the original DLL question: Languages like C may have data/variables which are writable (residing in the writable-static area, WSA). There was a time and I think in some cases it is still true, where the load point of the module is used by LE to determine that the module was already loaded for a given enclave. LE may use that information to decide whether it should create a new WSA instance associated with that DLL (module), which is shared for the entire LE enclave. Thus not having the module marked as RENT could cause problems, with multiple instances of data/variables are seen in different modules/procedures/functions of the entire DLL application. On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith <sasd...@gmail.com> wrote: > > Seems like deja vu. For all practical purposes, RENT and REFR (which > implies RENT) have the same effect (that may be a tautology). > > For whatever reasons, RENT & REFR were defined such that they didn't > accurately describe how they were implemented. What the OS wanted was > protected memory for programs (and good programmers want that too). In > effect, both mean that program storage cannot be modified during > execution. But the module attribute definitions go on about the ability > for multiple tasks to simultaneously use the module, or for the ability to > tolerate a refresh. Neither of those things absolutely requires > non-modification, so one wonders why IBM wandered off into those tangents. > > On the converse, it's not that hard to write read-only code that is not > reentrant (thread-safe in newspeak). And nothing in z/OS cares a bit... > you just get unpredictable results. Actual reentrancy requires interlocked > access to any shared memory; avoiding variables embedded within the program > module is just the beginning. > > The bottom line is that Program Fetch allows RENT modules to be shared, > REUS is just a weird ENQ trick, and otherwise you get multiple copies. I > really don't know if REFR has any effect over RENT. Perhaps it's required > for PLPA modules. > > sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
