Well, I did do this. But, I am not sure it was worth it. The ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM check only tells me what I already knew. That I have some address spaces using user key common. I had hoped it went further and identified them. I know one for sure.....
Yes, I do see the info on interpreting SMF30_UserKeyCsaUsage and SMF30_UserKeyCadsUsage. So, I guess my next step is to see if my MXG level has this support, or do I need to update (in part, or fully) MXG. Or, alternatively, is there some ICE tool support for this question. > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Allan Staller > Sent: Monday, September 16, 2019 5:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > I just this the same thing. The DEBCHK lock function is a pe-chain that seems > it has run on for about 18 months. > I ended up bypassing 2 APARs that do not affect my installation. > > OA58037 is according to L2 support, a very specific set of conditions. > > IMO, it is OK to bypass an error hold, as long as you are aware of the > consequences (why else would IBM have written the code?). > It should not be done lightly, but it is OK to do so. > > HTH, > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Gibney, Dave > Sent: Friday, September 13, 2019 5:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Considering Bypassing ERROR HOLD for OA58037 > > 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 > ::DISCLAIMER:: > ________________________________ > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred errors) > shall therefore not attach any liability on the originator or HCL or its > affiliates. > Views or opinions, if any, presented in this email are solely those of the > author and may not necessarily reflect the views or opinions of HCL or its > affiliates. Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message without the > prior written consent of authorized representative of HCL is strictly > prohibited. If you have received this email in error please delete it and > notify > the sender immediately. Before opening any email and/or attachments, > please check them for viruses and other defects. > ________________________________ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
