Generate Processing Overview

The Generate System is an integral part of Code Pipeline. This section gives an overview and describes the components involved.

Where are Generates performed?

In Code Pipeline, generates are generally only performed in the TEST and HOLD environments. The PROD environment is updated by copying the source and generated components from the HOLD environment to the PROD environment.

The last generate at a HOLD level can be considered to be the “production” generate. The PROD environment then contains what was tested and signed off in the HOLD environment.

TEST Versus HOLD Generates

Code Pipeline differentiates between generates performed in the TEST environment and generates performed in the HOLD environment. It is possible to have different generate panels and processing. The TEST level generates are normally performed under the requester’s userID, and HOLD generates are performed under some controlled ID.

Generate processing can be the same or different for both environments and is usually controlled by the code in the Generate Skeletons using MEMBENV=‘TEST’ or MEMBENV=‘HOLD’.

Automatic Generate After Promote

The Promote operation can automatically request a Generate for any “generate” component types, depending on the options set in the Reference Data (option AD, Flags). If the Generate Indicator is set to R (Required), a Generate will automatically be performed for that component at that level. If the Generate Indicator is set to O (Optional), an online generate may be performed from the Code Pipeline Task list. (A generate will not automatically be done in a Set in this case.)

Prevent Promote After Failed Generate

A subsequent promote operation can be prevented if the generate for a component has failed. It depends on the options set in the Reference Data (option AD, Flags). If the Check Generate Flag is set to Y (Yes), any attempt to perform a promote on a component where the last generate has failed will be rejected. If the Check Generate Flag is set to N (No) or blank, the promote will be allowed.

Pre-Exit and Post-Exit Processing

As with other Code Pipeline task line commands, the site can specify special processing to occur. This can be before the standard ‘G’ processing as a Pre- exit or after the standard processing as a Post-exit.

Exit Processing Phases

The standard ‘G’ processing calls an internal process with the following events occurring: If a pre-exit is defined for the technology or component type, it is invoked. If no pre-exit was defined or the return code from the pre-exit is 0, then routine WZZEXG# is invoked. If a post-exit is defined and the return code from WZZEXG# is 0 or 2, then it is invoked.

WZZEXG# Processing

WZZEXG# is the main processing routine for all generates and controls the display of the generate panel, update of the Permanent Generate Parameters, update of the Generate Extension Classes WZGPARMS and WZGWORK, and file tailoring and submission of any generate JCL. The basic functions it performs include the following:

• Retrieve the Permanent Generate Parameters from their respective Db2 tables and the WZGPARMS variables. These values are kept and versioned for each component. For new components, new rows are added to the tables and extension classes.
• For a foreground generate, display the appropriate generate panel (TEST or HOLD) as specified in M.CT/M.AD to allow the user to modify generate parameters/variables.
• If it is a TEST generate and the user has changed a parameter value, update the Generate Parameters if indicated by UPDTFLAG=’Y’. Setting of this flag is usually controlled in the TEST panel. Parameters are not normally updated in HOLD, although the jobcard and other information may be input.
• Other processing is performed to validate and set variables used in generate processing and in the file tailoring of the skeletons.
• If this is a foreground generate, values are added to or updated in the Generate Extension Class WZGWORK. These values contain all of the temporary ISPF variables that would otherwise not be available for the demanded batch job. A foreground generate will also update any indicated parms from the generate panel in the WZGPARMS extension class.
• If this is a demanded background generate, the values previously stored in the WZGWORK extension class are retrieved.
• For compatibility with older versions of Code Pipeline, the Generate User Exit, WZXGEN1U, may still be called if it has been customized by a site, but Code Pipeline now recommends that site-specific generate processing be done in a routine defined to the CMPLEXIT variable. The information on the appropriate Generate Extension Class is retrieved so that all the information for the component is available in either the CMPLEXIT routine or WZXGEN1U. The site code is executed and any generate parms added to the temporary table $WZXGENX are retrieved and passed along to the subsequent file tailoring process. If the return code from the Generate User Exit is 0, the processing continues. If not, the processing is terminated.
• If the generate job is file tailored and submitted in foreground from the user’s TSO session (usually the case in a TEST generate), the following steps are executed:
  • The Generate Skeleton is file tailored.
  • The resulting job is submitted using the SUBMIT command.

• If this is a demanded background generate, Code Pipeline will submit a job under the Set Processor UserID. This batch job will, in turn, build and submit any required generate jobs. The following steps are executed:
  • The batch job to process the demanded generate is submitted.
  • The Generate Skeleton is file tailored.
  • The resulting job is submitted using the SUBMIT command.