Build Processing Controls
Change management best practices require consistent, repeatable build processes.
ChangeMan ZMF offers a variety methods to restrict build processing to provide administrators with the level of level consistency they want, and the level of flexibility they want to offer to application developers.
| Build Processing Consistency | ChangeMan ZMF Processes and Configuration |
|---|---|
| Minimum | The compile procedure and build options that a developer enters on ChangeMan ZMF panels are recorded in package component records. These values are shown on build process panels the next time a build process is initiated for the component in the package, but a developer can change the information. When the package is installed and the component is baselined, build process information stored in package component records is written to the Component History File. When the component is checked out to another package, the compile procedure and build options are copied from component history to package component records. These values are shown on build process panels when a build process is initiated for the component in the package, but a developer can change the information. |
| Medium | Some compile and link edit options are hard coded in compile procedure skeletons. Some compile and link edit options are prohibited, and if a developer uses them, the package cannot be frozen and the component cannot be selectively refrozen. (Exit program CMNEX025) |
| High | Application administrator defines a designated compile procedure with a Force Level 1 for single component or a group of components. The designated compile procedure specifies the compile procedure skeleton and build options that must be used the last time a component is built before the package is frozen. |
| Maximum | Application administrator defines a designated compile procedure with a Force Level 2 for single component or a group of components. The designated compile procedure specifies the compile procedure skeleton and build options that must always be used in build processing for the component. |
Designated Compile Procedures
A designated compile procedure imposes consistency in build processing for a component before it is installed into production. A designated compile procedure can eliminate all variation in build processing for a component throughout the development life cycle.
When your administrator defines a designated compile procedure in application administration, the following build process information is specified for a component name, or for a name pattern, in a library type, for an application.
| Field | Description |
|---|---|
| Language | The coding language of the like-source member. Valid language names are defined in application administration |
| Compile Procedure | The name of the main ISPF skeleton that is file tailored to create build job JCL. Valid compile procedure names are associated with a language name in application administration. |
| Compile Parms | A 34-byte field where users set compile options that are not set by: System defaults for the compiler. Options that are hard coded in Compile Procedure skeletons. User Options that set variables used by file tailoring to set compile options |
| Link Edit parms | A 34-byte field where users set linkage editor or binder options that are not set by: System defaults for the linkage editor or binder. Options that are hard coded in Compile Procedure skeletons. User Options that set variables used by file tailoring to set link edit or binder options |
| Db2 Precompile Indicator | An indicator that determines whether a Db2 precompile step is included in the build job JCL. |
| Force Level | Determines when the compile procedure and other build options in the designated procedure must be used. |
| 1. The compile procedure and build options in the designated procedure must be used in the last build before package freeze or component refreeze. | |
| 2. The compile procedure and build options in the designated procedure must always be used. | |
| Additional options | Fifty-eight fields ranging in length from 1-72 bytes that ChangeMan ZMF installers and administrators can define for variables or indicators used to file tailor JCL for build processing. |
See the ChangeMan/ZMF Administrator’s Guide - Setting up Application Administration for more details.
Build Information Search Order
Even when there is no designated compile procedure to impose consistency in build processing, ChangeMan ZMF encourages consistency by populating build processing panel fields with values used previously to build the component.
Change Man ZMF uses this search order to obtain values for the compile procedure skeleton and build options for a component. Component history is keyed by component name within library type.
| Search Sequence | Location of Build Information | Comment |
|---|---|---|
| 1 | Force Level 2 Designated Compile Procedure | Fields on build panels are set to the values in the designated procedure, and the fields are displayed in read-only mode. |
| 2 | Stage: Mass Build panel Batch Mass Recompile Job Information panel | If the Suppress History field is Y on these panels, panel values are used in build processing for all selected components. |
| 3 | Package Component Records | These records contain the values used the last time you performed a build for this component/library type in your package. These records are deleted if you delete the component from your package. |
| 4 | Component History | This history contains the values used to build the component/library type that was last baselined. |
| 5 | Designated Compile Procedure with Force Level 1 | Fields on build panels are set to the values in the designated procedure, but you can overtype the values. |
| 6 | Build process ISPF panel. | All required build panel fields must be filled to provide a default values in case they are needed for a new component. |