There is an old error in GRS, which has still not been resolved (even at z/OS 
2.3) that causes this problem, when you receive it, it's all timing related, 
and the slower the LPAR (i.e. the more you cap it) the more likely you are to 
receive it.  If you take a SA dump, it's easy to see that there is a huge 
getmain that GRS does that uses up the space.  Strangely enough, the problem is 
with the above the line ESQA, not the below the line SQA.  

z/OS doesn't allocate a lot of SQA and ESQA at IPL time, and you have not yet 
gotten to the point in your IPL where your SQA and EQSA parms kick in.

Luckily, the fix is simple.

Insert the following into your LOADxx member for that (and probably all of your 

INITSQA  0000K 0008M 

This will add just 8 meg to the ESQA that is allocated at IPL.  You can 
actually get by with just an extra 8K, but it's ESQA, so extra won't kill you.

This amount is added to the default amount at IPL, (which you cannot otherwise 
affect), and is added to your total SQA and ESQA for the life of the IPL.  

You can add SQA as well if you want, but it does affect the total below the 
line, so be sure to deduct it from your SQA parmlib amount later if you do use 
the first parm above (I have it set to zero).

Any way, there are some PTF's that change the order of things occurring that 
have caused this VERY old problem to resurface.  They have not been resolved as 
of RSU 1801 for z/OS 2.3 or z/OS 2.2, so plan on keeping the INITSQA parm for 
quite a while yet.

If you want more information, please feel free to call me or send me a note and 
I'll talk this over with you.  I spent 3 days going through stand alone dumps 
to find the problem a couple months ago.  We thought we had a hardware issue, 
because we had not changed the service level at all, just the hardware patches 
were changed.  

In the end, it's just the single getmain from GRS.


For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to