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
equ...@listserv.ua.edu>
Sent: Wednesday, January 9, 2019 4:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
On Wed, 9 Jan 2019 20:02:33 +, Seymour J Metz wrote:
>There are two region restrictions, and you can only control one in JCL.
That was true until
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jesse 1 Robinson
Sent: Wednesday, January 9, 2019 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
I don't expect below-the-line CSA to be much affected by a hardware c
the
> problem is found.
>
> Mark
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Wayne Bickerdike
> Sent: Wednesday, January 09, 2019 3:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Generic query on Region allocation failure
Sent: Wednesday, January 09, 2019 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
*to IBM-MAIN*
*On Wed, 9 Jan 2019 13:47:48 +, Allan Staller wrote:>This looks more like
the linklst dataset has taken an extent for some reason.Not to me.
On Thu, 10 Jan 2019 08:36:11 +1100, Wayne Bickerdike wrote:
>Do IBM test between releases?
Yes, they do.
Is their testing perfect? No.
Is the problem that you are having a bug or some error in your configuration? I
could be wrong, but I'd bet it is the latter.
Have you analyzed the dump?
--
To
vice versa."
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Wednesday, January 09, 2019 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Generic query on Region alloca
On Wed, 9 Jan 2019 20:02:33 +, Seymour J Metz wrote:
>There are two region restrictions, and you can only control one in JCL.
That was true until z/OS 2.2.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab600/xexregjob.htm
https://www.ibm.com/support/knowledgecen
DU
Subject: (External):Re: Generic query on Region allocation failure
I don't expect below-the-line CSA to be much affected by a hardware change (not
in 2018 for sure) but in the case of a true push/pull swap out, you are likely
using a whole new IODF--which is software. That was certai
Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Peter Hunkeler
Sent: Tuesday, January 08, 2019 11:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: Generic query on Region allocation failure
>So when we move to a higher
://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Peter
Sent: Tuesday, January 8, 2019 10:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
Apologies for being ignorant
So when we move to a higher
8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
We went through a similar round of problems with private areas below the line.
You have to remember that the REGION parameter or whatever is SMFLIMxx is a
limit, not an allocation. In other words, specify
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
On Wed, 9 Jan 2019 13:47:48 +, Allan Staller wrote:
>This looks more like the linklst dataset has taken an extent for some reason.
Not to me. I would expect S106 reason code 0F, not reason code 0C.
>
>Try compressing the dataset containing CEEBINIT, followed by F LLA,REFRESH
I don't recommen
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
IF that does not work an IPL will be necessary.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Wayne Bickerdike
> Sent: Tuesday, January 8, 2019 10:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Generic query on Region al
IF that does not work an IPL will be necessary.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Wayne Bickerdike
> Sent: Tuesday, January 8, 2019 10:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Generic query on Region al
Bickerdike
Sent: Tuesday, January 8, 2019 10:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
IEW4000I FETCH FOR MODULE CEEBINIT FROM DDNAME *VLF*FAILED BECAUSE
INSUFFICI
CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEBINIT, RETURN CODE 24, REASON CODE
2
bject: EXTERNAL: Re: Generic query on Region allocation failure
Usually such ABEND codes have a reason in R15 and a message in the job log.
Please include those when you ask for help.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainf
Thank you so much all for a great response
On Wed 9 Jan, 2019, 11:06 AM Peter Hunkeler
>
>
> >I would like to make a suggestion. REGION=xxx and other settings
> should remain the same. If you specify REGION=(#K,#M,#G), where you
> are requesting 24, 31, and 64 bit memory amounts subject to othe
>I would like to make a suggestion. REGION=xxx and other settings
should remain the same. If you specify REGION=(#K,#M,#G), where you
are requesting 24, 31, and 64 bit memory amounts subject to other
suffixes and normal override measures.
I don‘t get your point.
There is no „#G“ spec
>So when we move to a higher version of hardware the storage area below the
line shrinks ?
Not necessarily. It may or may not, and the cautious system programmer may or
may not be able to avoid it. There are certain boundaries in the address space
map that must lie on a megabyte boundary. The
7 705 971) | m: +61 400029610 | h:
> > +61 387399252 | email: ron.hawk...@ipsicsopt.com
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List On
> > Behalf Of Jesse 1 Robinson
> > > Sent: Wednesday, 9 January 2019 06:13
>
ally costs nothing and may save some debugging
>> > grief down the road. I've seen cases where 0M may be required for a
>> > particular product. Again, the cost of doing so is minimal. Why quibble?
>> > Someone needs to refresh the communal coffee pot.
>> > >
t; > Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h:
> > +61 387399252 | email: ron.hawk...@ipsicsopt.com
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List On
> > Behalf Of Jesse 1 Robinson
> > > Sent:
| h:
> +61 387399252 | email: ron.hawk...@ipsicsopt.com
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List On
> Behalf Of Jesse 1 Robinson
> > Sent: Wednesday, 9 January 2019 06:13
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re:
csopt Pty Ltd (ACN: 627 705 971) | m: +61 400029610 | h: +61
> 387399252 | email: ron.hawk...@ipsicsopt.com
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Jesse 1 Robinson
> Sent: Wednesday, 9 January 2019 06:13
> To: IBM-MAIN@LISTSERV.UA
: ron.hawk...@ipsicsopt.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jesse 1 Robinson
Sent: Wednesday, 9 January 2019 06:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Generic query on Region allocation failure
This post is not intended to be enlighte
: Tuesday, January 8, 2019 2:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure
We keep seeing S106 abends trying to run DFHEISUP utility.
It's been discussed a few times on various fora but no definitive
solution yet.
At CICS 5.2 it ran fine.5.3 it'
: Generic query on Region allocation failure
We keep seeing S106 abends trying to run DFHEISUP utility.
It's been discussed a few times on various fora but no definitive solution yet.
At CICS 5.2 it ran fine.5.3 it's hit and miss and 5.4 just plain doesn't work.
All permutations
updated for 10+ years and
> still have very small regions sizes.
>
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Jesse 1 Robinson"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, January 8, 2019 1:13:14 PM
> Subject: Re:
till have very small regions sizes.
>
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Jesse 1 Robinson"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, January 8, 2019 1:13:14 PM
> Subject: Re: Generic query on Region allocation failure
>
>
n Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Marchant
> Sent: Tu
ISTSERV.UA.EDU
Sent: Tuesday, January 8, 2019 1:13:14 PM
Subject: Re: Generic query on Region allocation failure
This post is not intended to be enlightening; it's merely corroborative. We
recently went from z12EC to z14. We had already upgraded to z/OS 2.3 with
hardware support service. In
] On Behalf
Of Tom Marchant
Sent: Tuesday, January 08, 2019 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Generic query on Region allocation failure
On Tue, 8 Jan 2019 10:16:00 +0400, Jake Anderson wrote:
>IEF085I REGION NOT AVAILABLE ERROR CODE = 20 IEF187I NJJJ FAILED -
>
On Tue, 8 Jan 2019 10:16:00 +0400, Jake Anderson wrote:
>IEF085I REGION NOT AVAILABLE ERROR CODE = 20
>IEF187I NJJJ FAILED - SYSTEM ERROR IN INITIATOR
>IEF472I NJJJ
That means that the region that was specified is not available.
Most likely, the region specified is less than 16M and that
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic query on Region allocation failure [EXTERNAL]
Apology for being vague
IEF085I REGION NOT AVAILABLE ERROR CODE = 20 IEF187I NJJJ FAILED - SYSTEM
ERROR IN INITIATOR IEF472I NJJJ
On Tue 8 Jan, 2019, 8:20 AM Lizette Koehler As always, it is
>A possible reason can be the fragmentation that normally occurs.
>It is possble to prevent it by coding VSM CHECKREGIONLOSS(xxxK,xM) on your
>>DIAGxx member of PARMLST.
Such fragmentation can only occur in batch initiators, or z/OS UNIX initiators,
aka BPXAS), which are address spaces t
-
> > From: IBM Mainframe Discussion List On
> Behalf Of
> > Jake Anderson
> > Sent: Monday, January 07, 2019 9:11 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Generic query on Region allocation failure
> >
> > Hi
> >
> > After we have moved f
>IEF085I REGION NOT AVAILABLE ERROR CODE = 20
>IEF187I NJJJ FAILED - SYSTEM ERROR IN INITIATOR
>IEF472I NJJJ
IEF085I lists four reasons for reason 20. You probably haven‘t specified V=R
(ADDRSPC=REAL), so two of them do not apply. You mentioned „started task“, so
there will be
Discussion List On
> Behalf Of
> > Jake Anderson
> > Sent: Monday, January 07, 2019 9:11 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Generic query on Region allocation failure
> >
> > Hi
> >
> > After we have moved from z114 to z14. Some of ou
nt: Monday, January 07, 2019 9:11 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Generic query on Region allocation failure
> >
> > Hi
> >
> > After we have moved from z114 to z14. Some of our database(ISVs database
> > product) started task failed with reg
Sent: Monday, January 07, 2019 9:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Generic query on Region allocation failure
>
> Hi
>
> After we have moved from z114 to z14. Some of our database(ISVs database
> product) started task failed with region allocation.( When I kept 5m),
Hi
After we have moved from z114 to z14. Some of our database(ISVs database
product) started task failed with region allocation.( When I kept 5m), but
after increasing the region size it came up .
Not sure if z14 requires some task to move above the line ?
Could someone please shed some light on
74 matches
Mail list logo
