Troubleshooting
Problem
SMP/E is being used to apply a PTF that has recently been released. However, the attempt fails because one of the modules that are being updated has a different maintenance level than is expected. A fix would be regressed if allowed to continue. This can also occur when processing an RSU, depending on the timing.
Symptom
Messages similar to the following are issued:
GIM38201E THERE IS A MODID ERROR FOR MOD ENTRY mmmmmmmm IN SYSMOD xxxxxxx.
GIM31901I SYSMOD xxxxxxx DOES NOT SPECIFY yyyyyyy ON THE PRE OR SUP OPERAND.
yyyyyyy IS THE RMID FOR MOD mmmmmmmm THAT IS CURRENTLY INSTALLED.
GIM22601I APPLY PROCESSING FAILED FOR SYSMOD xxxxxxx.
Where the values in these messages can start with:
mmmmmmmm Module Name | xxxxxxx PTF | yyyyyyy ++APAR |
EZA, EZB | UI | AI, BI, CI, ... |
IST, IVT | UA | AA, BA, CA, ... |
ISP, ISR | UA | AA, BA, CA, ... |
Cause
The SYSMOD identified by yyyyyyy is a test fix (++APAR) for an APAR opened after the one for the PTF identified by xxxxxxx. This ++APAR has as a PRErequisite the ++APAR for the PTF's APAR. The PTF for that second APAR is not yet available,
Diagnosing The Problem
Verify the following to ensure the described conditions match the state on this system:
- Use the SMP/E dialog to perform a QUERY of the PTF in the GLOBAL zone. Note the ++APAR(s) in the SUP list.
- QUERY the ++APAR identified in the message in the TARGET zone. Verify that its PRE list includes the ++APAR noted for the PTF.
Resolving The Problem
Because the test fix for the APAR being fixed by the PTF is already on the system, you do not need to immediately apply the PTF. Wait until the PTF for the second APAR becomes available, and then apply both PTFs in the same SMP/E run.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21695598