Re: APAR OA58438 (was Re: Planned ESQA change and HealthCheck)
On Fri, 4 Oct 2019 07:11:21 +, Martin Packer wrote: > >Interesting. And no I didn’t know about it. Question: At what stage does >the ESQA into ECSA check wave a red (or orange) flag? > >Cheers, Martin From monitors it depends I guess. But the OS does it right away via IRA103I SQA/ESQA HAS EXPANDED INTO CSA/ECSA BY x PAGES https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieam900/m013171.htm Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: APAR OA58438 (was Re: Planned ESQA change and HealthCheck)
Thanks Mark for the heads up. We've not seen the behavior noted in this APAR, although I am tracking it now for closure. In my case, got lazy over the years and hadn’t been paying attention to CSA/ECSA SQA/ESQA allocation and utilization that has crept up. ESQA has been hovering around 80-85% on my heavily used lpars. We've had one production system spill from ESQA to ECSA since our last IPL in early May. Since we've got our fall IPL's coming up, I'm adjusting it to get it back into a more comfortable range. _ 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 Mark Zelden Sent: Thursday, October 3, 2019 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: APAR OA58438 (was Re: Planned ESQA change and HealthCheck) **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** If you are running z/OS 2.3 and increasing ESQA because of expansion into ECSA messages or sudden unexplained growth, check out APAR OA58438. We had 3 system crashes after migrations to z/OS 2.3 in 2019 and one close call after ECSA got to 99% when ESQA expanded into it (only a vendor monitor crashed in that case after a failed ECSA getmain). Stand alone dumps didn't find the root cause other than we new it was RPB pool growth related to SVC dumps from CICS. In one case a single SVC dump caused an 80M ESQA spike within one or two seconds crashed a system when it spilled into ECSA and also filled up ECSA (typically at about 70% use, but "stable"). We worked with IBM all summer on this. We had different SLIPs and GTF traces put in place, but with the traces going the problem never happen. But SVC dump processing did take over the CPU with the trace + GTF active! :-) Meanwhile, we increased ESQA on 30 LPARs via normal IPLs over the summer by about 80M and ECSA a bit as a "work around". Settings that haven't been touched in god knows how long (certainly not since 64-bit usage has increased and HVCOMMON). So we had to loose about 100M of high private to do this. We also increased real storage on a couple of LPARs that really didn't warrant it (based on zero or close to zero demand paging during normal operations), but we knew real storage was also involved in the problem (no flash memory for SVC dumps on my client's mainframes). The entire time IBM has said we are the only ones reporting the problem, but since we had the problem in big sysplexes, small sysplexes, big LPARs, small LPARs, I know that we can't be the only ones. I think other shops are ignoring the ESQA expansion into ECSA (since that in itself doesn't hurt) and / or they have more "white space". The RPB control blocks are freed after about 10 minutes, so anyone looking at their current ESQA (and ECSA) usage wouldn't notice the spikes or would just say 'oh well, looks good now". Anyway, IBM was getting close to figuring this out not too long ago and partially re-created the problem in the lab some weeks ago and just got back to us today with the root cause and the APAR that was opened. It is related to being real storage constrained at the time of the SVC dumps (I think all of the crashes were during CICS startup time in the wee morning hours). I really wanted to post something about this earlier but didn't since IBM said they had no other reported problems, So if you have seen this problem since migrating to z/OS 2.3, now you know you aren't the only ones. -- 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: APAR OA58438 (was Re: Planned ESQA change and HealthCheck)
Interesting. And no I didn’t know about it. Question: At what stage does the ESQA into ECSA check wave a red (or orange) flag? Cheers, Martin Sent from my iPad > On 3 Oct 2019, at 22:34, Mark Zelden wrote: > > On Thu, 3 Oct 2019 16:18:32 -0500, Mark Zelden wrote: > >> If you are running z/OS 2.3 and increasing ESQA because of expansion into ECSA messages >> or sudden unexplained growth, check out APAR OA58438. >> >> We had 3 system crashes after migrations to z/OS 2.3 in 2019 and one close call after >> ECSA got to 99% when ESQA expanded into it (only a vendor monitor crashed in that >> case after a failed ECSA getmain). Stand alone dumps didn't find the root cause >> other than we new it was RPB pool growth related to SVC dumps from CICS. In one >> case a single SVC dump caused an 80M ESQA spike within one or two seconds crashed >> a system when it spilled into ECSA and also filled up ECSA (typically at about >> 70% use, but "stable"). >> >> We worked with IBM all summer on this. We had different SLIPs and GTF traces put in >> place, but with the traces going the problem never happen. But SVC dump processing >> did take over the CPU with the trace + GTF active! :-) >> >> Meanwhile, we increased ESQA on 30 LPARs via normal IPLs over the summer by about >> 80M and ECSA a bit as a "work around". Settings that haven't been touched in god knows >> how long (certainly not since 64-bit usage has increased and HVCOMMON). So we had >> to loose about 100M of high private to do this. We also increased real storage on a >> couple of LPARs that really didn't warrant it (based on zero or close to zero demand >> paging during normal operations), but we knew real storage was also involved in >> the problem (no flash memory for SVC dumps on my client's mainframes). >> >> The entire time IBM has said we are the only ones reporting the problem, but since we >> had the problem in big sysplexes, small sysplexes, big LPARs, small LPARs, I know that >> we can't be the only ones. I think other shops are ignoring the ESQA expansion into >> ECSA (since that in itself doesn't hurt) and / or they have more "white space". The >> RPB control blocks are freed after about 10 minutes, so anyone looking at their >> current ESQA (and ECSA) usage wouldn't notice the spikes or would just say 'oh well, >> looks good now". >> >> Anyway, IBM was getting close to figuring this out not too long ago and partially >> re-created the problem in the lab some weeks ago and just got back to us today >> with the root cause and the APAR that was opened. It is related to being real >> storage constrained at the time of the SVC dumps (I think all of the crashes were >> during CICS startup time in the wee morning hours). >> >> I really wanted to post something about this earlier but didn't since IBM said >> they had no other reported problems, So if you have seen this problem since >> migrating to z/OS 2.3, now you know you aren't the only ones. >> > > > One thing I didn’t mention in the post (well, I did the first time I started to compose it, > but accidentally closed the window) is that one may not even notice the problem because > the RPB pools are releases after some period of time (10-15 minutes?). So if one looked > at any given point in time ESQA usage would be “normal”. The only clue would be Health > Checker messages if Health Checker was running or some other monitor tripping > an ESQA threshold hit or expansion into ECSA. > > > Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > ITIL v3 Foundation Certified > mailto:m...@mzelden.com > Mark's MVS Utilities: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mzelden.com_mvsutil.html=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=43S2JiirvFMh4tAR2Cl0rV7xrOMLxgWPfM46UlAhBvY=NjRA6txmJh5iEmctzIV1vmrUwRbMU9MrRo8bzD7-aq4= > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: APAR OA58438 (was Re: Planned ESQA change and HealthCheck)
On Thu, 3 Oct 2019 16:18:32 -0500, Mark Zelden wrote: >If you are running z/OS 2.3 and increasing ESQA because of expansion into ECSA >messages >or sudden unexplained growth, check out APAR OA58438. > >We had 3 system crashes after migrations to z/OS 2.3 in 2019 and one close >call after >ECSA got to 99% when ESQA expanded into it (only a vendor monitor crashed in >that >case after a failed ECSA getmain). Stand alone dumps didn't find the root >cause >other than we new it was RPB pool growth related to SVC dumps from CICS. In >one >case a single SVC dump caused an 80M ESQA spike within one or two seconds >crashed >a system when it spilled into ECSA and also filled up ECSA (typically at about >70% use, but "stable"). > >We worked with IBM all summer on this. We had different SLIPs and GTF traces >put in >place, but with the traces going the problem never happen. But SVC dump >processing >did take over the CPU with the trace + GTF active! :-) > >Meanwhile, we increased ESQA on 30 LPARs via normal IPLs over the summer by >about >80M and ECSA a bit as a "work around". Settings that haven't been touched in >god knows >how long (certainly not since 64-bit usage has increased and HVCOMMON). So >we had >to loose about 100M of high private to do this. We also increased real >storage on a >couple of LPARs that really didn't warrant it (based on zero or close to zero >demand >paging during normal operations), but we knew real storage was also involved in >the problem (no flash memory for SVC dumps on my client's mainframes). > >The entire time IBM has said we are the only ones reporting the problem, but >since we >had the problem in big sysplexes, small sysplexes, big LPARs, small LPARs, I >know that >we can't be the only ones. I think other shops are ignoring the ESQA >expansion into >ECSA (since that in itself doesn't hurt) and / or they have more "white >space". The >RPB control blocks are freed after about 10 minutes, so anyone looking at their >current ESQA (and ECSA) usage wouldn't notice the spikes or would just say 'oh >well, >looks good now". > >Anyway, IBM was getting close to figuring this out not too long ago and >partially >re-created the problem in the lab some weeks ago and just got back to us today >with the root cause and the APAR that was opened. It is related to being real >storage constrained at the time of the SVC dumps (I think all of the crashes >were >during CICS startup time in the wee morning hours). > >I really wanted to post something about this earlier but didn't since IBM said >they had no other reported problems, So if you have seen this problem since >migrating to z/OS 2.3, now you know you aren't the only ones. > One thing I didn’t mention in the post (well, I did the first time I started to compose it, but accidentally closed the window) is that one may not even notice the problem because the RPB pools are releases after some period of time (10-15 minutes?). So if one looked at any given point in time ESQA usage would be “normal”. The only clue would be Health Checker messages if Health Checker was running or some other monitor tripping an ESQA threshold hit or expansion into ECSA. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
APAR OA58438 (was Re: Planned ESQA change and HealthCheck)
If you are running z/OS 2.3 and increasing ESQA because of expansion into ECSA messages or sudden unexplained growth, check out APAR OA58438. We had 3 system crashes after migrations to z/OS 2.3 in 2019 and one close call after ECSA got to 99% when ESQA expanded into it (only a vendor monitor crashed in that case after a failed ECSA getmain). Stand alone dumps didn't find the root cause other than we new it was RPB pool growth related to SVC dumps from CICS. In one case a single SVC dump caused an 80M ESQA spike within one or two seconds crashed a system when it spilled into ECSA and also filled up ECSA (typically at about 70% use, but "stable"). We worked with IBM all summer on this. We had different SLIPs and GTF traces put in place, but with the traces going the problem never happen. But SVC dump processing did take over the CPU with the trace + GTF active! :-) Meanwhile, we increased ESQA on 30 LPARs via normal IPLs over the summer by about 80M and ECSA a bit as a "work around". Settings that haven't been touched in god knows how long (certainly not since 64-bit usage has increased and HVCOMMON). So we had to loose about 100M of high private to do this. We also increased real storage on a couple of LPARs that really didn't warrant it (based on zero or close to zero demand paging during normal operations), but we knew real storage was also involved in the problem (no flash memory for SVC dumps on my client's mainframes). The entire time IBM has said we are the only ones reporting the problem, but since we had the problem in big sysplexes, small sysplexes, big LPARs, small LPARs, I know that we can't be the only ones. I think other shops are ignoring the ESQA expansion into ECSA (since that in itself doesn't hurt) and / or they have more "white space". The RPB control blocks are freed after about 10 minutes, so anyone looking at their current ESQA (and ECSA) usage wouldn't notice the spikes or would just say 'oh well, looks good now". Anyway, IBM was getting close to figuring this out not too long ago and partially re-created the problem in the lab some weeks ago and just got back to us today with the root cause and the APAR that was opened. It is related to being real storage constrained at the time of the SVC dumps (I think all of the crashes were during CICS startup time in the wee morning hours). I really wanted to post something about this earlier but didn't since IBM said they had no other reported problems, So if you have seen this problem since migrating to z/OS 2.3, now you know you aren't the only ones. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Planned ESQA change and HealthCheck
Radoslaw, Rest assured that your post elicited only admiration. Most of us are familiar with the noun 'anathema', which allowed us to decode the verb formation with minimal effort. I was also impressed that Windows 10 spell checker did not blink over the verb. I cannot promise to follow my granddaughter's endearing practice of sprinkling my daily conversation with this cool new word--although it is political campaign season here, so opportunities may arise. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, October 3, 2019 4:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Planned ESQA change and HealthCheck Jesse, It is English word, taken from dictionary. Actually it has Latin root, and the word is similar to Polish "anatema" which mean "klątwa" (noun) and also has Latin roots. BTW: my dictionary (bab.la) says that "klątwa" in English is "curse" or "anathema". And Polish "anatema" is ..."anathema". So, I see no mistake in using "anathematized". I also sustain my words about HealthChecker quick and dirty procedure. Yes, there is a risk of anathema... Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 18:38, Jesse 1 Robinson pisze: > I stand in awe of the Polish guru who can both entertain and educate. > Including English vocabulary. No anathematization here. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: Tuesday, October 1, 2019 7:24 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Planned ESQA change and HealthCheck > > (I will be anathematized for the text below) Simple solution: > stop HZSPROC > delete HZSDATA dataset > create it again using plain IEFBR14 or any other method - just empty PS > dataset start HZSPROC > > It works. No animal will be injured by deletion of the dataset. No climate > change will happen when you create new dataset using cursed method as the > above. Some prophets say it may happen badly, but it had never happened yet... > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-10-01 o 13:25, Jousma, David pisze: >> Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. >> But how do I reset the history is still outstanding. >> >> Thanks, Dave >> >> _ >> 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 >> Jousma, David >> Sent: Tuesday, October 1, 2019 7:20 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Planned ESQA change and HealthCheck >> >> **CAUTION EXTERNAL EMAIL** >> >> **DO NOT open attachments or click on links from unknown senders or >> unexpected emails** >> >> Ok, This is one of those dumb moments...IPLed one of my tech systems last >> night with a planned increase of ESQA. The associated health check popped >> after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. >> It's not clear to me how to reset the history for this healthcheck so that >> it doesn't show as a critical problem. In my guessing, I ended up deleting >> that check. >> >> So how do I get it back(short of IPLing), and how do I reset the history >> since this was a planned change? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Planned ESQA change and HealthCheck
Jesse, It is English word, taken from dictionary. Actually it has Latin root, and the word is similar to Polish "anatema" which mean "klątwa" (noun) and also has Latin roots. BTW: my dictionary (bab.la) says that "klątwa" in English is "curse" or "anathema". And Polish "anatema" is ..."anathema". So, I see no mistake in using "anathematized". I also sustain my words about HealthChecker quick and dirty procedure. Yes, there is a risk of anathema... Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 18:38, Jesse 1 Robinson pisze: I stand in awe of the Polish guru who can both entertain and educate. Including English vocabulary. No anathematization here. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, October 1, 2019 7:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Planned ESQA change and HealthCheck (I will be anathematized for the text below) Simple solution: stop HZSPROC delete HZSDATA dataset create it again using plain IEFBR14 or any other method - just empty PS dataset start HZSPROC It works. No animal will be injured by deletion of the dataset. No climate change will happen when you create new dataset using cursed method as the above. Some prophets say it may happen badly, but it had never happened yet... -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 13:25, Jousma, David pisze: Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. But how do I reset the history is still outstanding. Thanks, Dave _ 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 Jousma, David Sent: Tuesday, October 1, 2019 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Planned ESQA change and HealthCheck **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Ok, This is one of those dumb moments...IPLed one of my tech systems last night with a planned increase of ESQA. The associated health check popped after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. It's not clear to me how to reset the history for this healthcheck so that it doesn't show as a critical problem. In my guessing, I ended up deleting that check. So how do I get it back(short of IPLing), and how do I reset the history since this was a planned change? == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Planned ESQA change and HealthCheck
I've found that foreigners who learned English in school often speak better English than native Anglophones but make certain characteristic grammatical errors (different errors for different native languages.) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Richards, Robert B. <01c91f408b9e-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, October 1, 2019 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Planned ESQA change and HealthCheck Skip, I have found that a lots of "English as a second language" folks speak better English than the rest of us. I had to refresh my memory using the dictionary when Radoslaw trotted out "anathematized". I *hate* it when people do that! I stand in awe behind you. :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 1, 2019 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Planned ESQA change and HealthCheck I stand in awe of the Polish guru who can both entertain and educate. Including English vocabulary. No anathematization here. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, October 1, 2019 7:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Planned ESQA change and HealthCheck (I will be anathematized for the text below) Simple solution: stop HZSPROC delete HZSDATA dataset create it again using plain IEFBR14 or any other method - just empty PS dataset start HZSPROC It works. No animal will be injured by deletion of the dataset. No climate change will happen when you create new dataset using cursed method as the above. Some prophets say it may happen badly, but it had never happened yet... -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 13:25, Jousma, David pisze: > Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. > But how do I reset the history is still outstanding. > > Thanks, Dave > > __ > ___ > 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 Jousma, David > Sent: Tuesday, October 1, 2019 7:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Planned ESQA change and HealthCheck > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Ok, This is one of those dumb moments...IPLed one of my tech systems last > night with a planned increase of ESQA. The associated health check popped > after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. > It's not clear to me how to reset the history for this healthcheck so that > it doesn't show as a critical problem. In my guessing, I ended up deleting > that check. > > So how do I get it back(short of IPLing), and how do I reset the history > since this was a planned change? > -- 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: Planned ESQA change and HealthCheck
The choices (most mentioned by one or more posts) for the current IPL are among delete the check (usually a bad choice) deactivating the check changing the check parameters changing the frequency at which the check runs (many checks support something like this, I did not try to see if the check in question does) acknowledging that you have seen the exception so that subsequent checks are based on that acknowledged state rather than the state from the previous IPL, precisely to avoid reporting on situations that you are aware of starting a new "persistent data" data set (highly discouraged -- that history can be valuable just not for the OP's specific case) And re-IPL will base its new reporting on the previous IPL (which in this case will be the larger size). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Planned ESQA change and HealthCheck
Maybe it is not that bad: I did not know the word either and maybe Radoslaw also had to look the English translation of the Polish word. But I might just as well be part of his English vocabulary -;) Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Richards, Robert B. > Sent: 01 October, 2019 19:02 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Planned ESQA change and HealthCheck > > Skip, > > I have found that a lots of "English as a second language" folks speak > better English than the rest of us. I had to refresh my memory using the > dictionary when Radoslaw trotted out "anathematized". I *hate* it when > people do that! > > I stand in awe behind you. :-) > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: Tuesday, October 1, 2019 12:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Planned ESQA change and HealthCheck > > I stand in awe of the Polish guru who can both entertain and educate. > Including English vocabulary. No anathematization here. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of R.S. > Sent: Tuesday, October 1, 2019 7:24 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Planned ESQA change and HealthCheck > > (I will be anathematized for the text below) Simple solution: > stop HZSPROC > delete HZSDATA dataset > create it again using plain IEFBR14 or any other method - just empty PS > dataset start HZSPROC > > It works. No animal will be injured by deletion of the dataset. No climate > change will happen when you create new dataset using cursed method as the > above. Some prophets say it may happen badly, but it had never happened > yet... > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-10-01 o 13:25, Jousma, David pisze: > > Ok, I answered the first question. How to get it back, F > HZSPROC,ADDNEW. But how do I reset the history is still outstanding. > > > > Thanks, Dave > > > > __ > > ___ > > 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 Jousma, David > > Sent: Tuesday, October 1, 2019 7:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Planned ESQA change and HealthCheck > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > Ok, This is one of those dumb moments...IPLed one of my tech systems > last night with a planned increase of ESQA. The associated health check > popped after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease > in EPVT. It's not clear to me how to reset the history for this > healthcheck so that it doesn't show as a critical problem. In my > guessing, I ended up deleting that check. > > > > So how do I get it back(short of IPLing), and how do I reset the history > since this was a planned change? > > > > -- > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijk
Re: Planned ESQA change and HealthCheck
Skip, I have found that a lots of "English as a second language" folks speak better English than the rest of us. I had to refresh my memory using the dictionary when Radoslaw trotted out "anathematized". I *hate* it when people do that! I stand in awe behind you. :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 1, 2019 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Planned ESQA change and HealthCheck I stand in awe of the Polish guru who can both entertain and educate. Including English vocabulary. No anathematization here. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, October 1, 2019 7:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Planned ESQA change and HealthCheck (I will be anathematized for the text below) Simple solution: stop HZSPROC delete HZSDATA dataset create it again using plain IEFBR14 or any other method - just empty PS dataset start HZSPROC It works. No animal will be injured by deletion of the dataset. No climate change will happen when you create new dataset using cursed method as the above. Some prophets say it may happen badly, but it had never happened yet... -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 13:25, Jousma, David pisze: > Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. > But how do I reset the history is still outstanding. > > Thanks, Dave > > __ > ___ > 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 Jousma, David > Sent: Tuesday, October 1, 2019 7:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Planned ESQA change and HealthCheck > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Ok, This is one of those dumb moments...IPLed one of my tech systems last > night with a planned increase of ESQA. The associated health check popped > after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. > It's not clear to me how to reset the history for this healthcheck so that > it doesn't show as a critical problem. In my guessing, I ended up deleting > that check. > > So how do I get it back(short of IPLing), and how do I reset the history > since this was a planned change? > -- 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: Planned ESQA change and HealthCheck
I stand in awe of the Polish guru who can both entertain and educate. Including English vocabulary. No anathematization here. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, October 1, 2019 7:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Planned ESQA change and HealthCheck (I will be anathematized for the text below) Simple solution: stop HZSPROC delete HZSDATA dataset create it again using plain IEFBR14 or any other method - just empty PS dataset start HZSPROC It works. No animal will be injured by deletion of the dataset. No climate change will happen when you create new dataset using cursed method as the above. Some prophets say it may happen badly, but it had never happened yet... -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 13:25, Jousma, David pisze: > Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. > But how do I reset the history is still outstanding. > > Thanks, Dave > > _ > 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 > Jousma, David > Sent: Tuesday, October 1, 2019 7:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Planned ESQA change and HealthCheck > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Ok, This is one of those dumb moments...IPLed one of my tech systems last > night with a planned increase of ESQA. The associated health check popped > after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. > It's not clear to me how to reset the history for this healthcheck so that > it doesn't show as a critical problem. In my guessing, I ended up deleting > that check. > > So how do I get it back(short of IPLing), and how do I reset the history > since this was a planned change? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Planned ESQA change and HealthCheck
Thanks RS. We write the data to logstream, so that's not an option. Per IBM,
I did a dynamic update to the HC, bumping the ABOVE parameter to something
greater than our planned change, and refreshed the check. It will revert to
standard check after the follow IPL, at which time it should not trigger again.
UPDATE,
CHECK(IBMVSM,VSM_CSA_CHANGE),
INTERVAL(ONETIME),
SEVERITY(HIGH),
PARM('BELOW(1M),ABOVE(60M)'),
DATE('20190930')
_
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 R.S.
Sent: Tuesday, October 1, 2019 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Planned ESQA change and HealthCheck
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
(I will be anathematized for the text below) Simple solution:
stop HZSPROC
delete HZSDATA dataset
create it again using plain IEFBR14 or any other method - just empty PS dataset
start HZSPROC
It works. No animal will be injured by deletion of the dataset. No climate
change will happen when you create new dataset using cursed method as the
above. Some prophets say it may happen badly, but it had never happened yet...
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2019-10-01 o 13:25, Jousma, David pisze:
> Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW.
> But how do I reset the history is still outstanding.
>
> Thanks, Dave
>
> _
> 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
> Jousma, David
> Sent: Tuesday, October 1, 2019 7:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Planned ESQA change and HealthCheck
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Ok, This is one of those dumb moments...IPLed one of my tech systems last
> night with a planned increase of ESQA. The associated health check popped
> after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT.
> It's not clear to me how to reset the history for this healthcheck so that
> it doesn't show as a critical problem. In my guessing, I ended up deleting
> that check.
>
> So how do I get it back(short of IPLing), and how do I reset the history
> since this was a planned change?
>
==
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2019 r. wynosi 169.347.928 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.347.928 as at 1 January 2019.
--
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 unex
Re: Planned ESQA change and HealthCheck
(I will be anathematized for the text below) Simple solution: stop HZSPROC delete HZSDATA dataset create it again using plain IEFBR14 or any other method - just empty PS dataset start HZSPROC It works. No animal will be injured by deletion of the dataset. No climate change will happen when you create new dataset using cursed method as the above. Some prophets say it may happen badly, but it had never happened yet... -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-01 o 13:25, Jousma, David pisze: Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. But how do I reset the history is still outstanding. Thanks, Dave _ 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 Jousma, David Sent: Tuesday, October 1, 2019 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Planned ESQA change and HealthCheck **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Ok, This is one of those dumb moments...IPLed one of my tech systems last night with a planned increase of ESQA. The associated health check popped after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. It's not clear to me how to reset the history for this healthcheck so that it doesn't show as a critical problem. In my guessing, I ended up deleting that check. So how do I get it back(short of IPLing), and how do I reset the history since this was a planned change? == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Planned ESQA change and HealthCheck
Ok, I answered the first question. How to get it back, F HZSPROC,ADDNEW. But how do I reset the history is still outstanding. Thanks, Dave _ 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 Jousma, David Sent: Tuesday, October 1, 2019 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Planned ESQA change and HealthCheck **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Ok, This is one of those dumb moments...IPLed one of my tech systems last night with a planned increase of ESQA. The associated health check popped after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. It's not clear to me how to reset the history for this healthcheck so that it doesn't show as a critical problem. In my guessing, I ended up deleting that check. So how do I get it back(short of IPLing), and how do I reset the history since this was a planned change? _ Dave Jousma AVP | Manager, Systems Engineering [cid:image003.png@01D4F915.C9E34050] Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 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 **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
Planned ESQA change and HealthCheck
Ok, This is one of those dumb moments...IPLed one of my tech systems last night with a planned increase of ESQA. The associated health check popped after the IPL CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT. It's not clear to me how to reset the history for this healthcheck so that it doesn't show as a critical problem. In my guessing, I ended up deleting that check. So how do I get it back(short of IPLing), and how do I reset the history since this was a planned change? _ Dave Jousma AVP | Manager, Systems Engineering [cid:image003.png@01D4F915.C9E34050] Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 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
