Modifying EGL build scripts for z/OS®
- Compile and link for a COBOL program, including the code generated from an EGL program, library, service, FormGroup,or DataTable part.
- DB2® precompile and bind if a program, library or service performs SQL I/O.
- CICS® translation if a program, library or service is generated for the z/OS® CICS® environment.
These build scripts are developed using pseudo-JCL, a form of JCL with some restrictions and a few extensions, as described in Pseudo-JCL syntax.
The build server reads the pseudo-JCL and processes it to invoke the build program against the data sets specified in the program. Because the build scripts reference data sets that contain the location of the DB2® preprocessor, the CICS® translator, the COBOL compiler, and the z/OS® linkage editor, you need to modify the shipped build scripts to at least specify the actual locations of these code-preparation components.
- Open the PROCLIB on the System 390 build server. (For information about installing the z/OS® build server, see the IBM® Rational® COBOL Runtime Guide for zSeries®.)
- Select the member (build script) that you want to edit.
- Edit the member. For information about the predefined symbolic parameters that are always passed as environment variables when you build output for z/OS® environments, see Predefined symbolic parameters that are set automatically. For a list of substitution variables defined within EGL build scripts, see Predefined symbolic parameters that can be set by the user.
- Save the member.
Examples of modifying EGL build scripts
The following examples show common modifications that you can make to EGL build scripts.
Modifying location of build components used by EGL build scripts
It is likely that the PDS naming conventions for the compiler, linkage editor, and database libraries are not the same as those used in the EGL build scripts. To change the default values, you must modify the VARS statement in the EGL build scripts. The following example shows the VARS statement for the default CICS® and COBOL compiler libraries:
//DEFAULTS VARS EZEPID=USER,
// COBCICS=SYS1.SCEECICS,
// COBCOMP=SYS1.IGY.SIGYCOMP,
// COBLIB=SYS1.SCEELKED,
...To change the high level qualifier for these libraries to MYSYS, you would use the following syntax to change the VARS statement:
//DEFAULTS VARS EZEPID=USER,
// COBCICS=MYSYS.SCEECICS,
// COBCOMP=MYSYS.IGY.SIGYCOMP,
// COBLIB=MYSYS.SCEELKED,
...Alternatively, you can leave the values of COBCICS, COBCOMP, and COBLIB set to the defaults in the build scripts and set the corresponding predefined symbolic parameters COBCICS, COBCOMP, and COBLIB in the EGL build descriptor parts to the values you need.
You can make similar updates for the EGL libraries (ELA substitution variable) and the database libraries (DSNEXIT and DSNLOAD substitution variables) either in the build scripts or by setting the corresponding predefined symbolic parameters in the EGL build descriptor parts.
Modifying EGL build scripts to save generated COBOL source
//*UPLOAD EXEC PGM=IEFBR14
//*EZESRC DD DSN=&EZEPID..&SYSTEM..EZESRC,DISP=SHR,CCUEXT=CBL//UPLOAD EXEC PGM=IEFBR14
//EZESRC DD DSN=&EZEPID..&SYSTEM..EZESRC,DISP=SHR,CCUEXT=CBLOptions required in EGL build scripts
In EGL build scripts, certain preparation options are required if you are using DB2® UDB, the CICS® translator, or the COBOL compiler for z/OS®.
Required options for DB2® precompiler
- HOST(COB2)
- APOSTSQL
- QUOTE
Required options for CICS® translator
- COBOL2
- NOSEQ
- QUOTE
- SP
The DBCS option is required for the CICS® translator when DBCHAR or MBCHAR variables or literals are used. The build scripts automatically include this option based on the setting of the predefined symbolic parameter EZEDBCS, which in turn is set based on the use of DBCHAR or MBCHAR
Required options for COBOL compiler for z/OS®
- LIB
- NODYNAM (as further described later)
- NUMPROC(NOPFD)
- NOSEQ
- QUOTE
- RENT
- TRUNC(BIN)
Also, the DBCS option is required for the COBOL compiler when DBCHAR or MBCHAR variables or literals are used. The build scripts automatically include this option based on the setting of the predefined symbolic parameter EZEDBCS, which in turn is set based on the use of DBCHAR or MBCHAR.
- CALL IDENTIFIER is always a dynamic call. EGL generates this type of call for a call or transfer to program statement when you use the default linkage in a non-CICS environment. EGL also uses CALL IDENTIFIER for calls to DataTable programs and FormGroup print services programs. This usage lets you to generate Data Tables and FormGroups containing print forms independently of the programs that use them.
- CALL LITERAL is either a dynamic or static call based on the compiler
option. EGL generates this type of call for a call or transfer to
program statement when you request static linkage. EGL also generates
this type of call for calls to IBM® Rational® COBOL Runtime for zSeries® modules.
The following IBM® Rational® COBOL Runtime for zSeries® modules
are statically linked:
- A few modules that are used frequently
- A stub module that dynamically links to the major runtime functions
EGL requires the NODYNAM compiler option so that all CALL LITERAL statements are treated as static calls.
Compiler options controlled by build descriptor options
- The ARITH compiler option specifies the size of numeric fields. You can control the setting for the ARITH compiler option by setting the maxNumericDigits build descriptor option to 31 for ARITH(EXTEND), or to 18 for ARITH (COMPAT). EXTEND increases the maximum number of digits for numeric items from 18 to 31 and also affects how intermediate results are computed. The default for the build descriptor option is 31.
- The DATA compiler option specifies the whether data areas are acquired above or below the 16 MB boundary. You can control the setting for the DATA compiler option by setting the data build descriptor option to 24 for DATA(24), or to 31 for DATA(31). The default for the build descriptor option is 31.
Other COBOL compiler options in build scripts for z/OS®
- The OPTIMIZE compiler option provides faster runtime performance, but can significantly increase the compile time. Consider using the NOOPTIMIZE option during testing and the OPTIMIZE option when moving the program to production.
COBOL compiler options not found in build scripts for z/OS®
- Listing Options. You can set the COBLISTPARMS predefined symbolic
parameter to specify the combination of LIST, MAP, and OFFSET that
you require. The build scripts default COBLISTPARMS to NOLIST.
- LIST
Produces an assembler language expansion of the COBOL source code.
- MAP
Produces a listing of information from the COBOL DATA DIVISION, including a DATA DIVISION map, global tables, literal pools, nested program structure map, and program attributes.
- OFFSET
Produces a cross-reference listing of the hexadecimal offsets in the module and the corresponding COBOL statement number. This is recommended to help you while you are debugging your program in the runtime environment.
- LIST
- SSRANGE
Provides runtime subscript checking. NOSSRANGE eliminates runtime subscript checking. Because using NOSSRANGE can result in better performance, specify NOSSRANGE when you move the program to production.
- TEST
Produces object code that enables Debug Tool to perform batch and interactive debugging in your runtime environment.
For details on COBOL compiler options, refer to your compiler documentation.
COBOL compiler options that are not supported
The COBOL compiler option NAME is not supported.