Re: SQA overflow condition
Yes We took a dump of master address space ID 1 and it showed that some of the messages were not DOMed and it occupied the dataspace. The SYSCONS PDMODE was in yes for long time and it caused this issue So once I V CN(xxx),RESET.. the ESQA storage got released On Wed, Dec 13, 2023, 8:25 PM Paul Feller wrote: > Peter and others, > > This is a very interesting situation. My curiosity is peaked as to how > that storage would have shown in a display of CSA/SQA? Would the storage > be "listed" under the MASTER address space or would it be attributed to > SYSTEM or would it be under CONSOLE? > > > Paul > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of kekronbekron > Sent: Wednesday, December 13, 2023 7:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > Yup, I've used V CN(*),ROUT=ALL and V CN(*),ROUT=NONE right before and > right after IPLs to keep tabs on what's going on. > > > > On Wednesday, December 13th, 2023 at 18:32, Steve Horein < > steve.hor...@gmail.com> wrote: > > > > System Automation can use SYSCONS with the Processor Operations > > (ProcOps) functionality. I take advantage of that, having SYSCONS > > activated in PD mode 24/7, but issue VARY CN(),ROUT=NONE on that > > console once the system is fully up (the MONITOR JOBNAMES/SESS/STATUS > > console attribute is honored regardless of ROUT settings) . At system > > shutdown time, another VARY > > CN(),ROUT=(1,2,10) is issued for monitoring progress and "external" > > automation when the time comes. D C,CN= may show some > > > > undesirable routing codes or DEL attributes included in the CONSOLxx > > "DEVNUM(SYSCONS)" definitions. > > > > https://www.ibm.com/docs/en/zos/2.5.0?topic=rc-routing-code-meaning-1 > > https://www.ibm.com/docs/en/zos/2.5.0?topic=consolxx-syntax-parameters > > -console-statement > > > > On Wed, Dec 13, 2023 at 4:29 AM Peter dbajava...@gmail.com wrote: > > > > > Finally found the reason for this condition > > > > > > Our HMC operating system message(SYSCONS) were flooding with a > > > product error message > > > > > > After resetting the SYSCONS > > > > > > ESQA got a relief and deactivated SYSCONS from operating system > > > message console in HMC > > > > > > On Tue, Dec 12, 2023, 2:34 PM Peter dbajava...@gmail.com wrote: > > > > > > > Are there any tools available in cbttape to view 78-2 ? > > > > > > > > On Tue, Dec 12, 2023, 2:01 PM Martin Packer > > > > martin_pac...@uk.ibm.com > > > > wrote: > > > > > > > > > Right. To Allan’s point it’s CSA that shows up by key. Though > > > > > SQA subpools are in the 78-2. > > > > > > > > > > I also agree with Paul’s point that a longitudinal view can > > > > > prove helpful. Even Time Of Day could be helpful. Even comparing > > > > > one system to another, likewise. > > > > > > > > > > Cheers, Martin > > > > > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on > > > > > behalf of Paul Feller prjfeller1...@gmail.com > > > > > Date: Monday, 11 December 2023 at 14:20 > > > > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: [EXTERNAL] Re: SQA overflow condition Peter, several > > > > > people have given you some good suggestions. There are a few > > > > > things you need to think about. > > > > > > > > > > 1) As others have said, EQSA overflow is not a bad thing as long > > > > > as your ECSA is okay. At the place I last worked at we routinely > > > > > saw ESQA overflow on some of our larger lpars that had lots of > > > > > activity. > > > > > 2) Has you ESQA always been "running" high and now it finaly has > > > > > statred to overflowing? > > > > > 3) If you have RMF and have SMF history data you can look back > > > > > at how your CSA/SQA usage has been doing. You can use the batch > > > > > reporting function of RMF. I think the manual is "z/OS Resource > > > > > Measurement Facility Report Analysis" that should help you. > > > > > 4) I would suggest you talk to the vendor about your question > > > > > around the SVC module. > > > > > > > > > > Paul > > > > > > >
Re: SQA overflow condition
Peter and others, This is a very interesting situation. My curiosity is peaked as to how that storage would have shown in a display of CSA/SQA? Would the storage be "listed" under the MASTER address space or would it be attributed to SYSTEM or would it be under CONSOLE? Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Wednesday, December 13, 2023 7:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition Yup, I've used V CN(*),ROUT=ALL and V CN(*),ROUT=NONE right before and right after IPLs to keep tabs on what's going on. On Wednesday, December 13th, 2023 at 18:32, Steve Horein wrote: > System Automation can use SYSCONS with the Processor Operations > (ProcOps) functionality. I take advantage of that, having SYSCONS > activated in PD mode 24/7, but issue VARY CN(),ROUT=NONE on that > console once the system is fully up (the MONITOR JOBNAMES/SESS/STATUS > console attribute is honored regardless of ROUT settings) . At system > shutdown time, another VARY > CN(),ROUT=(1,2,10) is issued for monitoring progress and "external" > automation when the time comes. D C,CN= may show some > > undesirable routing codes or DEL attributes included in the CONSOLxx > "DEVNUM(SYSCONS)" definitions. > > https://www.ibm.com/docs/en/zos/2.5.0?topic=rc-routing-code-meaning-1 > https://www.ibm.com/docs/en/zos/2.5.0?topic=consolxx-syntax-parameters > -console-statement > > On Wed, Dec 13, 2023 at 4:29 AM Peter dbajava...@gmail.com wrote: > > > Finally found the reason for this condition > > > > Our HMC operating system message(SYSCONS) were flooding with a > > product error message > > > > After resetting the SYSCONS > > > > ESQA got a relief and deactivated SYSCONS from operating system > > message console in HMC > > > > On Tue, Dec 12, 2023, 2:34 PM Peter dbajava...@gmail.com wrote: > > > > > Are there any tools available in cbttape to view 78-2 ? > > > > > > On Tue, Dec 12, 2023, 2:01 PM Martin Packer > > > martin_pac...@uk.ibm.com > > > wrote: > > > > > > > Right. To Allan’s point it’s CSA that shows up by key. Though > > > > SQA subpools are in the 78-2. > > > > > > > > I also agree with Paul’s point that a longitudinal view can > > > > prove helpful. Even Time Of Day could be helpful. Even comparing > > > > one system to another, likewise. > > > > > > > > Cheers, Martin > > > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on > > > > behalf of Paul Feller prjfeller1...@gmail.com > > > > Date: Monday, 11 December 2023 at 14:20 > > > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: [EXTERNAL] Re: SQA overflow condition Peter, several > > > > people have given you some good suggestions. There are a few > > > > things you need to think about. > > > > > > > > 1) As others have said, EQSA overflow is not a bad thing as long > > > > as your ECSA is okay. At the place I last worked at we routinely > > > > saw ESQA overflow on some of our larger lpars that had lots of > > > > activity. > > > > 2) Has you ESQA always been "running" high and now it finaly has > > > > statred to overflowing? > > > > 3) If you have RMF and have SMF history data you can look back > > > > at how your CSA/SQA usage has been doing. You can use the batch > > > > reporting function of RMF. I think the manual is "z/OS Resource > > > > Measurement Facility Report Analysis" that should help you. > > > > 4) I would suggest you talk to the vendor about your question > > > > around the SVC module. > > > > > > > > Paul > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > Behalf Of Allan Staller > > > > Sent: Monday, December 11, 2023 7:39 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: SQA overflow condition > > > > > > > > Classification: Confidential > > > > > > > > RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It > > > > will show the alllocations, but not necessarily the "actual" user. > > > > E,g. VTAM, TCPIP,. > > > > > > > > HTH > > > > > > > > -Original Me
Re: SQA overflow condition
Yup, I've used V CN(*),ROUT=ALL and V CN(*),ROUT=NONE right before and right after IPLs to keep tabs on what's going on. On Wednesday, December 13th, 2023 at 18:32, Steve Horein wrote: > System Automation can use SYSCONS with the Processor Operations (ProcOps) > functionality. I take advantage of that, having SYSCONS activated in PD > mode 24/7, but issue VARY CN(),ROUT=NONE on that console once the system > is fully up (the MONITOR JOBNAMES/SESS/STATUS console attribute is honored > regardless of ROUT settings) . At system shutdown time, another VARY > CN(),ROUT=(1,2,10) is issued for monitoring progress and "external" > automation when the time comes. D C,CN= may show some > > undesirable routing codes or DEL attributes included in the CONSOLxx > "DEVNUM(SYSCONS)" definitions. > > https://www.ibm.com/docs/en/zos/2.5.0?topic=rc-routing-code-meaning-1 > https://www.ibm.com/docs/en/zos/2.5.0?topic=consolxx-syntax-parameters-console-statement > > On Wed, Dec 13, 2023 at 4:29 AM Peter dbajava...@gmail.com wrote: > > > Finally found the reason for this condition > > > > Our HMC operating system message(SYSCONS) were flooding with a product > > error message > > > > After resetting the SYSCONS > > > > ESQA got a relief and deactivated SYSCONS from operating system message > > console in HMC > > > > On Tue, Dec 12, 2023, 2:34 PM Peter dbajava...@gmail.com wrote: > > > > > Are there any tools available in cbttape to view 78-2 ? > > > > > > On Tue, Dec 12, 2023, 2:01 PM Martin Packer martin_pac...@uk.ibm.com > > > wrote: > > > > > > > Right. To Allan’s point it’s CSA that shows up by key. Though SQA > > > > subpools are in the 78-2. > > > > > > > > I also agree with Paul’s point that a longitudinal view can prove > > > > helpful. Even Time Of Day could be helpful. Even comparing one system to > > > > another, likewise. > > > > > > > > Cheers, Martin > > > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on > > > > behalf > > > > of Paul Feller prjfeller1...@gmail.com > > > > Date: Monday, 11 December 2023 at 14:20 > > > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: [EXTERNAL] Re: SQA overflow condition > > > > Peter, several people have given you some good suggestions. There are a > > > > few things you need to think about. > > > > > > > > 1) As others have said, EQSA overflow is not a bad thing as long as your > > > > ECSA is okay. At the place I last worked at we routinely saw ESQA > > > > overflow > > > > on some of our larger lpars that had lots of activity. > > > > 2) Has you ESQA always been "running" high and now it finaly has statred > > > > to overflowing? > > > > 3) If you have RMF and have SMF history data you can look back at how > > > > your CSA/SQA usage has been doing. You can use the batch reporting > > > > function of RMF. I think the manual is "z/OS Resource Measurement > > > > Facility > > > > Report Analysis" that should help you. > > > > 4) I would suggest you talk to the vendor about your question around the > > > > SVC module. > > > > > > > > Paul > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > Behalf > > > > Of Allan Staller > > > > Sent: Monday, December 11, 2023 7:39 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: SQA overflow condition > > > > > > > > Classification: Confidential > > > > > > > > RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will > > > > show the alllocations, but not necessarily the "actual" user. > > > > E,g. VTAM, TCPIP,. > > > > > > > > HTH > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > Behalf > > > > Of Peter > > > > Sent: Sunday, December 10, 2023 10:29 PM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: SQA overflow condition > > > > > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > > > the sender, Don’t click links or open attachments as it
Re: SQA overflow condition
System Automation can use SYSCONS with the Processor Operations (ProcOps) functionality. I take advantage of that, having SYSCONS activated in PD mode 24/7, but issue VARY CN(*),ROUT=NONE on that console once the system is fully up (the MONITOR JOBNAMES/SESS/STATUS console attribute is honored regardless of ROUT settings) . At system shutdown time, another VARY CN(*),ROUT=(1,2,10) is issued for monitoring progress and "external" automation when the time comes. D C,CN= may show some undesirable routing codes or DEL attributes included in the CONSOLxx "DEVNUM(SYSCONS)" definitions. https://www.ibm.com/docs/en/zos/2.5.0?topic=rc-routing-code-meaning-1 https://www.ibm.com/docs/en/zos/2.5.0?topic=consolxx-syntax-parameters-console-statement On Wed, Dec 13, 2023 at 4:29 AM Peter wrote: > Finally found the reason for this condition > > Our HMC operating system message(SYSCONS) were flooding with a product > error message > > After resetting the SYSCONS > > ESQA got a relief and deactivated SYSCONS from operating system message > console in HMC > > > > On Tue, Dec 12, 2023, 2:34 PM Peter wrote: > > > Are there any tools available in cbttape to view 78-2 ? > > > > > > > > On Tue, Dec 12, 2023, 2:01 PM Martin Packer > > wrote: > > > >> Right. To Allan’s point it’s CSA that shows up by key. Though SQA > >> subpools are in the 78-2. > >> > >> I also agree with Paul’s point that a longitudinal view can prove > >> helpful. Even Time Of Day could be helpful. Even comparing one system to > >> another, likewise. > >> > >> Cheers, Martin > >> > >> From: IBM Mainframe Discussion List on > behalf > >> of Paul Feller > >> Date: Monday, 11 December 2023 at 14:20 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: [EXTERNAL] Re: SQA overflow condition > >> Peter, several people have given you some good suggestions. There are a > >> few things you need to think about. > >> > >> 1) As others have said, EQSA overflow is not a bad thing as long as your > >> ECSA is okay. At the place I last worked at we routinely saw ESQA > overflow > >> on some of our larger lpars that had lots of activity. > >> 2) Has you ESQA always been "running" high and now it finaly has statred > >> to overflowing? > >> 3) If you have RMF and have SMF history data you can look back at how > >> your CSA/SQA usage has been doing. You can use the batch reporting > >> function of RMF. I think the manual is "z/OS Resource Measurement > Facility > >> Report Analysis" that should help you. > >> 4) I would suggest you talk to the vendor about your question around the > >> SVC module. > >> > >> > >> Paul > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf > >> Of Allan Staller > >> Sent: Monday, December 11, 2023 7:39 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: SQA overflow condition > >> > >> Classification: Confidential > >> > >> RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will > >> show the alllocations, but not necessarily the "actual" user. > >> E,g. VTAM, TCPIP,. > >> > >> HTH > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf > >> Of Peter > >> Sent: Sunday, December 10, 2023 10:29 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: SQA overflow condition > >> > >> [CAUTION: This Email is from outside the Organization. Unless you trust > >> the sender, Don’t click links or open attachments as it may be a > Phishing > >> email, which can steal your Information and compromise your Computer.] > >> > >> The ESQA usage has gone to 108%. > >> > >> Is there any tool available in CBTTAPEA which can tell me or trace SQA > >> users and who are not releasing the storage? > >> > >> On Mon, Nov 27, 2023, 5:37 PM Allan Staller < > >> 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> > Classification: Confidential > >> > > >> > 100% concur w/Martin > >> > > >> > -Original Message- > >> > From: IBM Mainframe Discussion List On > >> > Behalf Of Martin Packer > >> > Sent: Sunday, November 26, 2023 2:39 AM > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: Re: SQA overflow
Re: SQA overflow condition
Thank you. That’s an interesting learning point: That backed up console messages could cause this. I’m wondering if anybody can give more detail on how this could be. Also how to manage it. The latter as a resilience point. Thanks, Martin From: IBM Mainframe Discussion List on behalf of Peter Date: Wednesday, 13 December 2023 at 10:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SQA overflow condition Finally found the reason for this condition Our HMC operating system message(SYSCONS) were flooding with a product error message After resetting the SYSCONS ESQA got a relief and deactivated SYSCONS from operating system message console in HMC On Tue, Dec 12, 2023, 2:34 PM Peter wrote: > Are there any tools available in cbttape to view 78-2 ? > > > > On Tue, Dec 12, 2023, 2:01 PM Martin Packer > wrote: > >> Right. To Allan’s point it’s CSA that shows up by key. Though SQA >> subpools are in the 78-2. >> >> I also agree with Paul’s point that a longitudinal view can prove >> helpful. Even Time Of Day could be helpful. Even comparing one system to >> another, likewise. >> >> Cheers, Martin >> >> From: IBM Mainframe Discussion List on behalf >> of Paul Feller >> Date: Monday, 11 December 2023 at 14:20 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [EXTERNAL] Re: SQA overflow condition >> Peter, several people have given you some good suggestions. There are a >> few things you need to think about. >> >> 1) As others have said, EQSA overflow is not a bad thing as long as your >> ECSA is okay. At the place I last worked at we routinely saw ESQA overflow >> on some of our larger lpars that had lots of activity. >> 2) Has you ESQA always been "running" high and now it finaly has statred >> to overflowing? >> 3) If you have RMF and have SMF history data you can look back at how >> your CSA/SQA usage has been doing. You can use the batch reporting >> function of RMF. I think the manual is "z/OS Resource Measurement Facility >> Report Analysis" that should help you. >> 4) I would suggest you talk to the vendor about your question around the >> SVC module. >> >> >> Paul >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of Allan Staller >> Sent: Monday, December 11, 2023 7:39 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: SQA overflow condition >> >> Classification: Confidential >> >> RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will >> show the alllocations, but not necessarily the "actual" user. >> E,g. VTAM, TCPIP,. >> >> HTH >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of Peter >> Sent: Sunday, December 10, 2023 10:29 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: SQA overflow condition >> >> [CAUTION: This Email is from outside the Organization. Unless you trust >> the sender, Don’t click links or open attachments as it may be a Phishing >> email, which can steal your Information and compromise your Computer.] >> >> The ESQA usage has gone to 108%. >> >> Is there any tool available in CBTTAPEA which can tell me or trace SQA >> users and who are not releasing the storage? >> >> On Mon, Nov 27, 2023, 5:37 PM Allan Staller < >> 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: >> >> > Classification: Confidential >> > >> > 100% concur w/Martin >> > >> > -Original Message- >> > From: IBM Mainframe Discussion List On >> > Behalf Of Martin Packer >> > Sent: Sunday, November 26, 2023 2:39 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: SQA overflow condition >> > >> > [CAUTION: This Email is from outside the Organization. Unless you >> > trust the sender, Don’t click links or open attachments as it may be a >> > Phishing email, which can steal your Information and compromise your >> > Computer.] >> > >> > (This is not specific advice but a way of thinking about things.) >> > >> > SQA can, of course, overflow into CSA - with no real harm done. Unless >> > it causes CSA to go short. (CSA can't overflow into SQA, of course.) >> > >> > The above statements are true for both 24-bit and 31-bit. >> > >> > 1409K below the line, though, is pretty extreme - for 24 bit. If you >> > made SQA larger so that it only overflowed, say, by 100K there would >> > be no wasted virtual storage. >> &g
Re: SQA overflow condition
Finally found the reason for this condition Our HMC operating system message(SYSCONS) were flooding with a product error message After resetting the SYSCONS ESQA got a relief and deactivated SYSCONS from operating system message console in HMC On Tue, Dec 12, 2023, 2:34 PM Peter wrote: > Are there any tools available in cbttape to view 78-2 ? > > > > On Tue, Dec 12, 2023, 2:01 PM Martin Packer > wrote: > >> Right. To Allan’s point it’s CSA that shows up by key. Though SQA >> subpools are in the 78-2. >> >> I also agree with Paul’s point that a longitudinal view can prove >> helpful. Even Time Of Day could be helpful. Even comparing one system to >> another, likewise. >> >> Cheers, Martin >> >> From: IBM Mainframe Discussion List on behalf >> of Paul Feller >> Date: Monday, 11 December 2023 at 14:20 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [EXTERNAL] Re: SQA overflow condition >> Peter, several people have given you some good suggestions. There are a >> few things you need to think about. >> >> 1) As others have said, EQSA overflow is not a bad thing as long as your >> ECSA is okay. At the place I last worked at we routinely saw ESQA overflow >> on some of our larger lpars that had lots of activity. >> 2) Has you ESQA always been "running" high and now it finaly has statred >> to overflowing? >> 3) If you have RMF and have SMF history data you can look back at how >> your CSA/SQA usage has been doing. You can use the batch reporting >> function of RMF. I think the manual is "z/OS Resource Measurement Facility >> Report Analysis" that should help you. >> 4) I would suggest you talk to the vendor about your question around the >> SVC module. >> >> >> Paul >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of Allan Staller >> Sent: Monday, December 11, 2023 7:39 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: SQA overflow condition >> >> Classification: Confidential >> >> RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will >> show the alllocations, but not necessarily the "actual" user. >> E,g. VTAM, TCPIP,. >> >> HTH >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of Peter >> Sent: Sunday, December 10, 2023 10:29 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: SQA overflow condition >> >> [CAUTION: This Email is from outside the Organization. Unless you trust >> the sender, Don’t click links or open attachments as it may be a Phishing >> email, which can steal your Information and compromise your Computer.] >> >> The ESQA usage has gone to 108%. >> >> Is there any tool available in CBTTAPEA which can tell me or trace SQA >> users and who are not releasing the storage? >> >> On Mon, Nov 27, 2023, 5:37 PM Allan Staller < >> 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: >> >> > Classification: Confidential >> > >> > 100% concur w/Martin >> > >> > -Original Message- >> > From: IBM Mainframe Discussion List On >> > Behalf Of Martin Packer >> > Sent: Sunday, November 26, 2023 2:39 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: SQA overflow condition >> > >> > [CAUTION: This Email is from outside the Organization. Unless you >> > trust the sender, Don’t click links or open attachments as it may be a >> > Phishing email, which can steal your Information and compromise your >> > Computer.] >> > >> > (This is not specific advice but a way of thinking about things.) >> > >> > SQA can, of course, overflow into CSA - with no real harm done. Unless >> > it causes CSA to go short. (CSA can't overflow into SQA, of course.) >> > >> > The above statements are true for both 24-bit and 31-bit. >> > >> > 1409K below the line, though, is pretty extreme - for 24 bit. If you >> > made SQA larger so that it only overflowed, say, by 100K there would >> > be no wasted virtual storage. >> > >> > More importantly, check out the "free CSA" picture. You really don't >> > want to run out of that. For 24-bit you want a few hundred K free. >> > (But to achieve that might require losing 1MB of 24-bit private, which >> > might not be consequence free.) >> > >> > For 31 bit I like to see at least 100MB free ECSA, preferably more. >> > The
Re: SQA overflow condition
Are there any tools available in cbttape to view 78-2 ? On Tue, Dec 12, 2023, 2:01 PM Martin Packer wrote: > Right. To Allan’s point it’s CSA that shows up by key. Though SQA subpools > are in the 78-2. > > I also agree with Paul’s point that a longitudinal view can prove helpful. > Even Time Of Day could be helpful. Even comparing one system to another, > likewise. > > Cheers, Martin > > From: IBM Mainframe Discussion List on behalf > of Paul Feller > Date: Monday, 11 December 2023 at 14:20 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: SQA overflow condition > Peter, several people have given you some good suggestions. There are a > few things you need to think about. > > 1) As others have said, EQSA overflow is not a bad thing as long as your > ECSA is okay. At the place I last worked at we routinely saw ESQA overflow > on some of our larger lpars that had lots of activity. > 2) Has you ESQA always been "running" high and now it finaly has statred > to overflowing? > 3) If you have RMF and have SMF history data you can look back at how your > CSA/SQA usage has been doing. You can use the batch reporting function of > RMF. I think the manual is "z/OS Resource Measurement Facility Report > Analysis" that should help you. > 4) I would suggest you talk to the vendor about your question around the > SVC module. > > > Paul > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Allan Staller > Sent: Monday, December 11, 2023 7:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > Classification: Confidential > > RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will show > the alllocations, but not necessarily the "actual" user. > E,g. VTAM, TCPIP,. > > HTH > > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf > Of Peter > Sent: Sunday, December 10, 2023 10:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > The ESQA usage has gone to 108%. > > Is there any tool available in CBTTAPEA which can tell me or trace SQA > users and who are not releasing the storage? > > On Mon, Nov 27, 2023, 5:37 PM Allan Staller < > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > Classification: Confidential > > > > 100% concur w/Martin > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Martin Packer > > Sent: Sunday, November 26, 2023 2:39 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SQA overflow condition > > > > [CAUTION: This Email is from outside the Organization. Unless you > > trust the sender, Don’t click links or open attachments as it may be a > > Phishing email, which can steal your Information and compromise your > > Computer.] > > > > (This is not specific advice but a way of thinking about things.) > > > > SQA can, of course, overflow into CSA - with no real harm done. Unless > > it causes CSA to go short. (CSA can't overflow into SQA, of course.) > > > > The above statements are true for both 24-bit and 31-bit. > > > > 1409K below the line, though, is pretty extreme - for 24 bit. If you > > made SQA larger so that it only overflowed, say, by 100K there would > > be no wasted virtual storage. > > > > More importantly, check out the "free CSA" picture. You really don't > > want to run out of that. For 24-bit you want a few hundred K free. > > (But to achieve that might require losing 1MB of 24-bit private, which > > might not be consequence free.) > > > > For 31 bit I like to see at least 100MB free ECSA, preferably more. > > The reason is because ECSA is - in my experience - more volatile. > > > > Speaking of volatility, you need to plan defensively - as a problem > > can lead to surge in SQA and CSA usage . > > > > Final point: I would advocate using SMF 78-2 to build a picture of > > common storage usage - and how variable it is. Here is a blog post I > > wrote on the > > matter: > > > > htt ps:// > > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storag > > e > > > > (Take out the space to follow the URL - as my mail client turned it > > into an attachment.) > > > > Cheers, Martin > > > > Sent from my iPad >
Re: SQA overflow condition
Right. To Allan’s point it’s CSA that shows up by key. Though SQA subpools are in the 78-2. I also agree with Paul’s point that a longitudinal view can prove helpful. Even Time Of Day could be helpful. Even comparing one system to another, likewise. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Paul Feller Date: Monday, 11 December 2023 at 14:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SQA overflow condition Peter, several people have given you some good suggestions. There are a few things you need to think about. 1) As others have said, EQSA overflow is not a bad thing as long as your ECSA is okay. At the place I last worked at we routinely saw ESQA overflow on some of our larger lpars that had lots of activity. 2) Has you ESQA always been "running" high and now it finaly has statred to overflowing? 3) If you have RMF and have SMF history data you can look back at how your CSA/SQA usage has been doing. You can use the batch reporting function of RMF. I think the manual is "z/OS Resource Measurement Facility Report Analysis" that should help you. 4) I would suggest you talk to the vendor about your question around the SVC module. Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Monday, December 11, 2023 7:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition Classification: Confidential RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will show the alllocations, but not necessarily the "actual" user. E,g. VTAM, TCPIP,. HTH -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, December 10, 2023 10:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] The ESQA usage has gone to 108%. Is there any tool available in CBTTAPEA which can tell me or trace SQA users and who are not releasing the storage? On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > 100% concur w/Martin > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don’t click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless > it causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you > made SQA larger so that it only overflowed, say, by 100K there would > be no wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't > want to run out of that. For 24-bit you want a few hundred K free. > (But to achieve that might require losing 1MB of 24-bit private, which > might not be consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. > The reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem > can lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of > common storage usage - and how variable it is. Here is a blog post I > wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storag > e > > (Take out the space to follow the URL - as my mail client turned it > into an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor > > III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > CSA=(2000,30) > > > > > > > > SQA=(16,192) > > > > > > Hardware: z14 > > LPAR : 16gb memory > > zOS 2.4 > > >
Re: SQA overflow condition
Peter, several people have given you some good suggestions. There are a few things you need to think about. 1) As others have said, EQSA overflow is not a bad thing as long as your ECSA is okay. At the place I last worked at we routinely saw ESQA overflow on some of our larger lpars that had lots of activity. 2) Has you ESQA always been "running" high and now it finaly has statred to overflowing? 3) If you have RMF and have SMF history data you can look back at how your CSA/SQA usage has been doing. You can use the batch reporting function of RMF. I think the manual is "z/OS Resource Measurement Facility Report Analysis" that should help you. 4) I would suggest you talk to the vendor about your question around the SVC module. Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Monday, December 11, 2023 7:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition Classification: Confidential RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will show the alllocations, but not necessarily the "actual" user. E,g. VTAM, TCPIP,. HTH -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, December 10, 2023 10:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] The ESQA usage has gone to 108%. Is there any tool available in CBTTAPEA which can tell me or trace SQA users and who are not releasing the storage? On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > 100% concur w/Martin > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don’t click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless > it causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you > made SQA larger so that it only overflowed, say, by 100K there would > be no wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't > want to run out of that. For 24-bit you want a few hundred K free. > (But to achieve that might require losing 1MB of 24-bit private, which > might not be consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. > The reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem > can lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of > common storage usage - and how variable it is. Here is a blog post I > wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storag > e > > (Take out the space to follow the URL - as my mail client turned it > into an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor > > III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > CSA=(2000,30) > > > > > > > > SQA=(16,192) > > > > > > Hardware: z14 > > LPAR : 16gb memory > > zOS 2.4 > > > > Do I have think about tunning the SQA parameter ? > > > > Regards > > Peter > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > Unless otherwise stated above: > > IBM United Kingdom Limi
Re: SQA overflow condition
Classification: Confidential RMF will do this provided VSTOR(D) is specified in ERBRMFxx. It will show the alllocations, but not necessarily the "actual" user. E,g. VTAM, TCPIP,. HTH -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, December 10, 2023 10:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] The ESQA usage has gone to 108%. Is there any tool available in CBTTAPEA which can tell me or trace SQA users and who are not releasing the storage? On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > 100% concur w/Martin > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don’t click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless > it causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you > made SQA larger so that it only overflowed, say, by 100K there would > be no wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't > want to run out of that. For 24-bit you want a few hundred K free. > (But to achieve that might require losing 1MB of 24-bit private, which > might not be consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. > The reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem > can lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of > common storage usage - and how variable it is. Here is a blog post I > wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storag > e > > (Take out the space to follow the URL - as my mail client turned it > into an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor > > III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > CSA=(2000,30) > > > > > > > > SQA=(16,192) > > > > > > Hardware: z14 > > LPAR : 16gb memory > > zOS 2.4 > > > > Do I have think about tunning the SQA parameter ? > > > > Regards > > Peter > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 Registered office: > PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU > > > -- > 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
Re: SQA overflow condition
Our ASM is completely fine and we didn't add the page dataset for a long time On Mon, Dec 11, 2023, 4:27 PM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Peter, have you been doing any PAGE ADDS, and PAGE DELETES?Years ago, > when we were migrating to new DASD (TDMF wont move active local page > datasets), I exhausted EQSA but didn’t realize it at the time. Now you do > PAGE DELETE with REPLACE to avoid the ESQA problem. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on behalf > of Peter > Date: Monday, December 11, 2023 at 5:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > These increase we have been whitenessing in last 1 month and never saw > this overflowing in last 2 years. No software changes have been made but > one of the product upgrade was backed out but we kept the products LPA SVC > module in LPALST as the > > > These increase we have been whitenessing in last 1 month and never saw this > > overflowing in last 2 years. > > > > No software changes have been made but one of the product upgrade was > > backed out but we kept the products LPA SVC module in LPALST as the SVC > > module shipped with higher version of the new product(which was backed out) > > was also compatible with lower version of the same product. > > > > So my question can the new SVC module which was shipped with newer version > > of product being utilized by lower version of product can cause spike in > > ESQA ? > > > > > > > > On Mon, Dec 11, 2023, 2:32 PM Martin Packer > > wrote: > > > > > I’m wondering why 108% is a problem. I’d say that’s about the right > amount > > > of overflow. Unless you know have a shortage of free ECSA. > > > > > > Thanks, Martin > > > > > > From: IBM Mainframe Discussion List on behalf > > > of Peter > > > Date: Monday, 11 December 2023 at 04:29 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: [EXTERNAL] Re: SQA overflow condition > > > The ESQA usage has gone to 108%. > > > > > > Is there any tool available in CBTTAPEA which can tell me or trace SQA > > > users and who are not releasing the storage? > > > > > > On Mon, Nov 27, 2023, 5:37 PM Allan Staller < > > > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > Classification: Confidential > > > > > > > > 100% concur w/Martin > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List On > Behalf > > > > Of Martin Packer > > > > Sent: Sunday, November 26, 2023 2:39 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: SQA overflow condition > > > > > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > > > the sender, Don’t click links or open attachments as it may be a > Phishing > > > > email, which can steal your Information and compromise your Computer.] > > > > > > > > (This is not specific advice but a way of thinking about things.) > > > > > > > > SQA can, of course, overflow into CSA - with no real harm done. Unless > it > > > > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > > > > > > > The above statements are true for both 24-bit and 31-bit. > > > > > > > > 1409K below the line, though, is pretty extreme - for 24 bit. If you > made > > > > SQA larger so that it only overflowed, say, by 100K there would be no > > > > wasted virtual storage. > > > > > > > > More importantly, check out the "free CSA" picture. You really don't > want > > > > to run out of that. For 24-bit you want a few hundred K free. (But to > > > > achieve that might require losing 1MB of 24-bit private, which might > not > > > be > > > > consequence free.) > > > > > > > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > > > > reason is because ECSA is - in my experience - more volatile. > > > > > > > > Speaking of volatility, you need to plan defensively - as a problem can > > > > lead to surge in SQA and CSA usage . > > > > > > > > Final point: I would advocate using SMF 78-2 to build a picture of > common > > > > storage usage - and how variable it is. Here is
Re: SQA overflow condition
Peter, have you been doing any PAGE ADDS, and PAGE DELETES?Years ago, when we were migrating to new DASD (TDMF wont move active local page datasets), I exhausted EQSA but didn’t realize it at the time. Now you do PAGE DELETE with REPLACE to avoid the ESQA problem. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Peter Date: Monday, December 11, 2023 at 5:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition These increase we have been whitenessing in last 1 month and never saw this overflowing in last 2 years. No software changes have been made but one of the product upgrade was backed out but we kept the products LPA SVC module in LPALST as the These increase we have been whitenessing in last 1 month and never saw this overflowing in last 2 years. No software changes have been made but one of the product upgrade was backed out but we kept the products LPA SVC module in LPALST as the SVC module shipped with higher version of the new product(which was backed out) was also compatible with lower version of the same product. So my question can the new SVC module which was shipped with newer version of product being utilized by lower version of product can cause spike in ESQA ? On Mon, Dec 11, 2023, 2:32 PM Martin Packer wrote: > I’m wondering why 108% is a problem. I’d say that’s about the right amount > of overflow. Unless you know have a shortage of free ECSA. > > Thanks, Martin > > From: IBM Mainframe Discussion List on behalf > of Peter > Date: Monday, 11 December 2023 at 04:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: SQA overflow condition > The ESQA usage has gone to 108%. > > Is there any tool available in CBTTAPEA which can tell me or trace SQA > users and who are not releasing the storage? > > On Mon, Nov 27, 2023, 5:37 PM Allan Staller < > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > Classification: Confidential > > > > 100% concur w/Martin > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Martin Packer > > Sent: Sunday, November 26, 2023 2:39 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SQA overflow condition > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > the sender, Don’t click links or open attachments as it may be a Phishing > > email, which can steal your Information and compromise your Computer.] > > > > (This is not specific advice but a way of thinking about things.) > > > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > > > The above statements are true for both 24-bit and 31-bit. > > > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > > SQA larger so that it only overflowed, say, by 100K there would be no > > wasted virtual storage. > > > > More importantly, check out the "free CSA" picture. You really don't want > > to run out of that. For 24-bit you want a few hundred K free. (But to > > achieve that might require losing 1MB of 24-bit private, which might not > be > > consequence free.) > > > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > > reason is because ECSA is - in my experience - more volatile. > > > > Speaking of volatility, you need to plan defensively - as a problem can > > lead to surge in SQA and CSA usage . > > > > Final point: I would advocate using SMF 78-2 to build a picture of common > > storage usage - and how variable it is. Here is a blog post I wrote on > the > > matter: > > > > htt ps:// > > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage > > > > (Take out the space to follow the URL - as my mail client turned it into > > an attachment.) > > > > Cheers, Martin > > > > Sent from my iPad > > > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > > > Hello > > > > > > I am able to see the below alert condition under RMF postprocessor III > > > > > > > > > > > > Name Reason Critical val. Possible cause or action > > > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > > > > >
Re: SQA overflow condition
These increase we have been whitenessing in last 1 month and never saw this overflowing in last 2 years. No software changes have been made but one of the product upgrade was backed out but we kept the products LPA SVC module in LPALST as the SVC module shipped with higher version of the new product(which was backed out) was also compatible with lower version of the same product. So my question can the new SVC module which was shipped with newer version of product being utilized by lower version of product can cause spike in ESQA ? On Mon, Dec 11, 2023, 2:32 PM Martin Packer wrote: > I’m wondering why 108% is a problem. I’d say that’s about the right amount > of overflow. Unless you know have a shortage of free ECSA. > > Thanks, Martin > > From: IBM Mainframe Discussion List on behalf > of Peter > Date: Monday, 11 December 2023 at 04:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: SQA overflow condition > The ESQA usage has gone to 108%. > > Is there any tool available in CBTTAPEA which can tell me or trace SQA > users and who are not releasing the storage? > > On Mon, Nov 27, 2023, 5:37 PM Allan Staller < > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > Classification: Confidential > > > > 100% concur w/Martin > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Martin Packer > > Sent: Sunday, November 26, 2023 2:39 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SQA overflow condition > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > the sender, Don’t click links or open attachments as it may be a Phishing > > email, which can steal your Information and compromise your Computer.] > > > > (This is not specific advice but a way of thinking about things.) > > > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > > > The above statements are true for both 24-bit and 31-bit. > > > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > > SQA larger so that it only overflowed, say, by 100K there would be no > > wasted virtual storage. > > > > More importantly, check out the "free CSA" picture. You really don't want > > to run out of that. For 24-bit you want a few hundred K free. (But to > > achieve that might require losing 1MB of 24-bit private, which might not > be > > consequence free.) > > > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > > reason is because ECSA is - in my experience - more volatile. > > > > Speaking of volatility, you need to plan defensively - as a problem can > > lead to surge in SQA and CSA usage . > > > > Final point: I would advocate using SMF 78-2 to build a picture of common > > storage usage - and how variable it is. Here is a blog post I wrote on > the > > matter: > > > > htt ps:// > > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage > > > > (Take out the space to follow the URL - as my mail client turned it into > > an attachment.) > > > > Cheers, Martin > > > > Sent from my iPad > > > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > > > Hello > > > > > > I am able to see the below alert condition under RMF postprocessor III > > > > > > > > > > > > Name Reason Critical val. Possible cause or action > > > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > > > > > CSA=(2000,30) > > > > > > > > > > > > SQA=(16,192) > > > > > > > > > Hardware: z14 > > > LPAR : 16gb memory > > > zOS 2.4 > > > > > > Do I have think about tunning the SQA parameter ? > > > > > > Regards > > > Peter > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Unless otherwise stated above: > > > > IBM United Kingdom Limited > > Registered in England and Wales with number 741598 Registered office: PO > > Box 41, North Harbour, Portsmouth, Hants. PO6 3AU > &
Re: SQA overflow condition
I’m wondering why 108% is a problem. I’d say that’s about the right amount of overflow. Unless you know have a shortage of free ECSA. Thanks, Martin From: IBM Mainframe Discussion List on behalf of Peter Date: Monday, 11 December 2023 at 04:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SQA overflow condition The ESQA usage has gone to 108%. Is there any tool available in CBTTAPEA which can tell me or trace SQA users and who are not releasing the storage? On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > 100% concur w/Martin > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > SQA larger so that it only overflowed, say, by 100K there would be no > wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't want > to run out of that. For 24-bit you want a few hundred K free. (But to > achieve that might require losing 1MB of 24-bit private, which might not be > consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem can > lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of common > storage usage - and how variable it is. Here is a blog post I wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage > > (Take out the space to follow the URL - as my mail client turned it into > an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > CSA=(2000,30) > > > > > > > > SQA=(16,192) > > > > > > Hardware: z14 > > LPAR : 16gb memory > > zOS 2.4 > > > > Do I have think about tunning the SQA parameter ? > > > > Regards > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 Registered office: PO > Box 41, North Harbour, Portsmouth, Hants. PO6 3AU > > > -- > 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 > repres
Re: SQA overflow condition
Peter, SDSF has the “CSR” display (Common Storage Remaining) and on later releases you can even issue the “JCS” action (Job Common Storage) against a row on the CSR panel to drill down to each individual chunk of common storage (and browse it if you so wish). For in-use common storage, see the SDSF “AS” display and you can use the “JCS” action against active jobs as well. SDSF also has the “CS” common that shows common storage summarized by subpool and key, and then the “L” action drills down to each block of storage within that subpool+key to show who owns it. Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Monday, December 11, 2023 4:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition EXTERNAL EMAIL The ESQA usage has gone to 108%. Is there any tool available in CBTTAPEA which can tell me or trace SQA users and who are not releasing the storage? On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu<mailto:0387911dea17-dmarc-requ...@listserv.ua.edu>> wrote: > Classification: Confidential > > 100% concur w/Martin > > -Original Message- > From: IBM Mainframe Discussion List > mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf > Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > SQA larger so that it only overflowed, say, by 100K there would be no > wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't want > to run out of that. For 24-bit you want a few hundred K free. (But to > achieve that might require losing 1MB of 24-bit private, which might not be > consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem can > lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of common > storage usage - and how variable it is. Here is a blog post I wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage<http://mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage> > > (Take out the space to follow the URL - as my mail client turned it into > an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter > > mailto:dbajava...@gmail.com>> wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > CSA=(2000,30) > > > > > > > > SQA=(16,192) > > > > > > Hardware: z14 > > LPAR : 16gb memory > > zOS 2.4 > > > > Do I have think about tunning the SQA parameter ? > > > > Regards > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the > > message: INFO IBM-MAIN > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 Registered office: PO > Box 41, North Harbour, Portsmouth, Hants. PO6 3AU > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the > message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) ar
Re: SQA overflow condition
The ESQA usage has gone to 108%. Is there any tool available in CBTTAPEA which can tell me or trace SQA users and who are not releasing the storage? On Mon, Nov 27, 2023, 5:37 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > 100% concur w/Martin > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > SQA larger so that it only overflowed, say, by 100K there would be no > wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't want > to run out of that. For 24-bit you want a few hundred K free. (But to > achieve that might require losing 1MB of 24-bit private, which might not be > consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem can > lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of common > storage usage - and how variable it is. Here is a blog post I wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage > > (Take out the space to follow the URL - as my mail client turned it into > an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > > > > > CSA=(2000,30) > > > > > > > > SQA=(16,192) > > > > > > Hardware: z14 > > LPAR : 16gb memory > > zOS 2.4 > > > > Do I have think about tunning the SQA parameter ? > > > > Regards > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 Registered office: PO > Box 41, North Harbour, Portsmouth, Hants. PO6 3AU > > > -- > 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: SQA overflow condition
Don't overlook the health checks that can report on CSA/ECSA and SQA/ESQA usage and provide alerts at stages (and severities) that you define, such as CHECK(VSM_CSA_THRESHOLD) and CHECK(VSM_SQA_THRESHOLD). And for understanding who is using what, there is the VERBEXIT VSMDATA OWNCOMM report from IPCS (and SDSF can show this too) Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SQA overflow condition
Classification: Confidential 100% concur w/Martin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Sunday, November 26, 2023 2:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] (This is not specific advice but a way of thinking about things.) SQA can, of course, overflow into CSA - with no real harm done. Unless it causes CSA to go short. (CSA can't overflow into SQA, of course.) The above statements are true for both 24-bit and 31-bit. 1409K below the line, though, is pretty extreme - for 24 bit. If you made SQA larger so that it only overflowed, say, by 100K there would be no wasted virtual storage. More importantly, check out the "free CSA" picture. You really don't want to run out of that. For 24-bit you want a few hundred K free. (But to achieve that might require losing 1MB of 24-bit private, which might not be consequence free.) For 31 bit I like to see at least 100MB free ECSA, preferably more. The reason is because ECSA is - in my experience - more volatile. Speaking of volatility, you need to plan defensively - as a problem can lead to surge in SQA and CSA usage . Final point: I would advocate using SMF 78-2 to build a picture of common storage usage - and how variable it is. Here is a blog post I wrote on the matter: htt ps://mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage (Take out the space to follow the URL - as my mail client turned it into an attachment.) Cheers, Martin Sent from my iPad > On 26 Nov 2023, at 05:40, Peter wrote: > > Hello > > I am able to see the below alert condition under RMF postprocessor III > > > > Name Reason Critical val. Possible cause or action > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > CSA=(2000,30) > > > > SQA=(16,192) > > > Hardware: z14 > LPAR : 16gb memory > zOS 2.4 > > Do I have think about tunning the SQA parameter ? > > Regards > Peter > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- 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: SQA overflow condition
Classification: Confidential Yup!. I could spend about a 1/2 hour typing up the pros/cons of that tuning. Almost a short story in length. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Saturday, November 25, 2023 11:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SQA overflow condition [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hello I am able to see the below alert condition under RMF postprocessor III Name Reason Critical val. Possible cause or action *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. Our SQA and CSA set up in our IEASYSxx is as below CSA=(2000,30) SQA=(16,192) Hardware: z14 LPAR : 16gb memory zOS 2.4 Do I have think about tunning the SQA parameter ? Regards Peter -- 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: SQA overflow condition
This all looks healthy – to me. It’s a single point in time, of course. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Peter Date: Monday, 27 November 2023 at 04:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SQA overflow condition Hello Right now the picture of CSA is good with just 9 percent used but I can see ESQA is in overflowing condition Area Start EndSize(K)%UseOverflow Size(Mb) Extended Private 1B10 7FFF 1653760K 1615Mb Extended CSA 08B8E000 1B0F 300488K 49 293Mb Extended MLPA 0K Extended FLPA 08B8B000 08B8DFFF 12K Extended PLPA 034B6000 08B8AFFF88916K 87Mb Extended SQA 01DBD000 034B5FFF23524K 97 1572K 23Mb Extended R/W Nuc 01D6F000 01DBCFFF 312K Extended R/O Nuc 0100 01D6E4FF13753K 13Mb R/O Nuc 00FDD000 00FF 140K R/W Nuc 00FD4000 00FDCAB7 34K SQA 00E0 00FD3FFF 1872K 29 0K 2Mb PLPA 00C3D000 00DF 1804K 2Mb FLPA 00C3C000 00C3CFFF 4K MLPA 0K CSA 00A0 00C3BFFF 2288K 9 2Mb Private 6000 009F10216K 10Mb V=R 6000 00015FFF 64K System2000 5FFF 16K PSA 1FFF 8K Home Address Space Length Used Free Region Requested 200K Region Above 16M 1653760K 4400K 1649360K Region Below 16M10216K 1364K 8852K DIAGxx Option CSA TrackingActive SQA Tracking Active GFS Trace Inactive On Sun, Nov 26, 2023, 9:35 PM Paul Feller wrote: > Peter, I've also have taken the attitude that SQA or ESQA overflow is not > necessarily a bad thing as long as you are not running short of CSA or > ECSA. As Martin mentioned you don't want to run out of CSA/ECSA. > > There are a few things that I've done over the years. > > There is a set of IRA messages that you could look for in the SYSLOG to > get an idea of the data/time of when the overflow happens. There is also > an IRA message that indicates when the overflow is relieved. > > Another thing I looked at was who was using up the SQA/ESQA. Did > something "new" show up that is allocating SQA/ESQA. As a side note I > would look at what the new thing might also be doing to the CSA/ECSA. > > As Martin mentioned the SMF type 78 record can be helpful. I had some SAS > code I ran that looked at the SMF type 78 records to get a picture of the > ups and downs of SQA/ESQA and CSA/ECSA usage. I'm not very good at coding > SAS but I'm able to make things work. I got the original code off the CBT > website and modified it for my needs. Unfortunately, I don't have access > to the z/OS system anymore because I'm retired so I don't have any > additional details I can give you around the SAS code. > > Paul > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > SQA larger so that it only overflowed, say, by 100K there would be no > wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't want > to run out of that. For 24-bit you want a few hundred K free. (But to > achieve that might require losing 1MB of 24-bit private, which might not be > consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem can > lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of common > storage usage - and how variable it is. Here is a blog post I wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage > > (Take out the space to follow the URL - as my mail client turned it into > an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor III > > > &g
Re: SQA overflow condition
Hello Right now the picture of CSA is good with just 9 percent used but I can see ESQA is in overflowing condition Area Start EndSize(K)%UseOverflow Size(Mb) Extended Private 1B10 7FFF 1653760K 1615Mb Extended CSA 08B8E000 1B0F 300488K 49 293Mb Extended MLPA 0K Extended FLPA 08B8B000 08B8DFFF 12K Extended PLPA 034B6000 08B8AFFF88916K 87Mb Extended SQA 01DBD000 034B5FFF23524K 97 1572K 23Mb Extended R/W Nuc 01D6F000 01DBCFFF 312K Extended R/O Nuc 0100 01D6E4FF13753K 13Mb R/O Nuc 00FDD000 00FF 140K R/W Nuc 00FD4000 00FDCAB7 34K SQA 00E0 00FD3FFF 1872K 29 0K 2Mb PLPA 00C3D000 00DF 1804K 2Mb FLPA 00C3C000 00C3CFFF 4K MLPA 0K CSA 00A0 00C3BFFF 2288K 9 2Mb Private 6000 009F10216K 10Mb V=R 6000 00015FFF 64K System2000 5FFF 16K PSA 1FFF 8K Home Address Space Length Used Free Region Requested 200K Region Above 16M 1653760K 4400K 1649360K Region Below 16M10216K 1364K 8852K DIAGxx Option CSA TrackingActive SQA Tracking Active GFS Trace Inactive On Sun, Nov 26, 2023, 9:35 PM Paul Feller wrote: > Peter, I've also have taken the attitude that SQA or ESQA overflow is not > necessarily a bad thing as long as you are not running short of CSA or > ECSA. As Martin mentioned you don't want to run out of CSA/ECSA. > > There are a few things that I've done over the years. > > There is a set of IRA messages that you could look for in the SYSLOG to > get an idea of the data/time of when the overflow happens. There is also > an IRA message that indicates when the overflow is relieved. > > Another thing I looked at was who was using up the SQA/ESQA. Did > something "new" show up that is allocating SQA/ESQA. As a side note I > would look at what the new thing might also be doing to the CSA/ECSA. > > As Martin mentioned the SMF type 78 record can be helpful. I had some SAS > code I ran that looked at the SMF type 78 records to get a picture of the > ups and downs of SQA/ESQA and CSA/ECSA usage. I'm not very good at coding > SAS but I'm able to make things work. I got the original code off the CBT > website and modified it for my needs. Unfortunately, I don't have access > to the z/OS system anymore because I'm retired so I don't have any > additional details I can give you around the SAS code. > > Paul > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Martin Packer > Sent: Sunday, November 26, 2023 2:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SQA overflow condition > > (This is not specific advice but a way of thinking about things.) > > SQA can, of course, overflow into CSA - with no real harm done. Unless it > causes CSA to go short. (CSA can't overflow into SQA, of course.) > > The above statements are true for both 24-bit and 31-bit. > > 1409K below the line, though, is pretty extreme - for 24 bit. If you made > SQA larger so that it only overflowed, say, by 100K there would be no > wasted virtual storage. > > More importantly, check out the "free CSA" picture. You really don't want > to run out of that. For 24-bit you want a few hundred K free. (But to > achieve that might require losing 1MB of 24-bit private, which might not be > consequence free.) > > For 31 bit I like to see at least 100MB free ECSA, preferably more. The > reason is because ECSA is - in my experience - more volatile. > > Speaking of volatility, you need to plan defensively - as a problem can > lead to surge in SQA and CSA usage . > > Final point: I would advocate using SMF 78-2 to build a picture of common > storage usage - and how variable it is. Here is a blog post I wrote on the > matter: > > htt ps:// > mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage > > (Take out the space to follow the URL - as my mail client turned it into > an attachment.) > > Cheers, Martin > > Sent from my iPad > > > On 26 Nov 2023, at 05:40, Peter wrote: > > > > Hello > > > > I am able to see the below alert condition under RMF postprocessor III > > > > > > > > Name Reason Critical val. Possible cause or action > > > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > >
Re: SQA overflow condition
Peter, I've also have taken the attitude that SQA or ESQA overflow is not necessarily a bad thing as long as you are not running short of CSA or ECSA. As Martin mentioned you don't want to run out of CSA/ECSA. There are a few things that I've done over the years. There is a set of IRA messages that you could look for in the SYSLOG to get an idea of the data/time of when the overflow happens. There is also an IRA message that indicates when the overflow is relieved. Another thing I looked at was who was using up the SQA/ESQA. Did something "new" show up that is allocating SQA/ESQA. As a side note I would look at what the new thing might also be doing to the CSA/ECSA. As Martin mentioned the SMF type 78 record can be helpful. I had some SAS code I ran that looked at the SMF type 78 records to get a picture of the ups and downs of SQA/ESQA and CSA/ECSA usage. I'm not very good at coding SAS but I'm able to make things work. I got the original code off the CBT website and modified it for my needs. Unfortunately, I don't have access to the z/OS system anymore because I'm retired so I don't have any additional details I can give you around the SAS code. Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Sunday, November 26, 2023 2:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SQA overflow condition (This is not specific advice but a way of thinking about things.) SQA can, of course, overflow into CSA - with no real harm done. Unless it causes CSA to go short. (CSA can't overflow into SQA, of course.) The above statements are true for both 24-bit and 31-bit. 1409K below the line, though, is pretty extreme - for 24 bit. If you made SQA larger so that it only overflowed, say, by 100K there would be no wasted virtual storage. More importantly, check out the "free CSA" picture. You really don't want to run out of that. For 24-bit you want a few hundred K free. (But to achieve that might require losing 1MB of 24-bit private, which might not be consequence free.) For 31 bit I like to see at least 100MB free ECSA, preferably more. The reason is because ECSA is - in my experience - more volatile. Speaking of volatility, you need to plan defensively - as a problem can lead to surge in SQA and CSA usage . Final point: I would advocate using SMF 78-2 to build a picture of common storage usage - and how variable it is. Here is a blog post I wrote on the matter: htt ps://mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage (Take out the space to follow the URL - as my mail client turned it into an attachment.) Cheers, Martin Sent from my iPad > On 26 Nov 2023, at 05:40, Peter wrote: > > Hello > > I am able to see the below alert condition under RMF postprocessor III > > > > Name Reason Critical val. Possible cause or action > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > CSA=(2000,30) > > > > SQA=(16,192) > > > Hardware: z14 > LPAR : 16gb memory > zOS 2.4 > > Do I have think about tunning the SQA parameter ? > > Regards > Peter > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- 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: SQA overflow condition
(This is not specific advice but a way of thinking about things.) SQA can, of course, overflow into CSA - with no real harm done. Unless it causes CSA to go short. (CSA can't overflow into SQA, of course.) The above statements are true for both 24-bit and 31-bit. 1409K below the line, though, is pretty extreme - for 24 bit. If you made SQA larger so that it only overflowed, say, by 100K there would be no wasted virtual storage. More importantly, check out the "free CSA" picture. You really don't want to run out of that. For 24-bit you want a few hundred K free. (But to achieve that might require losing 1MB of 24-bit private, which might not be consequence free.) For 31 bit I like to see at least 100MB free ECSA, preferably more. The reason is because ECSA is - in my experience - more volatile. Speaking of volatility, you need to plan defensively - as a problem can lead to surge in SQA and CSA usage . Final point: I would advocate using SMF 78-2 to build a picture of common storage usage - and how variable it is. Here is a blog post I wrote on the matter: htt ps://mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage (Take out the space to follow the URL - as my mail client turned it into an attachment.) Cheers, Martin Sent from my iPad > On 26 Nov 2023, at 05:40, Peter wrote: > > Hello > > I am able to see the below alert condition under RMF postprocessor III > > > > Name Reason Critical val. Possible cause or action > > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. > > > > > > Our SQA and CSA set up in our IEASYSxx is as below > > > > CSA=(2000,30) > > > > SQA=(16,192) > > > Hardware: z14 > LPAR : 16gb memory > zOS 2.4 > > Do I have think about tunning the SQA parameter ? > > Regards > Peter > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SQA overflow condition
Hello I am able to see the below alert condition under RMF postprocessor III Name Reason Critical val. Possible cause or action *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K. Our SQA and CSA set up in our IEASYSxx is as below CSA=(2000,30) SQA=(16,192) Hardware: z14 LPAR : 16gb memory zOS 2.4 Do I have think about tunning the SQA parameter ? Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
