Re: IEA303W ABEND 878 REASON 00000004

[Jesse Lynch]

Thank you very much for all your help

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

Re: IEA303W ABEND 878 REASON 00000004

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

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

Re: IEA303W ABEND 878 REASON 00000004

[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 

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

Re: IEA303W ABEND 878 REASON 00000004

[Allan Staller]

In general, I do not worry about ECSA/ESQA except to be sure the amount is 
sufficient. You have 2 GB avail. What's a couple of hundred MB matter?

Yes, SQA/ESQA will expand into CSA/ECSA respectively. If  E* areas are 
exhausted, the below the line areas will be used.
When all are exhausted, an IPL occurs.

RMF III and or the RMFPP with VSTOR(D) will give you the respective 
utilizations and notify of any overflows,

HTH,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse Lynch
Sent: Sunday, February 11, 2018 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEA303W ABEND 878 REASON 0004

We got

IEA303W ABEND 878 REASON 0004 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=000D2C07
message displayed during start up of .



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

Re: IEA303W ABEND 878 REASON 00000004

[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
February 11, 2018 at 2:04 PM
We got

IEA303W ABEND 878 REASON 0004 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=000D2C07
message displayed during start up of .



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 lists...@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 
'phish...@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.

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