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 <[email protected]> On Behalf Of Martin Packer Sent: Sunday, November 26, 2023 2:39 AM To: [email protected] 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 <[email protected]> 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
