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-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 <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
