What Is a Package?
packageis a set of
CA Endevoractions that might require approval before being executed. To create a package, the user defines SCL that specifies actions to be performed against Elements. The SCL in a package must be explicit. Wildcarding is
notallowed in any SCL contained in a package. When you create a package, you define it as a standard (default) package or as an emergency package. Emergency packages require approval from emergency approver groups. An emergency approver group must be given the authority to approve emergency packages. When creating a package, you must also specify whether it is a promotion package. A promotion package can contain Move actions only and can be easily reused. A promotion package can be either a standard or an emergency package.
Note:For information about how to create packages and perform package actions in foreground see Package Element Actions. For information about SCL statements for packages, see Manage Packages in Batch (Batch Package Facility).
You can use packages to do the following actions:
- Lock the Elements in a package. Locking prevents modification of the Element at the source of the package action, target of the package action, or both.
- Validate the actions in the package before executing the package.
- Require that a package be approved before it can be executed. Approver groups can be defined locally or to an external security product such as CA Top Secret for z/OS, IBM RACF, or CA ACF2 for z/OS.
- Inspect the Elements in a package for security, signout, synchronization conflicts, and source changes that might affect its successful execution.
- Validate package components to prevent Elements from being moved until the Elements have been assembled, compiled, or linked with current versions of all their dependencies.
- Restart a package if it fails during execution. The package is "checkpointed" and, when re-executed, begins at the first action that failed and re-executes the failed actions.
- Back out package outputs (and later back in) after a package has been executed.
- Ship package outputs to remote locations.
- Secure package actions using the External Security Interface (ESI) or using approver groups.
- Customize package processing using exit points before and after each package function,
- Execute package functions in batch mode.
The package lifecycle consists of five steps. A package is
reviewedby the appropriate approvers. When the package is approved, it is
executedand, when no further modifications are required, the package can be
committedand optionally archived and deleted.
After a package has been executed, its outputs can be backed out, backed in, or shipped to remote locations.
CA Endevorassigns packages a status at each phase of the lifecycle and provides exit points before and after all package functions.
The following table shows the change in package status that occurs when each package function is performed. The table also lists the next appropriate action after the specified package action is performed.
Createpackage (build, import, copy)
Modify or cast
Modifypackage (edit, import, copy)
Reset and correct
Backout, Backin, Ship, Commit
Correct and re-execute
Delete, Reset, Archive
None, Backin, Ship
None, Backout, Ship
None, Backout, Backin, Commit
At any time during package processing, you can reset a package to In-edit status. You can backout and backin a package as many times as necessary - until you commit the package.
A package must be reviewed if one or more approver groups are associated with the inventory areas included in the package. Once a package is in the review phase, only designated approvers can access the package and review its contents. If the Dynamic Approvers option is enabled in the
CA EndevorOptions Table, package approvers can add more users as one-time approvers for a particular package while it is in the in-approval state.
To be approved, a package must:
- Receive approval from at least the required approvers.
- Receive approval from a quorum of approvers.
- Not be denied approval by any approvers
A local approver group is an approver group which contains approver user IDs defined to
CA Endevor. An external approver group is an approver group which has no user IDs defined in
CA Endevor. Instead, the user IDs are defined to the external security packages such as CA Top Secret, RACF, or CA ACF2.
For more information about approver groups, see
Example: Use Approvers
The approver group PKGQA consists of three approvers. The approver group was established with a quorum size of 2, with one approver required. This means that in addition to the required approver, one of the two remaining members of the approver group must approve the package for it to be executed.
The following table shows the package status in relationship to the review phase:
Approved (if approval granted)
Denied (if approval not granted)
Reset and Correct
The package can be either executed online or submitted in batch. To execute the package, the user must have the authority to execute the package and the authority to perform the actions that are contained in the package.
The following table shows the package status in relationship to the execution phase. The outputs of packages that have been executed can be backed out, backed in, or shipped to remote locations.
Backout, backin, ship, or commit
Correct and re-execute, backout, backin
CA Endevorreleases Element locks during package execution. Each lock is released after the associated action completes successfully.
Package processing provides you with the ability to backout, and later backin, change packages, if necessary. The BACKOUT/BACKIN option is available only after you have executed a package. All package event information (user, date, and time information pertaining to each step of the package processing procedure), and backout/backin data, is maintained with the package until you commit the package.
Committing a package simply removes any backout/backin data while retaining package event information. Commit a package only when you are sure that you no longer need to back it out or in. The following table shows the package status in relationship to the commit phase:
Delete, Reset, Archive