This section provides COBOL-specific information related to generating
COBOL for the z/OS and iSeries environments, including
the following topics:
- An overview of COBOL generation (this topic)
- COBOL program restrictions
- Inputs to COBOL generation
- Output of COBOL generation
- Modifying build scripts for z/OS
- Modifying build scripts for iSeries
- Preparing output for deployment
Overview of COBOL generation
This is an
overview illustrating the different phases of the generation process
as it applies to COBOL generation.
The process for generating
COBOL code and other output from EGL source actually consists of several
phases. The phases were covered briefly in the topic "Overview of
EGL generation". However, there are some specific differences between
the generation process for COBOL and the process for Java™. This topic gives a high level overview
of the COBOL generation process, focusing particularly on the details
specific to COBOL.
Here are the phases included in the generation
process, along with the parts required for each phase:
- Validation for the target runtime environment
- The first phase is the validation phase. The inputs required for
this phase are:
- The main part such as a program or library.
- The Build Descriptor part, which includes some or all of the following
information:
- The target runtime environment, specified in the system build
descriptor option.
- The name of the linkage options part, if any. This is specified
by the linkage build descriptor option.
- The name of the resource associations part, if any. This is specified
by the resourceAssociation build descriptor
option.
- A subset of the build descriptor options that are used during
the validation phase, such as the validateSQLStatements build
descriptor option.
The validation phase of generation is specific to the target
runtime environment. It does the following:- Validates that the source code is compatible with the target runtime
environment. For example, certain statements, such as sysLib.purge,
can only be used in specific environments.
- Validates that the entries in the linkage options part and resource
associations part are correct based on the target runtime environment.
- Validates according to any special requests, such as those associated
with the validateSQLStatements build descriptor
option.
- Production phase
- This second phase of the generation process includes the generation
of the actual COBOL code. The inputs for this phase are the following
artifacts:
- Validated EGL source code
- All the build descriptor options, including those validated in
validation phase
- Linkage options part
- Resource associations part
- Runtime JCL templates for z/OS or
runtime CL templates for iSeries
- COBOL reserved words file
- If your target environment is z/OS,
these additional inputs:
- Link edit part
- Bind control part
After generation, the output resulting from this phase consists
of the following artifacts:- COBOL source code
- A build plan that controls the preparation phase for COBOL; the
build plan is based on which build descriptors and symbolic parameters
were set
- Additional output based on the specific part being generated,
the target runtime environment, and the specific build descriptor
options that were set for your generation
Any error messages are shown in the EGL Generation Results view.
- Preparation phase
- The third phase of the generation process involves preparing the
output of generation to run in your target runtime environment. In
general, the preparation process is controlled by the build plan that
is created in the production phase and which can include the following
steps:
- Transfer of the output of generation to your build server system
using TCP/IP.
- Running the build scripts on the build server system, in order
to compile and link the output of generation; for CICS, the build scripts include a CICS translate step. For z/OS, if the program uses SQL, the build scripts
include steps for a DB2 precompile
and bind.
- Transferring the results of the preparation phase back to the
workstation using TCP/IP.
The build plan controls the order in which output are sent to
the remote build server and also controls which scripts are run on
the build server.