frame Discussion List On Behalf Of
Clark Morris
Sent: Thursday, 17 January 2019 4:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Abend 106 (was Generic query on Region allocation failure)
[Default] On 16 Jan 2019 02:57:29 -0800, in bit.listserv.ibm-main
01a0403c5dc1-dmarc-requ...@listserv.u
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: Friday, January 18, 2019 11:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Abend 106 (was Generic query on Region allocation
&g
Generic query on Region allocation
failure)
On 1/18/2019 11:02 AM, Jesse 1 Robinson wrote:
> Even Peter Relson did not comment on this, but I gotta say it: 2 GB LPAR is
> too small.
But, just to be clear, increasing the central storage available to this LPAR
will *NOT* solve this issue.
On 1/18/2019 11:02 AM, Jesse 1 Robinson wrote:
Even Peter Relson did not comment on this, but I gotta say it: 2 GB LPAR is too
small.
But, just to be clear, increasing the central storage available to this
LPAR will *NOT* solve this issue. The 24-bit private area will continue
to be 8M.
ist [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Wednesday, January 16, 2019 5:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Abend 106 (was Generic query on Region allocation
failure)
On Wed, 16 Jan 2019 13:57:48 +1100, Wayne Bickerdike wrote:
>Mark Zeldens excellent I
On 1/18/2019 7:53 AM, Tom Marchant wrote:
On Fri, 18 Jan 2019 07:46:05 -0500, Peter Relson wrote:
Wayne, Please let us know how the PMR path plays out.
Yes, please do.
FWIW it looks like a C program to me. Every CSECT shows either 'AMODE:
MIN' or 'AMODE: UNS' in AMBLIST.
More likely than
On Fri, 18 Jan 2019 07:46:05 -0500, Peter Relson wrote:
>Wayne, Please let us know how the PMR path plays out.
Yes, please do.
>If there are parts of the loadmod that need to be below 16M, perhaps going
>forward they'd even consider making it an RMODE=SPLIT program object so
>that only the par
Wayne, Please let us know how the PMR path plays out.
If there are parts of the loadmod that need to be below 16M, perhaps going
forward they'd even consider making it an RMODE=SPLIT program object so
that only the parts that truly need to be below 16M are, or if not that
then the more brute fo
Thankyou Peter and Tom for your recent comments.
I'll open a PMR with the CICS group.
Wayne Bickerdike
On Fri, Jan 18, 2019 at 12:29 AM Peter Relson wrote:
> So we conclude that Wayne's private area below 16M is too small for
> running this utility.
>
> Regardless of that, since an 8M private
So we conclude that Wayne's private area below 16M is too small for
running this utility.
Regardless of that, since an 8M private area is not bizarre (1M would be
bizarre), I would expect the documentation for the CICS utility program to
include the minimum private area size below 16M required
Do you mean private is too small?
Not sure. I was responding to Peter Relson.
A question for Wayne: can you find out the size of low private on your
system (there are probably "pretty" ways to do this, such as some VSM
health check, but if you can get the value of GDACSA that will let the
answ
East Paris, Grand Rapids, MI 49546 MD RSCB2H
>p 616.653.8429
>f 616.653.2717
>
>-Original Message-----
>From: IBM Mainframe Discussion List On Behalf Of
>Wayne Bickerdike
>Sent: Tuesday, January 15, 2019 9:58 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Abend 106
On Wed, 16 Jan 2019 13:57:48 +1100, Wayne Bickerdike wrote:
>Mark Zeldens excellent IPLINFO shows:
>
>The real storage size at IPL time was 2048M.
>The private area size <16M is 8192K.
It seems to be a sloppy calculation. The private area always ends on a 1M
boundary, but every system I've looke
, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Wayne Bickerdike
Sent: Tuesday, January 15, 2019 9:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Abend 106 (was Generic query on Region allocation failure
Mark Zeldens excellent IPLINFO shows:
The real storage size at IPL time was 2048M.
The private area size <16M is 8192K.
The private area size >16M is 1628M.
The CSA size <16M is 4812K.
The CSA size >16M is 300652K.
The SQA size <16M is 1248K.
The SQA size >16M is 15792K.
The maximum V=R region siz
On Tue, 15 Jan 2019 08:57:39 -0500, Peter Relson wrote:
>
>there is no excuse for such a large module requiring RMODE(24).
>
>
>Sure there is -- if it doesn't cause a problem. But here it does cause a
>problem.
>So the real question is? what's the problem?
DFHEISUP has been getting larger with
Thanks Tom,
I'm down the rabbit hole now:
BLS18224I Dump of z/OS 02.02.00-0 - level same as IPCS level
78 +++ DEC_ASID = X2D(SUBSTR(BLSOAS,(POS('ASID',BLSOAS)+7),4))
IRX0040I Error running IGVVSMIN, line 78: Incorrect call to routine
***
On Wed, Jan 16, 2019 at 8:28 AM Tom Marchant <
000
On Tue, 15 Jan 2019 08:57:39 -0500, Peter Relson wrote:
>A question for Wayne: can you find out the size of low private on your
>system (there are probably "pretty" ways to do this, such as some VSM
>health check, but if you can get the value of GDACSA that will let the
>answer be ascertained).
there is no excuse for such a large module requiring RMODE(24).
Sure there is -- if it doesn't cause a problem. But here it does cause a
problem.
So the real question is? what's the problem?
It's not the simple problem -- I could easily imagine a customer not
having a 7M private region below
Full reason code:
CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEBINIT, RETURN CODE 24, REASON
CODE 26080021, DDNAME STEPLIB
DSNAME Seq VolSer BlkSize Extent SMS APF
LRecL DSOrg Rec
CEE.SCEERUN 29 VTMVSC 32760 1 NO YES 0
POU
CE
Thanks guys,
very helpful.
Peter, I have tested with LLA stopped,thought I posted that test.Still
received S106-C.
Since the problem started with CICS 5.3, I think a PMR with CICS is the
next step.
I'll run more tests today (I'm at a different client today).
Wayne
On Tue, Jan 15, 2019 at 3:0
On Mon, 14 Jan 2019 08:30:20 -0600, Tom Marchant wrote:
>On Sat, 12 Jan 2019 14:59:05 +1100, Wayne Bickerdike wrote:
>
>>Step end stats:
>>
>>IEF032I STEP/STEP020 /STOP 2019011.2148
>>
>>CPU: 0 HR 00 MIN 00.05 SECSRB: 0 HR 00 MIN 00.01
>>SEC
>>VIRT: 7908K SYS:
I'd still like Wayne to post the untruncated CSV031I message...
(or re-post it if he had done so but I missed amidst the many appends).
Check out the reason code of the S106-xx message. It could be that the
module it's trying to load is in LLA, but LLA REFRESH was not done after
replacing the
On Sat, 12 Jan 2019 14:59:05 +1100, Wayne Bickerdike wrote:
>Step end stats:
>
>IEF032I STEP/STEP020 /STOP 2019011.2148
>
>CPU: 0 HR 00 MIN 00.05 SECSRB: 0 HR 00 MIN 00.01
>SEC
>VIRT: 7908K SYS: 260K EXT:4K SYS:10876K
>
>ATB- REAL:
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Wayne Bickerdike
Sent: Friday, January 11, 2019 9:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Abend 106 (was Generic query on Region allocation failure)
[EXTERNAL]
Step end stats:
IEF032I STEP/STEP020 /STOP 2019011.2148
CPU: 0 HR 00 MIN
Roger,
The error occurs consistently on three different machines at three clients.
Unlikely to be LLA.
FYI. One abend had failure to load from *VLF*. I stopped LLA and received
the same S106.
Also all libraries are in STEPLIB.
Wayne
On Sat, Jan 12, 2019 at 4:53 PM Mike Schwab wrote:
> http
http://www.jaymoseley.com/hercules/sabends.htm
S106 - 0C - NOT ENOUGH STORAGE WAS AVAILABLE FOR FETCH TO DO A GETMAIN
FOR THE MODULE OR CONTROL BLOCKS. CHECK REGISTER 0:
04 - NO STORAGE FOR DATD.
08 - NO STORAGE FOR DEB.
0C - NO STORAGE FOR IOSB.
droid
From: IBM Mainframe Discussion List on behalf of
Wayne Bickerdike
Sent: Friday, January 11, 2019 10:59:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Abend 106 (was Generic query on Region allocation failure)
Step end stats:
IEF032I STEP/STEP020 /STOP 2019011.2148
CPU: 0 HR 0
Step end stats:
IEF032I STEP/STEP020 /STOP 2019011.2148
CPU: 0 HR 00 MIN 00.05 SECSRB: 0 HR 00 MIN 00.01
SEC
VIRT: 7908K SYS: 260K EXT:4K SYS:10876K
ATB- REAL: 3104K SLOTS: 0K
VIRT- ALL
REGION=0M and same abend with REGION=512M.
Took an SVC dump, here's some FA information.
JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11
21:21:48
IBM Fault Analyzer Abend Job Information:
Abend Date. . . . . . . . : 2019/01/11
Abend Time. . . . . . . . : 21:21:48
Sy
Fetch usually fails with INSUFFICIENT MEMORY. Increase region size.
If you don't have one, look at the memory stats at the end of step
messages to see what was used and double. Otherwise suggest REGION=4M,
5M, 6M, 7M, 20M, 32M, 64M, etc.
On Wed, Jan 9, 2019 at 12:26 PM Peter Relson wrote:
>
> I
Subject: Abend 106 (was Generic query on Region allocation failure)
I don't think the abend 106 that is discussed is part of the original
discussion, so I guessed that it could do with a different thread name.
The abend 106 itself is not helpful in finding out what is going on
because that
I don't think the abend 106 that is discussed is part of the original
discussion, so I guessed that it could do with a different thread name.
The abend 106 itself is not helpful in finding out what is going on
because that is just the generic result of a preceding problem which
likely had mess
33 matches
Mail list logo
