Introduction

Most SYSMODs you receive from IBM® can be installed without additional considerations; you can simply receive, apply, and then accept them. For some SYSMODs, however, this is not possible. Examples of such SYSMODs are:

SYSMODs that were sent out to correct a problem but that either have not fixed the problem or have introduced a new problem. These are called PTFs in error, or PE PTFs.
SYSMODs that require special installation processing, such as a fix that must be concurrently installed on all processors in a network.
SYSMODs that introduce changes into the system that you should be made aware of, such as changes to operator messages or critical documentation changes.

In SMP/E terms, these SYSMODs are called exception SYSMODs. SMP/E supplies a function to automate the management of exception SYSMODs. SMP/E supports three categories of exception SYSMODs:

Error. PTFs in error (PE PTFs).
System. SYSMODs identified by IBM as requiring special processing or notification.
User. Any SYSMODs that you identify as requiring special processing.

Two MCSs are used to manage exception SYSMODs:

++HOLD puts a SYSMOD into exception status.
++RELEASE removes a PE PTF from exception status when it has been determined that the PTF was held erroneously.

++HOLD statements for system holds are usually built as part of the held PTF. ++RELEASE statements and ++HOLD statements for error or user holds must be in SMPHOLD. ++HOLD and ++RELEASE statements provided by SMPHOLD (external holds) identify the following:

The SYSMOD ID of the exception SYSMOD (that is, the SYSMOD being held).
The exception SYSMOD category.
The FMID to which that ++HOLD applies.
The reason the SYSMOD is being put into or was in exception status. This is a 1- to 7-character alphanumeric string called the reason ID.
- For error-category exception SYSMODs, SMP/E expects the reason ID to be the SYSMOD ID of the APAR reporting the problem.
- For system-category exception SYSMODs, SMP/E expects the reason ID to be a short description of the action required.
- For user-category exception SYSMODs, SMP/E makes no assumption about what the reason ID represents.
For more information about reason IDs, see z/OS SMP/E Reference.
Text describing why the SYSMOD is being put into exception status. This field is only for ++HOLD statements.
An alternative way to release the exception SYSMOD. This field is only for ++HOLD statements.
Every ++HOLD statement specifies a HOLD category of ERROR, SYSTEM, or USER. In addition to one of these categories, a ++HOLD statement may include a HOLD CLASS, which is an alternative way to release a held SYSMOD. For example, an exception SYSMOD may fix a problem more severe than the problem it introduces. The ++HOLD statement for that SYSMOD would have an ERROR reason ID that matches an APAR ID and a CLASS of ERREL.

++HOLD statements provided within a SYSMOD identify the same information. However, even though these internal holds are effective against the containing SYSMOD, the SYSMOD ID specified on the hold may be different from that of the containing SYSMOD, as long as the SYSMOD ID specified on the hold is superseded by the containing SYSMOD.

SMP/E then manages exception SYSMODs by actually managing the resolution of the problems described by the reason ID specified on the ++HOLD statement.

Subsequent topics of this topic describe how SMP/E uses HOLDDATA during the installation of a SYSMOD, where the exception SYSMOD statements come from, and how to process them. The topics on the RECEIVE command, the APPLY command, and the ACCEPT command in z/OS SMP/E Commands contain a much more detailed explanation of the material covered here.