Exception SYSMODs (HOLD)

SMP/E makes sure each SYSMOD has no unresolved exception data associated with it. Exception data is information specified on the ++HOLD statement. Each ++HOLD statement has a REASON operand specifying a character string that identifies the reason why the SYSMOD has been put into exception status. The following types of exception data are supported by SMP/E:

HOLDERROR
HOLDFIXCAT
HOLDSYSTEM (internal and external)
HOLDUSER

In addition, the ++HOLD statement may contain a CLASS operand, which specifies an alternative way to resolve exception data through the use of the BYPASS operand.

Exception data is considered resolved when one or more of the following are true:

HOLDERROR and HOLDFIXCAT exception data is considered resolved if any of the following conditions apply:
- The SYSMOD named as the reason ID for the exception is already applied or is superseded by a SYSMOD that is already applied.
- The SYSMOD named as the reason ID for the exception is being applied concurrently or is being superseded by a SYSMOD being applied concurrently.
- The applicable BYPASS operand is specified.
HOLDSYSTEM (internal) exception data is considered resolved if
- the SYSMOD ID specified on the ++HOLD defining the exception is found as a SYSMOD entry in the distribution zone OR
- the SYSMOD ID specified on the ++HOLD defining the exception is being superseded by a SYSMOD being accepted concurrently OR
- the applicable BYPASS operand is specified.
HOLDSYSTEM (external) exception data is considered resolved if the applicable BYPASS operand is specified.
HOLDUSER exception data is considered resolved if the applicable BYPASS operand is specified.

If all the exception data associated with a given SYSMOD is not resolved, SMP/E does not accept that SYSMOD. The SYSMOD is treated as though it had been specifically excluded. Messages are issued showing which exception data is not resolved, and the SYSMOD and reason IDs associated with the exception data are displayed in the SYSMOD Summary report.

Each category of exception data is resolved differently:

For HOLDERROR exception data the reason ID is actually the number of the APAR that caused the SYSMOD to be placed in exception status. As subsequent service is processed, the APAR will probably be superseded by a PTF. When this happens, the exception data is resolved and the first PTF is automatically processed. Therefore, it is generally not necessary to use the BYPASS operand to process SYSMODs with error reason IDs.
During any mass installation of SYSMODs, it should be expected that some SYSMODs are not accepted, because unresolved APARs are associated with them. During the installation of preventive service, these SYSMODs should not be investigated further; they will be installed later when a subsequent SYSMOD is produced that supersedes the reason ID associated with the exception data that is causing them to be held.

During the installation either of corrective service (that is, installing a PTF or an APAR because of a known problem in the system) or of a new function specifically requiring a SYSMOD, the reason IDs associated with the HOLDERROR exception data should be taken as the first piece of data for research. Research may provide a fix for the problem, in which case the SYSMOD and the fix can be accepted concurrently. If a fix is not available, you can either wait for one, or accept the SYSMOD using the appropriate BYPASS operand.
For HOLDFIXCAT exception data, the reason ID is the number of the APAR that caused the SYSMOD to be placed in the exception status. The APAR is associated with one or more fix categories. It is optional whether the HOLDFIXCAT exception data affects processing for the held SYSMOD, based on the fix categories of the HOLDFIXCAT and the fix categories of interest specified by the user. The fix categories of interest are specified on the FIXCAT operand or in the FIXCAT subentry of the active OPTIONS entry. If a fix category value on the HOLDFIXCAT exception matches any of those of interest to the user, then the held SYSMOD is not accepted until the APAR reason ID is resolved. If there are no matching fix categories, then the SYSMOD is not held for that HOLDFIXCAT exception.
For HOLDFIXCAT exceptions that must be resolved, the APAR is considered resolved when any one of the following conditions is true:
- The SYSMOD named as the reason ID (the APAR) is already accepted or has been superseded by a SYSMOD that is already accepted.
- The SYSMOD named as the reason ID (the APAR) is being accepted concurrently or is being superseded by a SYSMOD that is being accepted concurrently.
- An applicable BYPASS operand of HOLDCLASS or HOLDFIXCAT is specified.
For HOLDSYSTEM (internal) exception data the SYSMOD ID specified on the ++HOLD message control statement may be either
- the SYSMOD ID of the containing SYSMOD OR
- a SYSMOD ID of a SYSMOD superseded by the containing SYSMOD.
When it is the latter, the reason that the current SYSMOD contains the ++HOLD is because it was originally in the SYSMOD whose SYSMOD ID appears on the ++HOLD and that SYSMOD has been superseded by the current SYSMOD. The exception data is considered resolved if the SYSMOD specified on the ++HOLD is already installed or is being superseded by another SYSMOD that is being installed concurrently with the held SYSMOD. When this is the case, it is assumed that the user has already addressed the reason for the hold.

When it is the former, the held SYSMOD should be accepted by use of the BYPASS(HOLDSYS(reason_id)) operand once the reason for the hold is addressed.
For HOLDSYSTEM (external) exception data the associated reason ID is a 1- to 7-character string used to identify some action that must be taken before or after a SYSMOD is installed. System reason IDs are not SYSMOD IDs and are not specified in the supersede list of a SYSMOD. Therefore, SMP/E does not automatically release them.
SYSMODs held in this manner should be accepted by use of the BYPASS(HOLDSYS(reason_id)) operand. If you were to remove the system reason ID by using the ++RELEASE statement, you would then be able to install the SYSMOD, but you would also lose the information about any special processing required in order to accept that SYSMOD on another system.
For HOLDUSER exception data the associated reason ID is a 1-to 7-character string meaningful to the user. User reason IDs are not SYSMOD IDs and are not specified in the supersede list of a SYSMOD. Therefore, SMP/E does not automatically release them.
SYSMODs held in this manner should be accepted by use of the BYPASS(HOLDUSER) operand. If you were to remove the hold associated with user reason ID by using the ++RELEASE statement, you would then be able to install the SYSMOD, but you would also lose sight of the fact the SYSMOD has some special significance to the you, the user.