Re: re-entrant modules and the binder
In CAE1XxDE+7LU3kKQt2pEgJVyNR2U7-=st1ejzi9abaxyuavr...@mail.gmail.com, on 07/22/2012 at 09:12 AM, John Gilmore jwgli...@gmail.com said: Specifying the RENT option when you assemble your HLASM subroutines instructs the HLASM to check your code for non-reentrant constructs, and it finds many but not quite all of them. The RENT option actually flags things that appear to not be read-only rather than reentrancy violations, and has some false positives. The option is useful, you you still must run IEBIBALL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
Hi John, To make my desire clearer, I'm going to slightly simplify my goal. I want to be able to bind as re-entrant any COBOL program that does NOT call an assembler subroutine that is not re-entrant. If I add only REUS=RENT to by COBOL program binder JCL I get the following if the COBOL program does a static call to a non-reentrant assembler module: z/OS V1 R12 BINDER 10:34:27 MONDAY JULY 23, 2012 BATCH EMULATOR JOB(DVFJSCM ) STEP(STEP01 ) PGM= IEWL PROCEDURE(LKED ) IEW2278I B352 INVOCATION PARAMETERS - LIST,MAP,XREF,REUS=RENT IEW2609W 5104 SECTION SUBR USABILITY ATTRIBUTE OF NON-REUSABLE CONFLICTS WITH REQUESTED USABILITY OF REENTRANT.[...]SECTION CLASS --- SOURCE OFFSET OFFSET NAME TYPE LENGTH DDNAME SEQ MEMBER 0 RUNDATE CSECT F9C SYSLIN 01 **NULL** FA0 CEESG005 * CSECT 18 SYSLIB 07 CEESG005 FB8 CEELOCT * CSECT 14 SYSLIB 07 CEELOCT FD0 SUBR * CSECT CFC SYSLIB 01 SUBR [...] PROCESSING OPTIONS: [...] COMPAT UNSPECIFIED [...] RES NO REUSABILITY REENTRANT [...]SAVE MODULE ATTRIBUTES: [...] AMODE 31 [...] REFR NO RENT YES REUS YES RMODE ANY [...] MESSAGE SUMMARY REPORT -- WARNING MESSAGES (SEVERITY = 04) 2609 INFORMATIONAL MESSAGES (SEVERITY = 00) 2008 2278 As you say, this will not work well if the program is loaded in to read-only storage. z/OS V1 R12 BINDER 10:38:20 MONDAY JULY 23, 2012 BATCH EMULATOR JOB(DVFJSCM ) STEP(STEP01 ) PGM= IEWL PROCEDURE(LKED ) IEW2278I B352 INVOCATION PARAMETERS - LIST,MAP,XREF,COMPAT=LKED,REUS=RENT IEW2664I 5143 SECTION SUBR USABILITY ATTRIBUTE OF NON-REUSABLE CONFLICTS WITH REQUESTED USABILITY OF REENTRANT. [...] PROCESSING OPTIONS: [...] COMPAT LKED [...] RES NO REUSABILITY REENTRANT [...] SAVE MODULE ATTRIBUTES: AMODE 31 [...] REFR NO RENT NO REUS NO RMODE ANY [...] MESSAGE SUMMARY REPORT -- [...] WARNING MESSAGES (SEVERITY = 04) NONE INFORMATIONAL MESSAGES (SEVERITY = 00) 2008 2278 2664 Differences when COMPAT=LKED specified: IEW2664I instead of IEW2609W. RENT NO instead of RENT YES (even though REUS=RENT specified). REUS NO instead of REUS YES (even though REUS=RENT specified). Doing this (specifying COMPAT=LKED) works fine and allows me to change the REUS option on my COBOL program binds to REUS=RENT, but to not have non-reentrant programs erroneously specified as being RENT when in fact they are not. This gives me time to make the assembler subroutines re-entrant at my convenience, while still being able to make those COBOL routines that do not call NORENT modules re-entrant sooner rather than later. I just want to make sure I'm not missing something or losing out on some benefit by doing this. I guess one point to be made is that I don't want to have to specify REUS=RENT on a program by program basis for those modules that I want to bind as reentrant. By doing this I can change the COBOL binder step to always specify this option (and COMPAT=LKED), and it will set RENT/REUS when those options are set in all routines bound together; otherwise it will not sent RENT/REUS. Finally, I am indeed making the assembler subroutines LE-compatible. As you say, it makes the storage management much simpler; especially when the same module can be executed both under CICS and not under CICS. Thanks! Frank From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, July 22, 2012 7:12 AM Subject: Re: re-entrant modules and the binder I
Re: re-entrant modules and the binder
I assume your query is directed to me, the original poster. The assembler subroutines are being used for some fairly basic processing that simply isn't available in COBOL (or wasn't at the time the assembler routines were written): - calling of a few basic macros (POST, STIMER [STIMER not used under CICS though!]) - A routine to expand each bit to a byte (x'F0' or x'F1') and to unexpand same - A routine to get the address of a working-storage area - A routine to perform an XOR operation - EBCDIC/ASCII translation - A basic compression routine - A base 94 conversion routine - Some other things that probably should have been done in COBOL but were done in assembler for reasons unknown to me... Frank From: Robert A. Rosenberg hal9...@panix.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, July 22, 2012 9:34 PM Subject: Re: re-entrant modules and the binder At 09:13 -0700 on 07/22/2012, Charles Mills wrote about Re: re-entrant modules and the binder: and it finds many but not quite all of them. Basically, it finds ST 1,FOO where FOO is defined in the CSECT something like FOO DC F'0' but it does not find things like the following construct that IBM macros are or were fond of CNOP 0,4 BAL 1,*+8 DC F'0' ST 2,0(0,1) In the first case it knows that FOO is in a code section but in the latter it only knows that R1 is pointing somewhere. Charles Since these modules are intended for use with CICS, most of the IBM macros that would fool the RENT Check are going to be ones that should not be being used in the first place. For example, doing I/O (and thus using OPEN/CLOSE and I/O calls) is not something you are supposed to do under CICS (you use the CICS not the OS support). What is the the intent of the Assembler Routines? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
Interesting. Looks like I can use COMPAT(LKED) and still create program objects (both format 2 and format 3). I guess maybe it's that one simply cannot explicitly request a PM level of higher than the program requires if you specify COMPAT(LKED). But (apparently) it behaves like COMPAT(MIN) on other respects; specifically that the binder should select the minimum PM level that supports the features actually in use for the current bind. Does that make sense? Frank From: Frank Swarbrick frank.swarbr...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 23, 2012 2:56 PM Subject: Re: re-entrant modules and the binder I hadn't noticed the issue with PDS load modules versus PDSE program objects. We currently are placing them in PDSs, but as we now use basic sysplex PDSE sharing we are going to soon want to convert to PDSE. I'm going to see what happens, just for my edification, but I believe you are right. Hmmm... This is not ideal. If you think of any good ideas please let me know! Thanks, Frank From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 23, 2012 1:42 PM Subject: Re: re-entrant modules and the binder Frank, I take your point about the use of the binder option COMPAT(LKED). It does ensure that no load module that contains a non-reentrant HLASM module will be marked RENT. I am not, however, sure that COMPAT(LKED) is free of other disabilities. It ensures, for example, that target executables will be PDS-resident load modules, not PDSE-resident program objects. It may preclude use of some LE facilities, for the use of which PM3 must minimally be specified. (The manual text is not entirely clear: we are abjured to avoid the notion that COMPAT is necessarily a lower level than PM1; but it is silent about where PM3 fits into this partial ordering.) John Gilmore, Ashland MA, 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
Tony Harminc wrote: begin extract It is, rather, a matter of discipline in managing assembler object output, and this can be helped by processing these outputs one at a time with the Binder, storing them as stub load modules or Program Objects, and marking them appropriately at that first partial bind. Then later Binder processing can warn appropriately on a more automated basis. /end extract Implicit in this is the important notion that these 'stubs' should be stored in a library that contains only NCAL program objects (or load modules). There is even a [small] performance benefit associated with this practice. The binder processes its own outputs more efficiently and rapidly than it does translator-generated object modules, which should have only very brief, transition-state lives. John Gilmore, Ashland, MA 01721 - USA. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
I am not sure that I fully understand exactly what you want to do or the exact sequence in which you want to do it. Your objective is, however, clear: You want to be able to use the CICS RENTPGM=PROTECT facility. If 1) you specify this option for a CICS application program (AP) and 2) CICS honors it, that AP is placed in read-only storage. A later attempt to execute such an AP will have dire consequences if it in fact modifies itself. You may not therefore specify this option for a load module or program object that contains a non-reentrant assembly-language module or modules. As you have noted, there is no great difficulty about making your COBOL modules reentrant. Instructing your compiler to do so will accomplish this. Specifying the RENT option when you assemble your HLASM subroutines instructs the HLASM to check your code for non-reentrant constructs, and it finds many but not quite all of them. (You can and should use the SYSOPT_RENT boolean within each assembly unit to ensure that the RENT option has in fact been specified for it.) I strongly recommend that you also make these assembly-language modules LE-compatible. Using the LE's LIFO storage-management facilities will make the task of making these modules reentrant much easier. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
and it finds many but not quite all of them. Basically, it finds ST 1,FOO where FOO is defined in the CSECT something like FOO DC F'0' but it does not find things like the following construct that IBM macros are or were fond of CNOP 0,4 BAL 1,*+8 DCF'0' ST2,0(0,1) In the first case it knows that FOO is in a code section but in the latter it only knows that R1 is pointing somewhere. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Sunday, July 22, 2012 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: re-entrant modules and the binder I am not sure that I fully understand exactly what you want to do or the exact sequence in which you want to do it. Your objective is, however, clear: You want to be able to use the CICS RENTPGM=PROTECT facility. If 1) you specify this option for a CICS application program (AP) and 2) CICS honors it, that AP is placed in read-only storage. A later attempt to execute such an AP will have dire consequences if it in fact modifies itself. You may not therefore specify this option for a load module or program object that contains a non-reentrant assembly-language module or modules. As you have noted, there is no great difficulty about making your COBOL modules reentrant. Instructing your compiler to do so will accomplish this. Specifying the RENT option when you assemble your HLASM subroutines instructs the HLASM to check your code for non-reentrant constructs, and it finds many but not quite all of them. (You can and should use the SYSOPT_RENT boolean within each assembly unit to ensure that the RENT option has in fact been specified for it.) I strongly recommend that you also make these assembly-language modules LE-compatible. Using the LE's LIFO storage-management facilities will make the task of making these modules reentrant much easier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: re-entrant modules and the binder
At 09:13 -0700 on 07/22/2012, Charles Mills wrote about Re: re-entrant modules and the binder: and it finds many but not quite all of them. Basically, it finds ST 1,FOO where FOO is defined in the CSECT something like FOO DC F'0' but it does not find things like the following construct that IBM macros are or were fond of CNOP 0,4 BAL 1,*+8 DCF'0' ST2,0(0,1) In the first case it knows that FOO is in a code section but in the latter it only knows that R1 is pointing somewhere. Charles Since these modules are intended for use with CICS, most of the IBM macros that would fool the RENT Check are going to be ones that should not be being used in the first place. For example, doing I/O (and thus using OPEN/CLOSE and I/O calls) is not something you are supposed to do under CICS (you use the CICS not the OS support). What is the the intent of the Assembler Routines? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
