Approving or Rejecting a Release Area

The release area approvals function allows you to view, approve, or reject release area operations. There are two types of release area approvals:

• Check in – Grants permission to check components in to the release area.

• Check off – Grants permission to check components in to the next area.

There are three approval functions for release areas:

• Notify – Notifies users and begins the check-in or check-off process.

• Approve - Grants permission for check-in or check-ff.

• Reject - Denies permission for check-in or check-off.

Notifying Area Check-in Approvers

Check-in approval opens a release area for package or area check-in. Check-in approval notification starts the check-in approval process by sending email and/or MVS send messages to people specified in approval definitions. Check-in approvals cannot be entered until the check-in approval notification function is executed.

Check-in approval notification also adds associated check-in approvers from the Global Release Management Approver List where conditions specified in the global definition are met in the area.

If the approval rule for an area is set to require check-in approval, and there are no check- in approvers defined for the area, execution of the check-in approval notification function sets the check-in approval flag to Y.

Approving an Area for Check-in

Check-in approval is an administrative process that grants permission for developers or release managers to populate the libraries for an area through the check-in function.

The requirement for check-in approval is determined by the area approval rule. Check-in approvals cannot be entered until the check-in approval notification function is executed, even if there are no notifications defined for any of the approvers.

If a check-in approver rejects the area, you must execute the Reset Check-in Approvers function. All check-in approvals entered up to that point are cleared. You must initiate the check-in approver notification process, and then enter all check-in approvals again.

Rejecting an Area for Check-in

Check-in approvers can reject an area for check-in, denying release managers or developers permission to populate area libraries.

The requirement for check-in approval is determined by the area approval rule. Check-in approvals cannot be entered until the check-in approval notification function is executed, even if there are no notifications defined for any of the approvers.

If a check-in approver rejects the area, you must execute the Reset Check-in Approvers function. All check-in approvals entered up to that point are cleared. You must initiate the check-in approver notification process, and then enter all check-in approvals again.

Notifying Area Check-off Approvers

Check-off approval signifies that an area is ready for check-in to the next area.

Check-off approval notification starts the check-off approval process. Check-off approvals cannot be entered until the check-off approval notification function is executed, even if there are no notifications defined for any of the approvers.

An area must be blocked to notify check-off approvers.

If the approval rule for an area is set to require check-off approval, and there are no check-off approvers defined for the area, execution of the check-off approval notification function will set the check-off approval flag to Y.

Approving Area Check-off

Check-off approval is an administrative function that grants permission to check-in the contents of area libraries to the next area.

The requirement for check-off approval is determined by the area approval rule. Check-off approvals cannot be entered until the check-off approval notification function is executed, even if there are no notifications defined for any of the approvers.

If a check-off approver rejects the area, you must unblock the area. All check-off approvals entered up to that point are cleared. When the approver’s issue is resolved, you must block the area, initiate the check-off approver notification process, and then enter all check-off approvals again.

Rejecting Area Check-off

Check-off approvers can reject an area for check-off, denying permission to check-in the contents of area libraries to the next area.

The requirement for check-off approval is determined by the area approval rule. Check-off approvals cannot be entered until the check-off approval notification function is executed, even if there are off notifications defined for any of the approvers.

If a check-off approver rejects the area, you must unblock the area. All check-off approvals entered up to that point are cleared. You must initiate the check-off approver notification process, and then enter all check-off approvals again.

Running Release Area Approvals

Right-click a release or release area in an eligible state and choose ZDD Network → Check in approvals or Check off approvals from the popup menu.

The Release Area Approval dialog box displays.

Select a release and release area from the drop-down lists. Choose the approval type, which can be either check-in or check-off.

Select an entry from the list of user roles. The buttons will be enabled or disabled depending on what functions are allowed for that role. The following table describes the functions:

Function	Description
Approve	Submits an "approve" request. When all approvers have approved the release area, check-in or check-off operations can proceed.
Reject	Displays the Reject Reasons dialog box for entering reject reasons. When you click OK, a “reject” request is submitted and check-in or check-off operations are disallowed.
Notify	Notifies approvers and begins the approval process.
Reset	Resets all check in approvals.
Block	Blocks the release area and locks it to prevent further changes.

Function	Description
Unblock	Unblocks an area and unlocks it to allow changes.
Test	Test the release area for errors. Compares the contents of a system or subsystem area to the contents of packages attached to the release