Components not checked out from BAS 0

Summary: List all staged components that were not checked out before.

Here is the clue for creating such report (the selection criteria):

• the hashing total of the baseline 0 version of the component at checkout time should be all zeroes (which limits the list to only those components for which no checkout was performed, possibly because a baseline 0 version of the component does not exist yet).
• the hashing total of the staged component is not all zeroes (to exclude staged components that are empty).
• the component should be of type like SRC, like CPY or like PDS.

Such report (and recreating it periodically) helps spotting CMN/ZMF users (via the userid corresponding to the stage request of such components) that do not use CMN/ZMF's checkout function (or for some reason don't use it). These situations may occur in case the checkout enforcement rule is turned of, because if turned on then CMN/ZMF will not accept a stage request for a component that exists in baseline, without first performing a checkout yet. This checkout enforcement rule can be turned on/of for by CMN/ZMF application, but not at the level of library types (enforcing the rule for library type SRC but not for library type XYZ is not possible). The typical reason why in most cases the rule is NOT turned is, is because there is at least 1 library type (like XYZ) for which its content is actually created/updated via some code generator (like for 4GL languages).

The major reason for trying to identify such components, is to encourage CMN/ZMF users to perform a checkout request whenever possible, without enforcing it via the checkout enforcement rule. This because it will:

• allow CMN/ZMF to flag concurrent development situations from the moment they start happening (at checkout time, to both parties involved).
• enable CMN/ZMF audit warnings (SYNCH-flags) related to version regression issues (without a prior checkout, there is no way for CMN/ZMF to verify "if the baseline content has changed since the checkout was done ...").

Note: by adding an extra filter for library type (LTP Type) and introducing a report variable for the package ID, this report can easily be enhanced to (a) not include the XYZ-like library types and (b) to run such report for a single package. Further transforming the saved JCL to create such report into an ISPF skeleton is straight forward also. Such skeleton can be included as an extra CMN/ZMF audit validation step, which would implement an enhanced version of CMN/ZMF's checkout enforcement rule, so that CMN/ZMF's audit function will not flag the XYZ-like components, and report all other components that were not checked out before (optionally combined with making audit fail in such cases).