Grace period for rejecting changes

Assume that while the sample setup is active, a z/OS® Explorer fix-pack with important fixes becomes available, but the timing of a banking project is such that various developers might be very weary of changing anything on their workstation right now.

To resolve the issue, the security administrator can grant all DEVBANK developers a grace period in which they can choose to postpone (reject) the update.

Setting up the grace period is a very simple process:

# start of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
  ID(DEVBANK) ACCESS(READ)

# activate changes
SETROPTS RACLIST(FACILITY) REFRESH

At the end of the grace period, the additional authority can be removed again:

# end of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
  ID(DEVBANK) DELETE

# activate changes
SETROPTS RACLIST(FACILITY) REFRESH

Note: The security administrator could also have created a FEK.PTC.REJECT.PRODUCT.UPDATES.*.DEVBANK profile with UACC(READ). This would permit all developers that bound their workspace to the DEVBANK group to reject product updates. The reject permit is not granted to developers who bound their workspace to the default group, even if they are a member of the DEVBANK group, as this is controlled by the FEK.PTC.REJECT.PRODUCT.UPDATES.* profile.