Re: Considering Bypassing ERROR HOLD for OA58037
I think I'm safe. Not nearly this volume and no dependency in SYS1.IMAGELIB > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Wednesday, September 18, 2019 1:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > When you are only about 1/2 thorough the apar list, if you print more than > 1000 jobs before restarting VPSIP, it would abend, the jobs all needed to > use|need SYS1.IMAGELIB. Then when we got to #18 on the list, the site > could produce 84,000+ jobs (again all needed SYS1.IMAGELIB), before the > abend. Now with the next 3 apars, we appear to be able to print an > unlimited number of jobs, but we split VPSIP into two separate regions and > restart them both weekly just in case, but once we get the final 2 on, we will > probably try to go without restarting any more. > > BRian > > > On Tue, 17 Sep 2019 18:44:02 +, Gibney, Dave > wrote: > > >Well, I do run VPS/TCPIP > >Key Product Name > >--- > >012 DRS > >001 VPS > >004 VPS/PCL > >002 VPS/TCPIP > > > >z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with > the error bypass. > >We don't have many printers, but they are all TCP/IP network attached. So > far I've not experienced (or at least not noticed) any of the errors in the > link. > > > >Since I found the Health Check disappointing, I could consider backing > >the bypassed PTFs out. I haven't looked. Are the SMF fields with the > >USERCSA data also part of one or more of the PTFs in this chain? There > >were 27 that went on with the bypass and selecting UA94607. (And 31 > >others that had dependencies satisfied :) ) > > > >Only running them in the sandboxes for now. > > > >> -----Original Message----- > >> From: IBM Mainframe Discussion List On > >> Behalf Of Brian Westerman > >> Sent: Monday, September 16, 2019 9:22 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > >> > >> That's part of a pretty long comedy of errors that apply to (mostly) > >> LRS's VPSIP product. If you are running VPSIP, like several of our > >> sites, then you are likely aware of the issues that this whole string of > aparas has caused. > >> > >> https://urldefense.proofpoint.com/v2/url?u=https- > >> 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > >> 2Dfunction-2Dlist- > >> > 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > >> b- > >> > Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp > >> 07SIADw0RnXZmcA=4Cib0hikGVj- > >> d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= > >> > >> If you are not using VPSIP then it probably won't effect you either > >> way to bypass the hold. > >> > >> Brian > >> > >> - > >> - 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 > > -- > 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
Re: Considering Bypassing ERROR HOLD for OA58037
That seems fair. If you don't have VPSIP, or don't use it to the extent that some of our clients do, then you are good to go. Brian On Tue, 17 Sep 2019 20:10:32 +, Gibney, Dave wrote: >The only reason I considered the bypass was because the PE chain was >preventing the APPLY of the PTFs to aid detecting and migrating from USERCSA. > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Jousma, David >> Sent: Tuesday, September 17, 2019 12:00 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Considering Bypassing ERROR HOLD for OA58037 >> >> I'm getting confused by this thread. I thought I recalled you had said the >> PTF >> you were bypassing was for S16E? All of those DEB Check PTF's are in >> support of the changes needed for OSPROTECT. And yes, we ran into the >> S16E issue on certain application datasets, only in a blue moon. >> Eventually, >> IBM got it all figured out, and the problem is fixed. I do recall they >> said they >> saw the problem in VPS, where VPS was opening/closing an IMAGELIB many >> times. >> >> But none of this had anything to do with USERKEY CSA.That’s an entirely >> different animal, and needs to be rectified before going V2.4. >> >> I suspect you won't have much luck backing these PTF's off because they >> reach out and touch a lot of different modules. The only real option would >> be if you have a known complete backup of the entire SMPE environment >> *before* the application of any of these PTF's. >> >> Incidentally, we do have UA95897 applied for over a year now, and have not >> run into the scenario that OA58037 describes. Seems like a pretty small >> window of problem, and even then, it was on a task/job that was being >> cancelled to begin with. I'd probably open ticket with IBM on that APAR, and >> ask an opinion (which they may not give). >> >> __ >> ___ >> Dave Jousma >> AVP | Manager, Systems Engineering >> >> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, >> MI >> 49546 >> 616.653.8429 | fax: 616.653.2717 >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Gibney, Dave >> Sent: Tuesday, September 17, 2019 2:44 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Considering Bypassing ERROR HOLD for OA58037 >> >> **CAUTION EXTERNAL EMAIL** >> >> **DO NOT open attachments or click on links from unknown senders or >> unexpected emails** >> >> Well, I do run VPS/TCPIP >> Key Product Name >> --- >> 012 DRS >> 001 VPS >> 004 VPS/PCL >> 002 VPS/TCPIP >> >> z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with >> the error bypass. >> We don't have many printers, but they are all TCP/IP network attached. So >> far I've not experienced (or at least not noticed) any of the errors in the >> link. >> >> Since I found the Health Check disappointing, I could consider backing the >> bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA >> data also part of one or more of the PTFs in this chain? There were 27 that >> went on with the bypass and selecting UA94607. (And 31 others that had >> dependencies satisfied :) ) >> >> Only running them in the sandboxes for now. >> >> > -Original Message- >> > From: IBM Mainframe Discussion List On >> > Behalf Of Brian Westerman >> > Sent: Monday, September 16, 2019 9:22 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 >> > >> > That's part of a pretty long comedy of errors that apply to (mostly) >> > LRS's VPSIP product. If you are running VPSIP, like several of our >> > sites, then you are likely aware of the issues that this whole string of >> > aparas >> has caused. >> > >> > https://urldefense.proofpoint.com/v2/url?u=https- >> > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- >> > 2Dfunction-2Dlist- >> > >> 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ >> > b- >> > >> Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp >> > 07SIADw0RnXZmcA=4Cib0hikGVj- >> > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= >> > >> > If you are not using VPSIP then it probably won't effect you eithe
Re: Considering Bypassing ERROR HOLD for OA58037
You run into it when (for instance), VPSIP gets the 16e abend but won't come down. Unfortunately, we found it the 'hard" way by cancelling VPSIP only to have to IPL when IGC00020 went into a tight loop. It's still not completely fixed, but we know now not to let VPSIP get anywhere close to the limit before we recycle it. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
I completely agree, when I apply maintenance, I ALWAYS create an entirely new target and dlib zone, and I keep the old one for at least a year. Brian On Tue, 17 Sep 2019 14:23:56 -0500, Tom Marchant wrote: >On Tue, 17 Sep 2019 19:00:04 +, Jousma, David wrote: > >>I suspect you won't have much luck backing these PTF's off because they reach >>out and touch a lot of different modules. The only real option would be if >>you have a known complete backup of the entire SMPE environment *before* the >>application of any of these PTF's. > >Another reason to always clone target zones before applying maintenance. > >Here is another possible way to restore the PTFs that I have considered, but >haven't yet had a need to try. > >1. Clone your distribution zone and relate the cloned zone to your target zone. >2. Accept everything that is keeping you from restoring the PTFs in your >cloned zone. >3. Restore the PTFs. >4. Relate the target zone back to the original distribution zone. > >Actually, if I was doing it, I would clone both the target and distribution >zones. > >-- >Tom Marchant > >-- >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
Re: Considering Bypassing ERROR HOLD for OA58037
When you are only about 1/2 thorough the apar list, if you print more than 1000 jobs before restarting VPSIP, it would abend, the jobs all needed to use|need SYS1.IMAGELIB. Then when we got to #18 on the list, the site could produce 84,000+ jobs (again all needed SYS1.IMAGELIB), before the abend. Now with the next 3 apars, we appear to be able to print an unlimited number of jobs, but we split VPSIP into two separate regions and restart them both weekly just in case, but once we get the final 2 on, we will probably try to go without restarting any more. BRian On Tue, 17 Sep 2019 18:44:02 +, Gibney, Dave wrote: >Well, I do run VPS/TCPIP >Key Product Name >--- >012 DRS >001 VPS >004 VPS/PCL >002 VPS/TCPIP > >z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the >error bypass. >We don't have many printers, but they are all TCP/IP network attached. So far >I've not experienced (or at least not noticed) any of the errors in the link. > >Since I found the Health Check disappointing, I could consider backing the >bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data >also part of one or more of the PTFs in this chain? There were 27 that went on >with the bypass and selecting UA94607. (And 31 others that had dependencies >satisfied :) ) > >Only running them in the sandboxes for now. > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Brian Westerman >> Sent: Monday, September 16, 2019 9:22 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Considering Bypassing ERROR HOLD for OA58037 >> >> That's part of a pretty long comedy of errors that apply to (mostly) LRS's >> VPSIP product. If you are running VPSIP, like several of our sites, then you >> are likely aware of the issues that this whole string of aparas has caused. >> >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- >> 2Dfunction-2Dlist- >> 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ >> b- >> Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp >> 07SIADw0RnXZmcA=4Cib0hikGVj- >> d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= >> >> If you are not using VPSIP then it probably won't effect you either way to >> bypass the hold. >> >> Brian >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
Hello Dave, yes you do need a newer level of MXG:- Change 36.188 Support for new Bit 4 of SMF30_RAXFLAGS and creation of BUILD005 these new bit-level variables with explanation in label BUIL3005 SMF30_RAXFLAG0='RAX0*USERKEY*COMMON*AUDIT*ENABLED?' VMAC30 SMF30_RAXFLAG1='RAX1*USERKEY*COMON*AUDIT*USAGE?' Oct 16, 2018 SMF30_RAXFLAG2='RAX2*USERKEY*CADS*USAGE?' SMF30_RAXFLAG3='RAX3*USERKEY*CHANGE*KEY*USAGE?' SMF30_RAXFLAG4='RAX4*USERKEY*RUCSA*USAGE?' that are added to TYPE30_4/TYPE30_5/TYPE30_6/TYPE30_V and PDB.STEPS for BUILDPDB (JES2) and BUILDPD3 (JES3). (Variable RAXFLAGS was added in MXG 35.09.) Thanks to MP Welch, Bank of America, USA. Change 36.175 Support for SMF 30 User Key CSA Audit Enhancements adds VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and Sep 28, 2018 the TYPE30_5 datasets. Change 35.212 (MXG 35.09+) Sep Feb 28, 2018 2017 made the code change but the change text was still Sep 20, 2018 a "Reserved Change" until Feb 28, 2018, but had the old 35.212 Change Number, so it was only in CHANGESS member. The IBM Record Change was made by APAR OA53355, but will only be needed thru z/OS 2.3, as User Key Common Storage usage support ends there. This is Health Check ZOSMIGV22R3_NEXT_VSM_USERKEYCOMM. These APARs required no additional code changes: OA53434 Corrects IBM macros SMF30RPS,SMF30SDS lengths not field lengths so it has no impact on MXG. OA53289 Corrects value of SMF30HVR from zero to valid. OA45767 APAR that added the extra triplet caused OA53434 See Change 36.188 which added new bit-level variables. Change 35.212 Support for SMF 30 User Key CSA Audit Enhancements adds VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and Sep 28, 2017 the TYPE30_5 datasets. This code change has been in MXG Feb 28, 2018 35.09 and later, but this change text replaced previous "Reserved Change" on Feb 28, 2018. This field was added by APAR OA53355, but will only be needed thru z/OS 2.3, as User Key Common Storage usage support ends there. This is Health Check ZOSMIGV22R3_NEXT_VSM_USERKEYCOMM. These APARs required no additional code changes: OA53434 Corrects ASM DSECT Lengths, no MXG impact OA53289 Corrects value of SMF30HVR from zero to valid. OA45767 APAR that added the extra triplet caused OA53434 On Tue, 17 Sep 2019 18:58:50 +, Gibney, Dave wrote: >Thank you, and also Dave Jousma who sent similar (same?) code privately. >I suspect my MXG level (V2929) needs some updating before I can run it. I >ordered 37.06 yesterday. Will install (or use the tricks to run mixed levels) >today. >I may try the techniques to run directly off of SMF and build PDB on the fly >also. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
The only reason I considered the bypass was because the PE chain was preventing the APPLY of the PTFs to aid detecting and migrating from USERCSA. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jousma, David > Sent: Tuesday, September 17, 2019 12:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > I'm getting confused by this thread. I thought I recalled you had said the > PTF > you were bypassing was for S16E? All of those DEB Check PTF's are in > support of the changes needed for OSPROTECT. And yes, we ran into the > S16E issue on certain application datasets, only in a blue moon. Eventually, > IBM got it all figured out, and the problem is fixed. I do recall they said > they > saw the problem in VPS, where VPS was opening/closing an IMAGELIB many > times. > > But none of this had anything to do with USERKEY CSA.That’s an entirely > different animal, and needs to be rectified before going V2.4. > > I suspect you won't have much luck backing these PTF's off because they > reach out and touch a lot of different modules. The only real option would > be if you have a known complete backup of the entire SMPE environment > *before* the application of any of these PTF's. > > Incidentally, we do have UA95897 applied for over a year now, and have not > run into the scenario that OA58037 describes. Seems like a pretty small > window of problem, and even then, it was on a task/job that was being > cancelled to begin with. I'd probably open ticket with IBM on that APAR, and > ask an opinion (which they may not give). > > __ > ___ > Dave Jousma > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, > MI > 49546 > 616.653.8429 | fax: 616.653.2717 > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Tuesday, September 17, 2019 2:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Well, I do run VPS/TCPIP > Key Product Name > --- > 012 DRS > 001 VPS > 004 VPS/PCL > 002 VPS/TCPIP > > z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with > the error bypass. > We don't have many printers, but they are all TCP/IP network attached. So > far I've not experienced (or at least not noticed) any of the errors in the > link. > > Since I found the Health Check disappointing, I could consider backing the > bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA > data also part of one or more of the PTFs in this chain? There were 27 that > went on with the bypass and selecting UA94607. (And 31 others that had > dependencies satisfied :) ) > > Only running them in the sandboxes for now. > > > -----Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Brian Westerman > > Sent: Monday, September 16, 2019 9:22 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > > > That's part of a pretty long comedy of errors that apply to (mostly) > > LRS's VPSIP product. If you are running VPSIP, like several of our > > sites, then you are likely aware of the issues that this whole string of > > aparas > has caused. > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > > 2Dfunction-2Dlist- > > > 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > > b- > > > Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp > > 07SIADw0RnXZmcA=4Cib0hikGVj- > > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= > > > > If you are not using VPSIP then it probably won't effect you either > > way to bypass the hold. > > > > Brian > > > > -- > > 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 **CAUTION > EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unkn
Re: Considering Bypassing ERROR HOLD for OA58037
First, I consider many things. That doesn't mean I will ultimately decide to do them. If I consider further, I will of course start with RESTORE CHECK and evaluate the complexity, etc. Second, I ran ACCEPT for everything that would accept clean before I started this path. Applied all that was RSU* IBM*, or HIPER and not in error as a separate run before I did the bypass. So, I do a. Have back-ups of the state after ACCEPT and before APPLY(s) and b. It's a total of less that 100 PTFs total in the full difference between RSU1903 (prior and ACCEPTED state) and RSU1908 +error, now running in my sandboxes. But, before I do anything in the way of backing out or going forward I will look further into the likelihood of this actually adversely effecting my systems. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Marchant > Sent: Tuesday, September 17, 2019 12:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > On Tue, 17 Sep 2019 19:00:04 +, Jousma, David > wrote: > > >I suspect you won't have much luck backing these PTF's off because they > reach out and touch a lot of different modules. The only real option would > be if you have a known complete backup of the entire SMPE environment > *before* the application of any of these PTF's. > > Another reason to always clone target zones before applying maintenance. > > Here is another possible way to restore the PTFs that I have considered, but > haven't yet had a need to try. > > 1. Clone your distribution zone and relate the cloned zone to your target > zone. > 2. Accept everything that is keeping you from restoring the PTFs in your > cloned zone. > 3. Restore the PTFs. > 4. Relate the target zone back to the original distribution zone. > > Actually, if I was doing it, I would clone both the target and distribution > zones. > > -- > Tom Marchant > > -- > 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
Re: Considering Bypassing ERROR HOLD for OA58037
Incidentally, we do have UA95897 applied for over a year now, and have not run into the scenario that OA58037 describes. Seems like a pretty small window of problem, and even then, it was on a task/job that was being cancelled to begin with. I'd probably open ticket with IBM on that APAR, and ask an opinion (which they may not give). The above is what IBM told me as well. ::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
Re: Considering Bypassing ERROR HOLD for OA58037
On Tue, 17 Sep 2019 19:00:04 +, Jousma, David wrote: >I suspect you won't have much luck backing these PTF's off because they reach >out and touch a lot of different modules. The only real option would be if >you have a known complete backup of the entire SMPE environment *before* the >application of any of these PTF's. Another reason to always clone target zones before applying maintenance. Here is another possible way to restore the PTFs that I have considered, but haven't yet had a need to try. 1. Clone your distribution zone and relate the cloned zone to your target zone. 2. Accept everything that is keeping you from restoring the PTFs in your cloned zone. 3. Restore the PTFs. 4. Relate the target zone back to the original distribution zone. Actually, if I was doing it, I would clone both the target and distribution zones. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
I'm getting confused by this thread. I thought I recalled you had said the PTF you were bypassing was for S16E? All of those DEB Check PTF's are in support of the changes needed for OSPROTECT. And yes, we ran into the S16E issue on certain application datasets, only in a blue moon. Eventually, IBM got it all figured out, and the problem is fixed. I do recall they said they saw the problem in VPS, where VPS was opening/closing an IMAGELIB many times. But none of this had anything to do with USERKEY CSA.That’s an entirely different animal, and needs to be rectified before going V2.4. I suspect you won't have much luck backing these PTF's off because they reach out and touch a lot of different modules. The only real option would be if you have a known complete backup of the entire SMPE environment *before* the application of any of these PTF's. Incidentally, we do have UA95897 applied for over a year now, and have not run into the scenario that OA58037 describes. Seems like a pretty small window of problem, and even then, it was on a task/job that was being cancelled to begin with. I'd probably open ticket with IBM on that APAR, and ask an opinion (which they may not give). _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Tuesday, September 17, 2019 2:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Considering Bypassing ERROR HOLD for OA58037 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Well, I do run VPS/TCPIP Key Product Name --- 012 DRS 001 VPS 004 VPS/PCL 002 VPS/TCPIP z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the error bypass. We don't have many printers, but they are all TCP/IP network attached. So far I've not experienced (or at least not noticed) any of the errors in the link. Since I found the Health Check disappointing, I could consider backing the bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data also part of one or more of the PTFs in this chain? There were 27 that went on with the bypass and selecting UA94607. (And 31 others that had dependencies satisfied :) ) Only running them in the sandboxes for now. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Monday, September 16, 2019 9:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > That's part of a pretty long comedy of errors that apply to (mostly) > LRS's VPSIP product. If you are running VPSIP, like several of our > sites, then you are likely aware of the issues that this whole string of > aparas has caused. > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > 2Dfunction-2Dlist- > 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > b- > Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp > 07SIADw0RnXZmcA=4Cib0hikGVj- > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= > > If you are not using VPSIP then it probably won't effect you either > way to bypass the hold. > > Brian > > -- > 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
Thank you, and also Dave Jousma who sent similar (same?) code privately. I suspect my MXG level (V2929) needs some updating before I can run it. I ordered 37.06 yesterday. Will install (or use the tricks to run mixed levels) today. I may try the techniques to run directly off of SMF and build PDB on the fly also. And, thank you for the offer, Andrew Rowley. But, we've already paid Barry and I don't like to do free trial stuff when I know I'll never be buying the product. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bruce Hewson > Sent: Monday, September 16, 2019 9:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > On Mon, 16 Sep 2019 23:15:40 +, Gibney, Dave > wrote: > > >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. > > > > I forget who I got this code from, one of the list members websites:- > > > // EXPORT SYMLIST=* > //* > // SET DATE='06/01/2019' <<== SET Search Date > // SET SYSN=SYS1 <<== SET SYSTEM NAME > // SET SMFID=PRD1 <<== SET SMF ID > - - - - - - - - - - - - - - - - - - 63 Line(s) not > Displayed > //SYSINDD *,SYMBOLS=EXECSYS > > %INCLUDE SOURCLIB(TYPE30,SMFINTRV); > > DATA LIMIT; >SET PDB.SMFINTRV ; >IF CPUTM NE . ; > IF SMF30_RAXFLAGS='00'X THEN DELETE; > IF SMF30_RAXFLAGS='40'X THEN DELETE; > IF SMF30_RAXFLAGS='80'X THEN DELETE; > /* 1000 = 80 = AUDIT ON */ > /* 1001 = 90 = CHANGE KEY*/ > /* 1010 = A0 = CADS USAGE*/ > /* 1011 = B0 = CADS+CHANGE KEY */ > /* 1100 = C0 = CSA USAGE */ > /* 1101 = D0 = CSA+CHANGE KEY*/ > /* 1110 = E0 = CSA+CADS */ > /* = F0 = CSA+CADS+CHANGEKEY*/ > IF SMF30_RAXFLAGS='90'X THEN USERKEY='CHGKEY' ; > IF SMF30_RAXFLAGS='A0'X THEN USERKEY='CADS' ; > IF SMF30_RAXFLAGS='B0'X THEN USERKEY='CADS+CHGKEY' ; > IF SMF30_RAXFLAGS='C0'X THEN USERKEY='CSA' ; > IF SMF30_RAXFLAGS='D0'X THEN USERKEY='CSA+CHGKEY' ; > IF SMF30_RAXFLAGS='E0'X THEN USERKEY='CSA+CADS' ; > IF SMF30_RAXFLAGS='F0'X THEN USERKEY='CSA+CADS+CHGKEY' ; >RUN; > > PROC MEANS DATA=LIMIT SUM NWAY MISSING NONOBS PRINT; > CLASS SYSTEM JOB PROGRAM SMF30_RAXFLAGS USERKEY; > VAR CPUTM; > OUTPUT OUT=POSTAV1(DROP=_TYPE_) SUM = GCPU ; > > OPTIONS LS=80 ; > > PROC PRINTTO FILE=USERKEY ; > > PROC PRINT DATA=POSTAV1; >TITLE1 ' ' ; >TITLE2 'SMF30_USERKEY '; >ID SYSTEM PROGRAM SMF30_RAXFLAGS USERKEY ; >VAR JOB; >RUN; > /* > > -- > 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
Re: Considering Bypassing ERROR HOLD for OA58037
That is a LONG*** pe chain to restore/re-apply -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Tuesday, September 17, 2019 1:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Considering Bypassing ERROR HOLD for OA58037 Well, I do run VPS/TCPIP Key Product Name --- 012 DRS 001 VPS 004 VPS/PCL 002 VPS/TCPIP z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the error bypass. We don't have many printers, but they are all TCP/IP network attached. So far I've not experienced (or at least not noticed) any of the errors in the link. Since I found the Health Check disappointing, I could consider backing the bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data also part of one or more of the PTFs in this chain? There were 27 that went on with the bypass and selecting UA94607. (And 31 others that had dependencies satisfied :) ) Only running them in the sandboxes for now. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Monday, September 16, 2019 9:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > That's part of a pretty long comedy of errors that apply to (mostly) > LRS's VPSIP product. If you are running VPSIP, like several of our > sites, then you are likely aware of the issues that this whole string of > aparas has caused. > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-data=02%7C01%7Callan > .staller%40HCL.COM%7C86f7d61528b346b4d1da08d73b9f2984%7C189de737c93a4f > 5a8b686f4ca9941912%7C0%7C1%7C637043427118885256sdata=oli6MDONl2sj > 4xIwtOJ2Jkl5YzCyWwOJtfmqF2lpY7o%3Dreserved=0 > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > 2Dfunction-2Dlist- > 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > b- > Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp > 07SIADw0RnXZmcA=4Cib0hikGVj- > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= > > If you are not using VPSIP then it probably won't effect you either > way to bypass the hold. > > Brian > > -- > 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 ::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
Re: Considering Bypassing ERROR HOLD for OA58037
Well, I do run VPS/TCPIP Key Product Name --- 012 DRS 001 VPS 004 VPS/PCL 002 VPS/TCPIP z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the error bypass. We don't have many printers, but they are all TCP/IP network attached. So far I've not experienced (or at least not noticed) any of the errors in the link. Since I found the Health Check disappointing, I could consider backing the bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data also part of one or more of the PTFs in this chain? There were 27 that went on with the bypass and selecting UA94607. (And 31 others that had dependencies satisfied :) ) Only running them in the sandboxes for now. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Monday, September 16, 2019 9:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > That's part of a pretty long comedy of errors that apply to (mostly) LRS's > VPSIP product. If you are running VPSIP, like several of our sites, then you > are likely aware of the issues that this whole string of aparas has caused. > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > 2Dfunction-2Dlist- > 2Dmaintenance=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > b- > Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp > 07SIADw0RnXZmcA=4Cib0hikGVj- > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= > > If you are not using VPSIP then it probably won't effect you either way to > bypass the hold. > > Brian > > -- > 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
Re: Considering Bypassing ERROR HOLD for OA58037
On Mon, 16 Sep 2019 23:15:40 +, Gibney, Dave wrote: >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. > I forget who I got this code from, one of the list members websites:- // EXPORT SYMLIST=* //* // SET DATE='06/01/2019' <<== SET Search Date // SET SYSN=SYS1 <<== SET SYSTEM NAME // SET SMFID=PRD1 <<== SET SMF ID - - - - - - - - - - - - - - - - - - 63 Line(s) not Displayed //SYSINDD *,SYMBOLS=EXECSYS %INCLUDE SOURCLIB(TYPE30,SMFINTRV); DATA LIMIT; SET PDB.SMFINTRV ; IF CPUTM NE . ; IF SMF30_RAXFLAGS='00'X THEN DELETE; IF SMF30_RAXFLAGS='40'X THEN DELETE; IF SMF30_RAXFLAGS='80'X THEN DELETE; /* 1000 = 80 = AUDIT ON */ /* 1001 = 90 = CHANGE KEY*/ /* 1010 = A0 = CADS USAGE*/ /* 1011 = B0 = CADS+CHANGE KEY */ /* 1100 = C0 = CSA USAGE */ /* 1101 = D0 = CSA+CHANGE KEY*/ /* 1110 = E0 = CSA+CADS */ /* = F0 = CSA+CADS+CHANGEKEY*/ IF SMF30_RAXFLAGS='90'X THEN USERKEY='CHGKEY' ; IF SMF30_RAXFLAGS='A0'X THEN USERKEY='CADS' ; IF SMF30_RAXFLAGS='B0'X THEN USERKEY='CADS+CHGKEY' ; IF SMF30_RAXFLAGS='C0'X THEN USERKEY='CSA' ; IF SMF30_RAXFLAGS='D0'X THEN USERKEY='CSA+CHGKEY' ; IF SMF30_RAXFLAGS='E0'X THEN USERKEY='CSA+CADS' ; IF SMF30_RAXFLAGS='F0'X THEN USERKEY='CSA+CADS+CHGKEY' ; RUN; PROC MEANS DATA=LIMIT SUM NWAY MISSING NONOBS PRINT; CLASS SYSTEM JOB PROGRAM SMF30_RAXFLAGS USERKEY; VAR CPUTM; OUTPUT OUT=POSTAV1(DROP=_TYPE_) SUM = GCPU ; OPTIONS LS=80 ; PROC PRINTTO FILE=USERKEY ; PROC PRINT DATA=POSTAV1; TITLE1 ' ' ; TITLE2 'SMF30_USERKEY '; ID SYSTEM PROGRAM SMF30_RAXFLAGS USERKEY ; VAR JOB; RUN; /* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
That's part of a pretty long comedy of errors that apply to (mostly) LRS's VPSIP product. If you are running VPSIP, like several of our sites, then you are likely aware of the issues that this whole string of aparas has caused. https://www.ibm.com/support/pages/debchk-deb-lock-new-function-list-maintenance If you are not using VPSIP then it probably won't effect you either way to bypass the hold. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
On 17/09/2019 9:15 am, Gibney, Dave wrote: 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. You could use the EasySMF 30 day trial to find the address spaces. https://www.blackhillsoftware.com/30-day-trial/ Andrew Rowley -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
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 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 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
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 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
