Customers must often create their own ZMF build procedures, or customize existing build procedures, to generate additional, related component types. When doing this it is often tempting to create generated components directly within the package staging dataset and to use that staging dataset as BAT90IN input to the associated BAT90/PGM=CMNBAT90 step.

This temptation should be avoided for several reasons, such as:

a) potential contention writing to the target dataset when multiple build requests execute concurrently.

b) incorrect relationships being generated for the SRC component.

Specifically for b), and as documented in the CMNBAT90 section of the ZMF Customization Guide (the 8.3 version of which can be found here), the BAT90IN dataset is a 'Library containing the build output components to be registered in the package master'. A component relationship (i.e. ‘SRC-to-LOD’ or ‘ILOD’) record will be written for the SRC component being built to every member contained in this BAT90IN dataset when the CMNBAT90 step executes. This will produce invalid and unpredictable results when a package contains more than one SRC component that produces members in this associated staging dataset.

Customers changing existing or writing their own build procedures should look at the manner in which distributed build procedures, such as CMNCOBE and its imbedded skels, handle generated component types (e.g. DBR, LOD, etc.). The general approach is to write all output components to a temporary dataset which is then passed to CMNBAT90 under the BAT90IN DD statement. The contents of the temporary dataset are then copied to the package staging library before the temporary file is discarded.