I know the difference between RENT and REUS as used in z/OS. And, no, I don't want to rehash it <grin/>.
The problem that I have with CA-Endevor is that if the binder invocation has the RENT parm specified, then the module is unconditionally marked RENT. It appears that if RENT is not specified, that the module is not marked RENT in the load library. And so it becomes the responsibility of the programmer to use the proper CA-Endevor processor or override to either mark the program as RENT or not. This is simply too complicated for our programmers. We have a single process to do all CICS compiles. It is what they know to use. They do not/can not learn the intricacies of when to specify RENT or not. The system _must_ do it for them. But it does not. So they are _forced_ to bind all their programs an NORENT,NOREUS. Sorry, but that's just the way it is here. I don't know about other shops. If I can make the HLASM routines re-entrant, then we can "hard code" the Endevor link step to have the RENT parm. That's what I'm tasked with doing. Because the programmers can't figure out how to fix the memory overlay problem until _we_ can tell them which COBOL verb in which COBOL program is actually causing the overlay. They cannot tell from the data in the overlay. Oh, and we can't compile or run with the SSRANGE option because that will cause excessive CPU overhead, which will cause screaming from IT management due to MSU charges. It is cheaper to just endure the problems. I.e. "cost to fix" is too great unless Tech Services can do it alone, for $0.00 in "hard dollars". MSU charges are "hard dollars". The problem: <quote> *Link-edit* *considerations:* If all programs in a load module are compiled with *RENT*, it is recommended that the load module be link-edited with the *RENT* linkage-editor or binder option. (Use the REUS linkage-editor or binder option instead if the load module will also contain any non-COBOL programs that are serially reusable.) </quote> from: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/2.4.42 On Tue, Jun 25, 2013 at 9:28 AM, Charles Mills <[email protected]> wrote: > > I don't know why the binder requires the RENT parameter to mark a program > > object as RENT if all the input CSECTs are COBOL which is compiled with > > the RENT compiler option. Maybe somebody could explain? > > Missed this question. It just does. It is a separate program with its own > options. I don't know for the "new-fangled" object formats, but for > traditional object formats, I don't think the object file carries an > indication of RENT or not, so the binder does not "know" that any or all of > the input modules are RENT. I suppose one could come up with hypothetical > situations such as one where an assembler module is compiled as RENT but > has > a reentrancy flaw, and so one might want to link it not RENT without the > bother of recompiling it? > > We can also rehash the tired IBM-MAIN discussion of the subtleties RENT vs > REUS if you want. <g> > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of John McKown > Sent: Tuesday, June 25, 2013 6:16 AM > To: [email protected] > Subject: z/OS subroutine in assembler, used in both batch & CICS , making > re-entrant > > IMO, this is a rather involved problem. > > background: > This is in CICS/TS 4.1, z/OS 1.12. We have a few highly used assembler > subroutines which are statically linked into both CICS and batch COBOL > programs. These programs are very old (20+ years). They use an "in line" > save area, and so they are not RENT. We are having a problem with some > other > program (nobody can figure out which one) in which that program sometimes > overlays a CICS application program. Some time thereafter, when this > overlaid program is invoked, it abends (surprise, suprise!). We are running > RENTPGM=PROTECT. However, none of our programs are linked as RENT and so > they are not protected. We use CA-Endevor to do all our compiles. > The Endevor person changed the Endevor setup to have the RENT parm in all > CICS/COBOL links. Unfortunately, this resulted in programs which use this > assembler subroutine abending ASRA (S0C4-4) when the subroutine tried to > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
