While compiling, RENT on IGYCRCTL versus HEWL.

[durga]

Hi,

We had been using a home grown CLIST to compile the COBOL programs of all sort. Now we have a new SCM tool coming in. we want to make sure that the compile JCL created by the CLIST and the new tool are same.

While testing I found out that for a batch COBOL program these were the options:

CLIST:
IGYCRCTL: NOOPT,DATA(31),RENT
HEWL: LIST, LET, MAP, XREF, AMODE=31, RMODE=ANY, CALL

Tool:
IGYCRCTL: NOOPT,DATA(31)
HEWL: LIST, LET, MAP, XREF, AMODE=31, RMODE=ANY, RENT

Noe, RENT is at IGYCRCTL in CLIST while in tool it is at HEWL (link/binder), will this make a difference?

I looked at these documents: https://www.ibm.com/support/knowledgece ... up0057.htm

https://www.ibm.com/support/knowledgece ... cllexx.htm

but still trying to confirm it. If someone can guide on this, that would be great.

[Robert Sample]

Noe, RENT is at IGYCRCTL in CLIST while in tool it is at HEWL (link/binder), will this make a difference?

It can make a difference. Whether or not it actually does, though, is a different question. If the default compile option is RENT, then the tool not specifying it would not matter. If the default compile option is NORENT, though, then the COBOL compiler will NOT generate a reentrant object module and that would impact the linkage editor / binder since it would not be able to create a reentrant load module from nonreentrant object modules.

Your best bet would be to work with your site support group on the issue and find out what they have the compiler defaults set to. The default is RENT, but that can be changed by site options.

[enrico-sorichetti]

there is no relation whatsoever between the compiler and binder RENT parm

for cobol it will make a difference in the machine code being generated,

for assembler

RENT
Specifies that the assembler checks for possible coding violations of program reenterability. Non-reenterable code is identified by an error message, but is not exhaustively checked because the assembler cannot check the logic of the code. Therefore, the assembler might not detect all violations of program reenterability.

IIRC the linkage editor / binder will just apply the requested attributes
it does not have any way to determine if the thing being bound is really reentrant or not
( at least for assembler )

all will be painfully discovered at run time

[durga]

I was working with the team involved in setting up the tool. They told me if the options shown the in the COBOL listing from CLIST and TOOL are same, we are good. As shown below:

Is that correct, even when the we have difference in the JCLs generated as stated in the first post?

Code: Select all

PP 5655-S71 IBM ENTERPRISE COBOL FOR Z/OS  4.2.0 
INVOCATION PARAMETERS:                           
 NOOPT,DATA(31),RENT,                            
OPTIONS IN EFFECT:                               
 NOADATA                                         
 NOADV                                           
   APOST                                         
   ARITH(COMPAT)                                 
 NOAWO                                           
 NOBLOCK0                                        
   BUFSIZE(16384)                                
 NOCICS                                          
   CODEPAGE(1140)                                
 NOCOMPILE(E)                                    
 NOCURRENCY                                      
   DATA(31)                                      
 NODATEPROC                                      
 NODBCS                                          
NODECK          
  DIAGTRUNC     
NODLL           
NODUMP          
NODYNAM         
NOEXIT          
NOEXPORTALL     
  FASTSRT       
  FLAG(W,E)     
  FLAGMIG4      
NOFLAGSTD       
  INTDATE(ANSI) 
  LANGUAGE(UE)  
  LIB           
  LINECOUNT(60) 
  LIST          
  MAP           
NOMDECK         
NONAME           
  NSYMBOL(DBCS)  
NONUMBER         
  NUMPROC(NOPFD) 
  OBJECT         
NOOFFSET         
NOOPTIMIZE       
  OUTDD(SYSOUT)  
  PGMNAME(COMPAT)
  RENT           
  RMODE(AUTO)    
NOSEQUENCE       
  SIZE(MAX)      
  SOURCE         
  SPACE(1)       
NOSQL            
  SQLCCSID       
NOSSRANGE        
 NOTERM                                             
 NOTEST                                             
 NOTHREAD                                           
   TRUNC(BIN)                                       
PP 5655-S71 IBM ENTERPRISE COBOL FOR Z/OS  4.2.0    
 NOVBREF                                            
 NOWORD                                             
   XMLPARSE(XMLSS)                                  
   XREF(FULL)                                       
   YEARWINDOW(1900)                                 
   ZWB                                              
PP 5655-S71 IBM ENTERPRISE COBOL FOR Z/OS  4.2.0    

[nicc]

What you posted is from the compiler so how the options weere set is irrelevant as long as they are correct. The same goes for the binder.

[durga]

I am sorry but I did not get you. You mean if the options appear in the above list, irrespective of the point whether they were supplied at compiler or binder does not matter?

[enrico-sorichetti]

irrespective of the point whether they were supplied at compiler or binder does not matter

where and how the options/parms are specified/provided DO matter

the compiler does not know about the binder and the binder does not know about the compiler

the compiler does not care about the binder options/parms
the binder does not care about the compiler options/parms

[Anuj Dhawan]

It'd be a good idea to test the executable, after both the compilation, to verify if all works well.