Re: re-entrant modules and the binder

[Frank Swarbrick]

I found an alternative, which is in fact what I wanted to do in the first place 
but could not figure how.  With the defaults, if we specify the binder option 
REUS=RENT we get the IEW2609W warning, but the bind process succeeds, giving a 
return code of 4.  However, I can specify LET=0 and this causes warnings to 
result in a return code of 12.  I am sure this was obvious with anyone familiar 
with the program binder, but...

Using this option will, of course, indicate that the module was to be bound 
with an improper option (RENT=REUS) and one would change that and re-bind. 


Of course it's not just the IEW2609W warning that will cause the step to fail, 
but any warning.  Hopefully we don't currently get any warnings that we want to 
consider successful.

Frank




>
> From: Frank Swarbrick 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Monday, July 23, 2012 4:34 PM
>Subject: 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 
>>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 
>>>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
>
>
>

--
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

[John Gilmore]

Tony Harminc wrote:


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.


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

[Tony Harminc]

On 23 July 2012 15:42, John Gilmore  wrote:
> 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 think I've missed a bit in all this discussion. As you point out,
the assembler RENT option provides (inadequate but still helpful)
checks for coding that might be non-reenterable. It does not mark the
resulting object output with its conclusions, and indeed the
traditional object deck format has no mechanism for encoding such an
attribute, either at the CSECT or object module level. The GOFF format
does appear to have such a mechanism, but the HLASM documentation
suggests that it is not used in output from HLASM.

So when we speak of having the Binder ensure that load modules will
not contain assembler modules with NORENT (or indeed other undesirable
attributes), this will not be enforced if the Binder input includes
classic object modules, and I believe it will not happen with GOFF
either. 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.

> 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.

The Binder book is more than a little confusing in its explanation of
the COMPAT option, but it does not say that COMPAT(LKED) forces
Linkage-Editor-like *output*, but just that "certain binder
*processing* options are to work in a manner compatible with the
linkage editor". In particular, if this option were to force load
module output, the explanation would conflict with the earlier "If
SYSLMOD is allocated to a PDSE or a z/OS UNIX file, the output is
saved as a program object in the format specified by the COMPAT
option. If the user specified a COMPAT value that does not support the
contents of the module, binder will issue a level 12 message and fail
the bind."

Tony H.
feeling unaccountably language-lawyerly today...

--
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

[Frank Swarbrick]

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 
>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 
>>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

[Frank Swarbrick]

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 
>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

Re: re-entrant modules and the binder

[John Gilmore]

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

Re: re-entrant modules and the binder

[Frank Swarbrick]

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 
>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

[Frank Swarbrick]

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 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Sunday, July 22, 2012 7:12 AM
>Subject: 

Re: re-entrant modules and the binder

[Shmuel Metz (Seymour J.)]

In
,
on 07/22/2012
   at 09:12 AM, John Gilmore  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  
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

[Robert A. Rosenberg]

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

Re: re-entrant modules and the binder

[John Gilmore]

The details of the example Charles Mills shows are unhelpful; but his
central point---that the non-reentrant constructions the HLASM finds
most readily are those of storage into one of the CSECTs or RSECTs
being assembled---is entirely correct.

Still, the RENT option should be specified when these target CSECTs or
RSECTs are to be reentrant.


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

[Charles Mills]

> 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

[John Gilmore]

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