Setting Up User Restrictions
A primary function of ChangeMan ZMF is to protect and regulate your valuable code. To do this, there are specific choices to be made about ChangeMan ZMF functions. For example, do you want to allow two users to work on the same component at the same time?
Many of these choices are set by parameters in ChangeMan ZMF itself. Part of this implementation of ChangeMan ZMF is setting these parameters in the global and application administration functions. By setting these parameters, you further define the functions the end users have and access. In the above example, the parameter would be “Allow Concurrent Checkout”. If this parameter is set to “no”, only one person can work on the component at any given time.
Setting Up Global Administration and Setting Up Application Administration detail the set up requirements and identify some of the policies you may want to set.
Allow Temporary Change Packages
A temporary change package is not permanent and may never be rippled into baseline. It is automatically deleted from production after a specified number of days (the user provides this information). The staging library contents associated with temporary change packages are placed into temporary libraries which are concatenated ahead of production libraries. They are never rippled into baseline and are deleted from the temporary libraries after a specified number of days by ChangeMan ZMF.
If the you restrict this option, the user is not allowed to select this change package option during package creation. If you allow temporary packages, users are required to enter the number of days the package is to remain in production after installation (duration number of days).
Work Request and Department Number Required
You can use the work request number and department number to track change packages in certain ChangeMan ZMF batch reports. They can also select viewing of package information within the Query function.
If you require all applications (and their users) to enter a work request number or a department number during change package creation, then users are not allowed to finish creating a change package without entering this information. (ChangeMan ZMF performs no validation checks on the number, but only that one is entered.)
Planned Installation Calendar
If you are the global administrator, you can set up a Planned Installation Calendar which limits the maximum number of planned changes that can be installed for any given date in the forthcoming 1820 days. See Restricting Administrator Access to the Application Function. Setting the maximum number to zero stops any planned package from being planned for installation on that date (unplanned change packages are not restricted by the calendar). This zero implies a non business day. A planned package cannot be scheduled for installation on a date that has already reached its maximum limit.
For the user, this information is accessible from the Dates option in the Build Change Package Menu. The user does not update the actual calendar. During package creation, they enter the desired installation date for each remote site selected to receive the package. ChangeMan ZMF verifies that the date is available and increments the calendar accordingly. If the date entered is not available (either the maximum allowable packages have been met or the date is blocked), the user is not be able to create the change package until a valid date is entered.
Unplanned change packages are not affected by this calendar.
Disable Installation Calendar
This option allows you to completely disable the Planned Installation Calendar. When a user creates a change package, ChangeMan ZMF only checks the install date to verify if it is a valid date, and disregards the maximum packages criteria.
Normal Business Hours
The application Planned Approval list is incorporated into any change package that is created within normal business hours. An unplanned package uses the Unplanned Approval list if it is created outside of normal business hours. Normal business hours are defined in global administration parameters.
Checkout Enforcement
You can set the checkout enforcement rule such that if a component exists in baseline, it must be checked out before it can be staged. There are levels to this rule:
| Level | Rule |
|---|---|
| 1 | Any component may be staged regardless of whether it exists in baseline or has been checked out to a package. ChangeMan ZMF does not check for the component's existence in the baseline libraries. |
| 2 | Users attempting to stage a component that exists in the baseline but has not been checked out must pass a security system ENTITY CHECK before the stage can proceed. The entity name is specified in the application parameter generation. Staging is not allowed if the user does not pass the entity check. |
| 3 | Disallow anyone from staging a component which exists in the baseline library but has not been checked out to the package requesting the stage. |
...
Allow Concurrent Checkout
This rule is used to dictate whether a user can check out components that are already checked out to another package. It only applies to planned packages, not emergency packages.
Validate Version During Staging
This option validates the component versions during staging. If the same component is in motion in two different packages, the first package to baseline ripple can force the user of the other package to halt development and recheckout the latest version of the component.
Staging Restriction Level
This option restricts who is allowed to stage NEW components. New components are not yet associated or checked out to a package.
| Level | Rule |
|---|---|
| 1 | All users can work on new components. This means they can stage components that are not yet associated with a packages (called development driven staging) as well as stage component that are associated with a package (called package driven staging). |
| 2 | Allows only users who have been defined to a special entity by their TSO ID to stage new components. Otherwise, they can only check out and stage components that are associated with a change package. |
| 3 | Does not allow you to stage new components, only ones currently associated with a package. This effectively disables development driven staging. |
...
Overlay Prior Staged Component
This rule can prevent someone from staging a component from a file outside of ChangeMan ZMF (stage from development) and overlaying another person’s work on the same component in the same change package.
Regardless of the setting for this rule, a warning is displayed if the stage from development will overlay an existing package component.
Audit Level
You cannot freeze the change package without passing audit. The Audit Level in application administration sets the maximum return code that audit may produce and still allow your change package to pass the audit:
| Audit Code | Explanation |
|---|---|
| 0 | Audit is recommended but not required. It may be performed, but this is optional. |
| 1 | Audit is required but any return code (except ABEND) is acceptable. |
| 2 | Audit is required but the return code must not exceed (12). This means that there are out-of-sync situations within this set of staging libraries |
| 3 | Audit is required but the return code must not exceed (8). This means that there are no out-of-sync situations within the staging libraries but there are out-of-sync situations within the baseline. |
| 4 | Audit is required but the return code must not exceed (4). This means that there are no out-of-sync situations in both staging and baseline sets of libraries, but there is at least one component of a staging library that is identical to the corresponding component in baseline (duplicate). |
| 5 | Audit is required but the return code must not exceed (0) which implies that there are no "out-of-synch" situations with either the staging libraries or the Baseline libraries, and no “duplicates” exist. |
...
Designated Compile Procedures
Change management best practices require consistent, repeatable build processes. ChangeMan ZMF offers a variety of controls over build processes and build options to provide you with the level of consistency you want, and the level of flexibility you want to offer to application developers when they work on components in packages.
| Level of Control | 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 presented 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 for use in build processing in the new package. |
| 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 compile procedure 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 compile procedure and build options that must always be used in build processing for the component. |
...
Designated compile procedures can completely eliminate variation in build processing for components before they are installed into production, and designated compile procedures can eliminate variation in development build processing as well.
Secured Components
If the administrator has chosen to secure one of the application's components to specific TSO IDs, generic TSO IDs, or to an Entity, only the TSO IDs associated with the component are allowed to check out or stage the component during change package development.
Approval Lists
The administrator has set up a list of approvers for this application's change packages, entity names associated with each approver description, and whether the approver will be called upon to approve packages (generated for another application) which impact this application. More than one TSO ID can be associated with each entity name so that packages can be approved when your regular approver is absent. When unplanned packages are created outside normal business hours, only the abbreviated list of approvers needs to be met. However, the installed package remains on the list of packages to be approved until the complete approval list is met. (This is called Post Approval and it is intended to facilitate emergency change packages.)