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 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 < 00000387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > 100% concur w/Martin > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> 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 <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,300000) > > > > > > > > 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 ---------------------------------------------------------------------- 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 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
