On 08/12/2014 09:02 AM, Paul Gilmartin wrote: > On Tue, 12 Aug 2014 08:47:37 -0500, Joel C. Ewing wrote: >> If you don't download and RECEIVE all PTFs but manually request some >> specific PTF with its co-requisite maintenance, you probably wouldn't be >> shipped superseded PTF's, even if one of those is HIPER. That could get >> you into the situation which I believe prompted the original question, >> where you could have a PTF in house which may be your only in-house fix >> for a HIPER error but don't know it fixes a HIPER error. >> > Won't HOLDDATA identify the HIPER situation? (But the customer might > need to run REPORT ERRSYSMODS.) > > -- gil > > > I see from some recent examples that "++HOLD..." does indeed support a "CLASS(HIPER)" parameter. That certainly sounds like the ERRSYSMODS report should be able to allow you to determine that you have unresolved HIPER errors, but since the HOLD data would presumably point to the HIPER resolving PTF the part I'm not sure about is whether the ERRSYSMODS report would just report the resolving HIPER PTF from the HOLD data or whether it is now smart enough to also indicate a received superseding PTF that resolves the APAR if the HIPER PTF has not been received. I would be inclined to suspect that it does not go that far and that some manual research might still be required to tie the pieces together, but at least the SMP/E zones would appear to have sufficient data to potentially make the determination that there is both an unresolved HIPER error and that you have a received PTF that will resolve that APAR -- just no direct links to find the resolving superseding PTF without a search.
-- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
