Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Example 12: Automatic release of system hold when ++HOLD keeps the originating SYSMOD ID SMP/E for z/OS Commands SA23-2275-01 |
|
Suppose you encounter a problem that is eventually identified as
an APAR (OZ00456) that had already been reported and fixed in module
MOD1234. IBM® support gave you
the number of a PTF (UZ00999) that contains a fix for the APAR. You
then checked to see if the PTF was available on the system having
the problem. It was, but UZ00999 contained the following ++HOLD that
had to be addressed (UZ00999 superseded UZ00111 and thereby had inherited
its ++HOLD):
You enlarged the data set and were now ready to install UZ00999. Of course, UZ00999 might need other PTFs installed along with it, so you decided to use the GROUP operand on the APPLY command. In order to get UZ00999 installed, you had to bypass the ACTION hold that UZ00999 contained. However, you did not want to inadvertently bypass any other ACTION holds that might be in effect for SYSMODs brought in by the GROUP operand, so you coded the BYPASS operand so that it would release only the ACTION hold for SYSMOD UZ00999. The APPLY command that you used was:
It turned out that a PRE of UZ00999 (UZ00444) was not installed and was therefore included in the APPLY operation by the GROUP operand. It also happened that UZ00444 also contained module MOD1234, which contained the fix for OZ00456, as well as another problem. In fact, UZ00444 also contained the ++HOLD that was in UZ00999, because UZ00444 also superseded UZ00111 and had inherited its ++HOLD. In this case, because the ++HOLD statements in UZ00444 and UZ00999 had kept the originating SYSMOD ID from being installed, and because UZ00999 was having the ++HOLD bypassed, SMP/E considers the ACTION hold to be addressed and will therefore automatically release the ACTION hold against UZ00444, even though you had not specifically named UZ00444 in the BYPASS operand. |
Copyright IBM Corporation 1990, 2014
|