On 08/11/2014 10:17 AM, Chase, John wrote: > It seems logical to me that a PTF which supersedes a HIPER PTF should itself > be ASSIGNed the HIPER SOURCEID flag, but in one current instance (UI19849, > which supersedes UI18382 whose APAR is flagged HIPER and DATALOSS) the > superseding PTF is not flagged HIPER. > > Is that perhaps an oversight by the team that created UI19849? It is > presumed that the fix in UI18382 is present in UI19849. > > TIA, > > -jc- > > ... One could argue both ways: For someone who already has RECEIVED or APPLIED UI18321, it would be appropriate for UI19849 to only be marked HIPER if the additional fixes in it should also be categorized HIPER. On the other hand, if it is ever possible for someone requesting UI19849 and not already having the PTF it SUPs to not also RECEIVE UI18321, then the importance of applying a non-HIPER UI19849 in that environment might be overlooked. The problem here is that the "HIPER" designation is associated with a PTF when in some cases it might more appropriately be associated with specific APARs. An ERROR HOLD for the critical APAR(s) should of course be distributed via HOLDDATA for appropriate SMP/E elements affected by a HIPER PTF, but I think there is no way to distinguish "critical" ERROR holds worthy of a HIPER PTF from lesser errors if you haven't also received the PTF with the explicit HIPER identification.
The simplest solution would be to just mark UI19849 HIPER but include (if the newest APARs are of lesser importance) a DOC HOLD indicating that UI19849 is not really HIPER if UI18321 is already or will be applied. This would require more manual effort if you had a good reason to apply HIPER PTFs but stay at the UI18321 level, but at least you have that option. -- 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
