For your Friday :) This APAR is holding UA96589 for OA51485. Since OA51485 is an INTEGRITY PROBLEM, there is very little info on it. Reading OA51485, I think the issue is unlikely on my systems(s) I would likely on implement this bypass in sandboxes and maybe development LPARs.
The reason is that I would really like to have the ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM health check from OA53355/UA94607 But, UA94607 needs UA93212 which needs UA97270 which needs UA96464 which needs UA96468 which needs UA96527 which needs UA96536 which needs UA96586 which needs the held UA96589 As mentioned, I doubt I will encounter the problem of OA51485 or consider it a fatal issue if I do. OA58037: ABEND 16E RC=0 after CANCEL is issued during OPEN processing 19/08/12 PTF PECHANGE z/OS APAR status • OPEN Error description • This problem happens when a CANCEL is issued while the Access • Method Executors are processing an OPEN. • When this occurs, IFG0RR0A is called because of the ABEND13E. It • starts clean up and IFG0RR0B calls IGG020T1, which in turn goes • to IGG0201Z, it issues LOCKEXCL, which receives RSN - x'0C07'. • IGG0201Z at DEBCHKRB can handle that return, but makes one • additional check for - DEBXDEBLOCKX. It is not on so we continue • with ABEND16E-00, • • DEBCHK/K • The SMP/E APPLY step I've been cloning for decades includes a commented out BYPASS( /* HOLDERROR( ) So I must have done this at least once before. I have no recollection as to when or why 😊 Dave Gibney Information Technology Services Washington State University ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
