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 <prjfeller1...@gmail.com> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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=<SysCons name> 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 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-stor > > > ag > > > > > > > > > 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 > > > > > > -------------------------------------------------------------------- > > > -- 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
