IEA303W ABEND 878 REASON 00000004

[Jesse Lynch]

We got

IEA303W ABEND 878 REASON 00000004 DURING
INITIALIZATION UNDER RIM IEAVNP23
OSC Index 12 connected to CPC4100A via IP
Addr 10.216.182.225:3270 **
LT Index=11 CSSID=00 MIFID=09 CU=0
UA=00 LUName=GMSTR **
Type=2965-N10 Mfg=IBM SN=0000000D2C07
message displayed during start up of GGGG.



at IPL over weekend on 2 of our LPARs.
For one, trying reipl worked fine. For the other we tried several times, no go.
RSU 1711 went into our 2.1 system. We searched on apars and found some old ones mentioning to increase
ESQA. There was some miscommunication and we increased ECSA from 570M to 650M for that one LPAR and it came
up just fine.

On further reading, it looks like if ESQA is exhausted, it might go to the ECSA.

So I have 2 questions

1). Anything we should look for on why this happened to us for the first time at IPL? Our maintenance?
or the fact because of the maintenance we stopped PPRC during the IPLs. Also we did update our ISV vendor software including CAs MIM. I know one of the old APARs mentioned GRS.

2). I am concerned that increasing ECSA might cost us in some way. Will this affect performance
or cause LPAR failure as we go along. I kind of looked at TMON for that LPAR and this is what I see:

CSA: 3068K( 34%) ECSA: 650M( 29%)
SQA: 800K( 56%) ESQA: 47076K( 61%)


We lost our senior Performance Guy to retirement recently which is why I am out here
asking for advice.

Thank you. Jess

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Mark Jacobs - Listserv]

Take a look at increasing INITSQA in LOADxx. It's likely you were close to the limit before, and some environmental change pushed it over the limit. You shouldn't need much of an increase from the default, or if you're specifying it now to het you past this problem.

Mark Jacobs

Jesse Lynch<mailto:jesse...@STATE.MN.US>
February 11, 2018 at 2:04 PM

We got

IEA303W ABEND 878 REASON 00000004 DURING
INITIALIZATION UNDER RIM IEAVNP23
OSC Index 12 connected to CPC4100A via IP

Addr 10.216.182.225:3270<http://10.216.182.225:3270> **

LT Index=11 CSSID=00 MIFID=09 CU=0
UA=00 LUName=GMSTR **
Type=2965-N10 Mfg=IBM SN=0000000D2C07
message displayed during start up of GGGG.



at IPL over weekend on 2 of our LPARs.
For one, trying reipl worked fine. For the other we tried several times, no go.
RSU 1711 went into our 2.1 system. We searched on apars and found some old ones mentioning to increase
ESQA. There was some miscommunication and we increased ECSA from 570M to 650M for that one LPAR and it came
up just fine.

On further reading, it looks like if ESQA is exhausted, it might go to the ECSA.

So I have 2 questions

1). Anything we should look for on why this happened to us for the first time at IPL? Our maintenance?
or the fact because of the maintenance we stopped PPRC during the IPLs. Also we did update our ISV vendor software including CAs MIM. I know one of the old APARs mentioned GRS.

2). I am concerned that increasing ECSA might cost us in some way. Will this affect performance
or cause LPAR failure as we go along. I kind of looked at TMON for that LPAR and this is what I see:

CSA: 3068K( 34%) ECSA: 650M( 29%)
SQA: 800K( 56%) ESQA: 47076K( 61%)


We lost our senior Performance Guy to retirement recently which is why I am out here
asking for advice.

Thank you. Jess

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

send email to list...@listserv.ua.edu<mailto:list...@listserv.ua.edu> with the message: INFO IBM-MAIN


Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phis...@meredith.com<mailto:phis...@meredith.com>'.


--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


This electronic message, including any attachments, may contain proprietary, confidential or privileged information for the sole use of the intended recipient(s). You are hereby notified that any unauthorized disclosure, copying, distribution, or use of this message is prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and delete it.

[Andrew Metcalfe]

I seem to recall a similar problem which caught us out. The cause was the number of inactive EMCS consoles. During NIP processing, it allocates storage to hold all the EMCS consoles defined to the sysplex. This may just tip you over the edge in terms of SQA/CSA and explains why it may not be a solid error condition. There is a healthchecker (CNZ_EMCS_INACTIVE_CONSOLES) which shows how many you have. You can delete inactive ones using the samplib member IEARELEC. We had some defined for TSO userids that had long-since been deleted. We also reduced the threshold for the HC to 1500 from 3000.

Andrew

[Brian Westerman]

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

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.

Brian

[Jesse Lynch]

Thank you very much for all your help