COBOL considerations for CA Datacom/DB and LE?

book

Article ID: 37718

calendar_today

Updated On:

Products

CA Datacom - DB CA Datacom CA Datacom - AD CA Datacom - Server CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware

Issue/Introduction

Question:

Some of our programmers are beginning to write COBOL programs that access Datacom/DB and DB2 databases from the same program.  Other than specifying DBSQL=YES in the DBUREND macro, are there any other requirements for the URT?  For instance, does it have to be an OPEN=USER or can it still be OPEN=DB, etc.

 

I have been told that we should be specifying LE=YES but now the Sysprog is saying that some programs will abend with the enclave.  I'm trying to also find out when you do or do not specify LE=YES then.

 

Answer:

Considerations when using LE (Language Environment):  

 

-1 See IBM knowledge Center: About Specifying Runtime Options in the EXEC statement. 

 https://www-01.ibm.com/support/knowledgecenter/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea200/mvsexec.htm

 

//[stepname] EXEC PGM=program_name, 

//PARM='[runtime options/][program parameter]'

 

For example , if you want to generate a storage report and runtime options report for program PROGRAM1, specify the following:

 

//GO1 EXEC PGM=PROGRAM1,PARM='RPTSTG(ON),RPTOPTS(ON)/'. 

 

The runtime options that are passed to the main routine must be followed by a slash (/) to separate them from program parameters.  

 

-2  See CA Datacom/DB Programming Guide: About - Considerations for IBM Language Environment (LE) (page 156/157)

When developing or converting applications accessing CA Datacom/DB to execute in the IBM Language Environment (LE) model, consider the following with regard to the DBURINF macro parameters OPEN= and LE=.....see documentation below:

https://supportcontent.ca.com/cadocs/0/CA%20Datacom%2014%200%20Public-ENU/Bookshelf.html

 

-3  See CA Datacom Webcasts on CA Support Online site: About User Requirements Tables (URTs). 

- CA Datacom User Requirements Tables (URTs) and Application Programming - Part 1 of 2 Webcast March 1st, 2011. 

-  CA Datacom User Requirements Tables (URTs) and Application Programming - Part 2 of 2 Webcast March 29th, 2011. 

Where LE= parameter is mentioned (see Part1). LE=NO is the default.

 

These CA webcasts can be seen at:

http://www.ca.com/us/support/ca-support-online/product-content/recommended-reading/technical-document-index/ca-datacom-video-and-recorded-webcast-index.aspx

 

-4 See CA Datacom/DB System and Administration Guide: About LE= parameter setting in URT. 

This parameter is used to specify that the application program is to be executed under IBM Language Environment (LE), and that CA Datacom/DB is to establish the LE enclave prior to branching to the entry point name specified in the USRNTRY= parameter.

 

If YES is specified, CA Datacom/DB is to establish an LE enclave prior to branching to USRNTRY= (recommended if BEGIN is specified as the entry point for the program at linkage edit).

 

If NO is specified, no LE initialization is to take place prior to branching to USRNTRY=.

https://supportcontent.ca.com/cadocs/0/CA%20Datacom%2014%200%20Public-ENU/Bookshelf.html 


 

-5 See Running COBOL Programs with AMODE 24,

https://supportcontent.ca.com/cadocs/0/CA%20Datacom%2014%200%20Public-ENU/Bookshelf_Files/HTML/Article-Running%20COBOL%20Programs%20with%20AMODE%2024/index.htm

 

-6 See IBM Knowledge Center about RTEREUS parameter.

(Derivation Run Time Environment REUS)

https://www-01.ibm.com/support/knowledgecenter/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea500/clrteru.htm

  

How LE can affect COBOL or Assembler CA Datacom/DB applications:  

The effect primarily depends on how their URTs are coded.  

- If they have the DBURINF parameter OPEN= set to USER, then there will generally be no impact when LE is involved.                       

                                                                             

- The next two cases/options apply when URTs have OPEN=DB specified.  

Per IBM documentation, the LE RTEREUS parameter can be specified as a run time PARM on the application EXEC statement. Should they decide to set the LPAR default to RTEREUS ON, then they can include RTEREUS OFF on all batch CA Datacom jobs. Below is a sample EXEC statement:

 

//STEP120  EXEC PGM=PQI75,(PARM='RTEREUS=OFF/DBURT=URT0142P',COND=(0,LT)    

                                                                            

A second option when RTEREUS ON is the default is to re-assemble all URTs with LE=YES specified and re-link them to their user applications.  LE=YES is a part of the DBURINF macro. This should also allow applications to end successfully since the URT code would then know LE is involved.             

                                                                            

If the LE=YES option is selected, then the RTEREUS parameter need not be specified but the placement of other parameters on the application EXEC PARM statement are impacted.

LE uses a slash '/' to separate its input parameters from the applications.  When LE=YES is chosen, the DBURT parameter in the PARM statement must follow a slash.  Below are sample EXEC statements:      

 

LE=NO                                                                       

//STEP120  EXEC PGM=PQI75,PARM='DBURT=URT0142P',COND=(0,LT)                 

 

LE=YES                                                                      

//STEP120  EXEC PGM=PQI75,PARM=(/'DBURT=URT0142P'),COND=(0,LT)          

 

 

Environment

Release:
Component: DB