In listserv%201008042316199977.0...@bama.ua.edu, on 08/04/2010
at 11:16 PM, Barbara Nitz nitz-...@gmx.net said:
The recommendation has been for some time to code region only on the
job card.
Whose recommendation? Where?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position;
Lizette Koehler wrote:
I got a question from one of my co workers on why his job abended with an
S822 Reason=0014
The job have over 200 steps running mostly DB2 Tools from CA. There is no
region size on the jobcard. Each step (except the one that got the S822)
has a REGION=0M
Why? As
Lizette Koehler wrote:
I got a question from one of my co workers on why his job abended with an
S822 Reason=0014
The job have over 200 steps running mostly DB2 Tools from CA. There is no
region size on the jobcard. Each step (except the one that got the S822)
has a REGION=0M
The step
Something you could also add in DIAGxx is VSM CHECKREGIONLOSS(256K,100M) with
numbers related to your shop RTM. This will recycle wlm and jes2 inits when the
region available is less than the amount specified. It will not help this job
per say, but would recycle the init afterwards to cleanup
On Wed, 4 Aug 2010 00:30:31 -0500, Barbara Nitz wrote:
I spent quite some time debugging a similar 822 on certain Endeavor-jobs. My
IEFUSI unconditionally overrides any region smaller than 32M to give the full
region below. ...
??? And zero above? Sounds broken to me? Rationale?
What does
Thanks to all who replied.
Yes, at 1am in the morning I was not truly as clear headed as I could have
been, and the size of IEFBR14 is not the issue.
Most likely the problem is going to be storage fragmentation for below the
line. Barbara's answer of using 0M for the region on that step will be
As one of the other posters recommended. USE VSMCHECKREGIONLOSS in
DIAGxx.
I checks for fragmentation and automatically drains/restarts the
initiatior thus, you do not have to review the dump.
HTH,
snip
Most likely the problem is going to be storage fragmentation for below
the
line. Barbara's
My understanding is that anything over 16MiB normally results in whatever
below is available plus unlimited above.
Your understanding is wrong.
Anything over 16M does give you everything below, but it limits above.
If you specify between 16 and 32, you get 32 in total.
Whatever you specify above
Sorry, I left a hanging fragment from the original post.
Re-sent, corrected.
My understanding is that anything over 16MiB normally results in whatever
below is available plus unlimited above.
Your understanding is wrong.
Anything over 16M does give you everything below, but it limits above.
Correction, if coding between 16M and 32M the default is 32M, from JCL
Reference:
If your installation does not change the IBM-supplied default limits in the
IEALIMIT
or IEFUSI exit routine modules, then specifying various values for the
region size
has the following results:
- A value equal to
Are we missing something here? Didn't R.11 allow IEFBR14 to issue HDELETEs
as appropriate? And mightn't that take up some 24-Bit virtual?
(In addition to everything others are saying about fragmentation.)
Cheers, Martin
Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Wednesday, August 04, 2010 12:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question on size of IEFBR14 and z/OS V1.11
Barbara,
Thanks. This may be a similar issue. I
No! See John Eells' post below. The HDELETE functionalty was added to
allocation and is triggered by the recognition of IEFBR14.
So, IEFBR14 has not increased in size but the addittional functionality within
allocation may well be the culprit.
Date: Wed, 4 Aug 2010 15:58:04 +0100
Correction, if coding between 16M and 32M the default is 32M.
That's what I said:
16M above, is 32M in total.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
--
For IBM-MAIN subscribe / signoff / archive access
Didn't R.11 allow IEFBR14 to issue HDELETEs as appropriate?
No, that's not quite accurate.
IEFBR14 hasn't changed.
The HDELETEs are done by some mechanism within the system/initiator.
Not to hijack this thread, but (as I've said before) that's a kludge!
-
I'm a SuperHero with neither powers,
On Wed, Aug 4, 2010 at 12:27 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:
Correction, if coding between 16M and 32M the default is 32M.
That's what I said:
16M above, is 32M in total.
Again from JCL Reference (32M above plus whatever is available below):
- A value greater than 16,384K or 16M
The extended region size is the default value of 32 megabytes.
I've obviously misinterpreted that statement then.
I always read it as total.
But, the major point is that 16M does not give you all above.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
I was rerunning an z/OS 1.9 ADDRSU backup of a Mod 9 volume, 600 track
VTOC, 90% used with mostly 1 track datasets, 90% of VTOC entries used.
I had to specify a REGION=256MB because REGION=196MB abended, ended up
using about 205MB. when it finally completed.
I would continue with the 17MB or
Gil,
My IEFUSI unconditionally overrides any region smaller than 32M to give the
full region below. ...
??? And zero above? Sounds broken to me? Rationale?
What does full region below mean?
o Whatever is available there?
o Exactly 8MiB (or at least that)?
o Other (specify)?
I did not talk about
I got a question from one of my co workers on why his job abended with an
S822 Reason=0014
The job have over 200 steps running mostly DB2 Tools from CA. There is no
region size on the jobcard. Each step (except the one that got the S822)
has a REGION=0M
Our default region size is problem
Barbara,
Thanks. This may be a similar issue. I am going to have them use 0M then I
will not need to read a dump. Yeah!!
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Barbara Nitz
Sent: Wednesday, August 04, 2010 1:31
21 matches
Mail list logo
