Re: Abend 106 (was Generic query on Region allocation failure)
SCLM is ancient and only slightly revered. No revenue attached to fixing it up. Superc - well I happen to know it's a weird beast and untangling the 24-bit issues is likely too much trouble for the developers. See my SCLM answer Cheers Hank -Original Message- From: IBM Mainframe 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.ua.edu (Jousma, David) wrote: >Wayne, you need to free up region below the line. We run with an 11M PVT below >the line.Here is our memory map from tasid. > >0 | PSA .. 8K | 1FFF > 2000 | System .. 16K | 5FFF > 6000 | PVT .. 11240K | AF > B0 | CSA ... 2276K | D38FFF > D39000 | PLPA .. 1380K | E91FFF > E92000 | SQA ... 1284K | FD2FFF > FD3000 | R/W Nucleus . 43K | FDD877 > FDE000 | R/O Nucleus .. 13483K | 1D08B2F > 1D09000 | Ext R/W Nuc 320K | 1D58FFF > 1D59000 | Ext SQA .. 90304K | 7588FFF > 7589000 | Ext PLPA . 65844K | B5D5FFF > B5D6000 | Ext CSA . 389288K | 231F > 2320 | Ext PVT 1521664K | 7FFF > >One way we make a bunch of room below the line is to move little used ISPF >modules out of LPA in LINKLIST. > Why the &*^^%* in 2019 should anyone have to move these modules out of LPA? Other than inertia, is there any need for these to be 24 bit? What else is in 24 bit LPA that should have been upgraded to 31 bit long ago? Clark Morris > >++VER(Z038) FMID(HIF7R02). >++MOVE (FLM$CPI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMCPCS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMDDL ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPCBL) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPFRT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPGEN) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLSS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMPTC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRA ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRTLIB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$LNK) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$SRV) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS7C ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTBMAP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCCPS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCIDS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCLGT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPP ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCVER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMMI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMSI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTXFER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMUM ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMVCSUP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXE ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (ISRSUPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. > >_ >Dave Jousma >Mainframe Engineering, Assistant Vice President david.jou...@53.com >1830 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 (was Generic query on Region allocation failure) > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or >unexpected emails** > >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 size is 280K. >The default V=R region size is 140K. >The maximum V=V region size is 8168K. > >Based on this: >CVTGDA = C2d(Storage(D2x(
Re: Abend 106 (was Generic query on Region allocation failure)
This is the 2GB LPAR on the IBM Remote Development program. I'm guessing that's how it's rolled out to folks like us. I have had some success on another customer site, but I can't really post about it here because it's . And the third customer site gets the same S106 abend. This same problem has been kicking around since 2009, I found an old reference today relating to CICS 3.2. On Sat, Jan 19, 2019 at 7:42 AM Jesse 1 Robinson wrote: > Understood. I just remember Elpida and company saying that a lot of > general problems stemmed from a too-small LPAR size. General observation, > not an explanation for the current case. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon 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 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 > 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. The 24-bit private area will continue to > be 8M. > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
Understood. I just remember Elpida and company saying that a lot of general problems stemmed from a too-small LPAR size. General observation, not an explanation for the current case. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon 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 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 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. The 24-bit private area will continue to be 8M. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was 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. The 24-bit private area will continue to be 8M. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
Even Peter Relson did not comment on this, but I gotta say it: 2 GB LPAR is too small. IBM has argued for years that many customer problems of all ilk can track back to insufficient real memory allocation. This was a common theme in SHARE presentations for quite a while. Finally the requirement for larger memory was codified in z/OS 2.3 running on z14: you will get a warning at IPL if an LPAR has less than 8 GB. Just sayin. We never saw the warning because we made sure to allocate >= 8 GB in that environment. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_zNext_Memory_Reqs_V2R3.htm . . J.O.Skip Robinson Southern California Edison Company Electric Dragon 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: 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 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 looked for the last several years had a private area that starts at X'6000'. Thus your actual private area size below 16M is X'7FA000' or 8168K. >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 size is 280K. >The default V=R region size is 140K. >The maximum V=V region size is 8168K. > >Based on this: >CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ >GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ >GDACSAH = D2x(GDACSA) /* display in hex */ >CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ >CSAEND = D2x(CSAEND) /* display in hex */ > >So CSA <16M is too small. Do you mean private is too small? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 not, all they need to do is change some attributes and recompile/re-link to fix this mess. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 parts that truly need to be below 16M are, or if not that >then the more brute force approach of splitting the loadmod into multiple >loadmods based at least in part on RMODE. (I'm assuming that most of this >utility is AMODE 31.) The current load module is linked AMODE(31) RMODE(24). -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 force approach of splitting the loadmod into multiple loadmods based at least in part on RMODE. (I'm assuming that most of this utility is AMODE 31.) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 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 in order to run > it. > > I suggest that you ask (strongly) that that information be provided. It is > an environmental requirement for the utility. And look at all the time and > resource (both customer and IBM) that has already been wasted because of > the lack of that information. > > Maybe they'll find that someone accidentally, years ago, introduced an > RMODE 24 CSECT into the loadmod without needing it to be so and that > dragged the whole loadmod below 16M when it didn't need to and that the > module really should be above 16M. We had that happen for an LPA module, > but it didn't take too long before someone noticed it. > > Tom M mentioned x'7FA000'. If you count the x'2000' PSA (I don't know if > you should or should not), 8M is correct. That doesn't mean that all 8M is > available to a program (think TCBs and RBs). The area x'2000'-x'5FFF' is > the system region, but it is private. So having a private area of 8M > doesn't mean that you could do a GETMAIN for 8M. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 in order to run it. I suggest that you ask (strongly) that that information be provided. It is an environmental requirement for the utility. And look at all the time and resource (both customer and IBM) that has already been wasted because of the lack of that information. Maybe they'll find that someone accidentally, years ago, introduced an RMODE 24 CSECT into the loadmod without needing it to be so and that dragged the whole loadmod below 16M when it didn't need to and that the module really should be above 16M. We had that happen for an LPA module, but it didn't take too long before someone noticed it. Tom M mentioned x'7FA000'. If you count the x'2000' PSA (I don't know if you should or should not), 8M is correct. That doesn't mean that all 8M is available to a program (think TCBs and RBs). The area x'2000'-x'5FFF' is the system region, but it is private. So having a private area of 8M doesn't mean that you could do a GETMAIN for 8M. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 answer be ascertained). CVTGDA (offset x'230' in the CVT) has the address of the GDA. GDACSA is the 4 bytes at offset x'6C' CSA 0080 00CB2FFF 4812K(GDACSA ?) Private V=V 6000 007F 8168K Wayne On Thu, Jan 17, 2019 at 12:52 AM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > 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 looked for the last several years had a > private area that starts at X'6000'. Thus your actual private area size > below 16M is X'7FA000' or 8168K. > > >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 size is 280K. > >The default V=R region size is 140K. > >The maximum V=V region size is 8168K. > > > >Based on this: > >CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ > >GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ > >GDACSAH = D2x(GDACSA) /* display in hex */ > >CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ > >CSAEND = D2x(CSAEND) /* display in hex */ > > > >So CSA <16M is too small. > > Do you mean private is too small? > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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.ua.edu (Jousma, David) wrote: >Wayne, you need to free up region below the line. We run with an 11M PVT below >the line.Here is our memory map from tasid. > >0 | PSA .. 8K | 1FFF > 2000 | System .. 16K | 5FFF > 6000 | PVT .. 11240K | AF > B0 | CSA ... 2276K | D38FFF > D39000 | PLPA .. 1380K | E91FFF > E92000 | SQA ... 1284K | FD2FFF > FD3000 | R/W Nucleus . 43K | FDD877 > FDE000 | R/O Nucleus .. 13483K | 1D08B2F > 1D09000 | Ext R/W Nuc 320K | 1D58FFF > 1D59000 | Ext SQA .. 90304K | 7588FFF > 7589000 | Ext PLPA . 65844K | B5D5FFF > B5D6000 | Ext CSA . 389288K | 231F > 2320 | Ext PVT 1521664K | 7FFF > >One way we make a bunch of room below the line is to move little used ISPF >modules out of LPA in LINKLIST. > Why the &*^^%* in 2019 should anyone have to move these modules out of LPA? Other than inertia, is there any need for these to be 24 bit? What else is in 24 bit LPA that should have been upgraded to 31 bit long ago? Clark Morris > >++VER(Z038) FMID(HIF7R02). >++MOVE (FLM$CPI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMCPCS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMDDL ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPCBL) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPFRT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPGEN) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLSS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMPTC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRA ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRTLIB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$LNK) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$SRV) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS7C ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTBMAP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCCPS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCIDS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCLGT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPP ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCVER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMMI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMSI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTXFER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMUM ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMVCSUP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXE ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (ISRSUPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. > >_ >Dave Jousma >Mainframe Engineering, Assistant Vice President >david.jou...@53.com >1830 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 (was Generic query on Region allocation failure) > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >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 size is 280K. >The default V=R region size is 140K. >The maximum V=V region size is 8168K. > >Based on this: >CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ >GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ >GDACSAH = D2x(GDACSA) /* display in hex */ >CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ >CSAEND = D2x(CSAEND) /* display in hex */ > >So CSA <16M is too small. > > >
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 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 looked for the last several years had a private area that starts at X'6000'. Thus your actual private area size below 16M is X'7FA000' or 8168K. >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 size is 280K. >The default V=R region size is 140K. >The maximum V=V region size is 8168K. > >Based on this: >CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ >GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ >GDACSAH = D2x(GDACSA) /* display in hex */ >CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ >CSAEND = D2x(CSAEND) /* display in hex */ > >So CSA <16M is too small. Do you mean private is too small? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
Wayne, you need to free up region below the line. We run with an 11M PVT below the line.Here is our memory map from tasid. 0 | PSA .. 8K | 1FFF 2000 | System .. 16K | 5FFF 6000 | PVT .. 11240K | AF B0 | CSA ... 2276K | D38FFF D39000 | PLPA .. 1380K | E91FFF E92000 | SQA ... 1284K | FD2FFF FD3000 | R/W Nucleus . 43K | FDD877 FDE000 | R/O Nucleus .. 13483K | 1D08B2F 1D09000 | Ext R/W Nuc 320K | 1D58FFF 1D59000 | Ext SQA .. 90304K | 7588FFF 7589000 | Ext PLPA . 65844K | B5D5FFF B5D6000 | Ext CSA . 389288K | 231F 2320 | Ext PVT 1521664K | 7FFF One way we make a bunch of room below the line is to move little used ISPF modules out of LPA in LINKLIST. ++VER(Z038) FMID(HIF7R02). ++MOVE (FLM$CPI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMCPCS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMDDL ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMLPCBL) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMLPFRT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMLPGEN) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMLSS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMPTC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMRA ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMRC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMRTLIB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMS$LNK) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMS$SRV) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMS7C ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTBMAP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTCCPS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTCIDS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTCLGT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTCPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTCPP ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTCVER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTMMI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTMSI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMTXFER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMUM ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMVCSUP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMXE ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (FLMXI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. ++MOVE (ISRSUPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 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 (was Generic query on Region allocation failure) **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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 size is 280K. The default V=R region size is 140K. The maximum V=V region size is 8168K. Based on this: CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ GDACSAH = D2x(GDACSA) /* display in hex */ CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ CSAEND = D2x(CSAEND) /* display in hex */ So CSA <16M is too small. On Wed, Jan 16, 2019 at 9:20 AM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > 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 each new release of CICS. > Looking at the libraries on our system, I see: > > CTS 5.4 007D1410 > CTS 5.3 007B6070 > CTS 5.2 0078C7D0 > CTS 5.1 00772608 > CTS 4.2 00752958 > CTS 4.1 00719EA8 > > Wayne's Fault Analyzer output showed the size of that modul
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 size is 280K. The default V=R region size is 140K. The maximum V=V region size is 8168K. Based on this: CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ GDACSAH = D2x(GDACSA) /* display in hex */ CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ CSAEND = D2x(CSAEND) /* display in hex */ So CSA <16M is too small. On Wed, Jan 16, 2019 at 9:20 AM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > 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 each new release of CICS. Looking at > the libraries on our system, I see: > > CTS 5.4 007D1410 > CTS 5.3 007B6070 > CTS 5.2 0078C7D0 > CTS 5.1 00772608 > CTS 4.2 00752958 > CTS 4.1 00719EA8 > > Wayne's Fault Analyzer output showed the size of that module that had been > loaded to be X'7B6070'. > The IEF032I message in his job output showed below the line system usage > to be 260K and private is 7908K. > That doesn't leave much room if he only has 8M of below the line private > area. > > It is not surprising to me that he has found that it fails more often with > newer releases of CICS. > > I am a little surprised though if all three of the places that he has run > this have only 8M of below the line private. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 each new release of CICS. Looking at the libraries on our system, I see: CTS 5.4 007D1410 CTS 5.3 007B6070 CTS 5.2 0078C7D0 CTS 5.1 00772608 CTS 4.2 00752958 CTS 4.1 00719EA8 Wayne's Fault Analyzer output showed the size of that module that had been loaded to be X'7B6070'. The IEF032I message in his job output showed below the line system usage to be 260K and private is 7908K. That doesn't leave much room if he only has 8M of below the line private area. It is not surprising to me that he has found that it fails more often with newer releases of CICS. I am a little surprised though if all three of the places that he has run this have only 8M of below the line private. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 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). CVTGDA (offset x'230' in the CVT) has the address
> >of the GDA. GDACSA is the 4 bytes at offset x'6C'
>
> One way to do it is using IPCS.
>
> 0 Defaults
> Select Source ==> ACTIVE
> PF3
> 2 Analysis
> 6i (not listed on the menu)
> VSMINFO
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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). CVTGDA (offset x'230' in the CVT) has the address >of the GDA. GDACSA is the 4 bytes at offset x'6C' One way to do it is using IPCS. 0 Defaults Select Source ==> ACTIVE PF3 2 Analysis 6i (not listed on the menu) VSMINFO -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 16M (and that's where the "no excuse" becomes more valid), but here there is room for that big module but apparently not for even a small one in addition. That would be uncommon, but certainly conceivable (suppose the private region size is exactly 7M and the module is 7M-x'B000' bytes, thus no room for a x'C000' byte module -- and that doesn't even count all the system control blocks that are needed in below-16M private). 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). CVTGDA (offset x'230' in the CVT) has the address of the GDA. GDACSA is the 4 bytes at offset x'6C' Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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 CEE.SCEERUN(CEEBINIT) On Tue, Jan 15, 2019 at 7:35 AM Wayne Bickerdike wrote: > 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:06 AM Tom Marchant < > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >> 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: 260K EXT:4K SYS:10876K >> >> >> >>ATB- REAL: 3104K SLOTS: 0K >> >> >> >> VIRT- ALLOC: 12M SHRD: 0M >> >> >> >> >> > >> >Look at module DFHEISUP in the load library. Is it marked RMODE(24)? >> According to your Fault Analyzer report, the module is over 7 MB and it >> seems to be loaded below the line. Your job is using only 4K above the line. >> > >> >I would suggest you open a PMR with IBM. >> >> I looked at DFHEISUP on our system. It is indeed over 7MB in size and is >> marked RMODE(24). >> >> Open a PMR with CICS. IMO, there is no excuse for such a large module >> requiring RMODE(24). >> >> -- >> Tom Marchant >> >> > >> >>On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike >> wrote: >> >> >> >>> 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 >> >>> System Name . . . . . . . : S0W1 >> >>> Job Type. . . . . . . . . : Batch >> >>> Job ID. . . . . . . . . . : JOB02430 >> >>> Job Name. . . . . . . . . : $SDO512M >> >>> Job Step Name . . . . . . : n/a >> >>> ASID. . . . . . . . . . . : 1C >> >>> Abend TCB Address . . . . : 007FE990 >> >>> Job Execution Class . . . : A >> >>> Region Size . . . . . . . : 0M >> >>> EXEC Program Name . . . . : DFHEISUP >> >>> User ID . . . . . . . . . : BDB204 >> >>> Accounting Information. . : n/a >> >>> >> >>> Execution Environment: >> >>> >> >>> Operating System. . . . . : z/OS V2R2M0 >> >>> Data Facility Product . . : DFSMS z/OS V2R2M0 >> >>> CPU Model . . . . . . . . : 2817 >> >>> >> >>> NOTE: The execution environment for this event is no longer valid, >> save >> >>> areas >> >>> and data might have subsequently been updated. This is normally >> >>> caused >> >>> by condition handling routine processing. >> >>> >> >>> >> >>> >> >>> Load Module Name. . . . . . : DFHEISUP >> >>> >> >>> At Address. . . . . . . . : 7F90 >> >>> >> >>> Load Module Length. . . . : X'7B6070' >> >>> >> >>> >> >>> >> >>> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) >> >>> >> >>> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset >> X'7B5DE0') >> >>> >> >>> AMODE . . . . . . . . . . : 31 >> >>> >> >>> >> >>> >> >>> Additional instructions around event offset: >> >>> >> >>> >> >>> >> >>> Offset HexInstruction >> >>> >> >>>-2C 58C0 0010 L R12,16 >> >>> >> >>>-28 58C0 C000 L R12,0(,R12) >> >>> >> >>>-24 58C0 C004 L R12,4(,R12) >> >>> >> >>>-20 58C0 C144 L R12,324(,R12) >> >>> >> >>>-1C 58C0 C004 L R12,4(,R12) >> >>> >> >>>-18 BFCF C020 ICM R12,15,32(R12) >> >>> >> >>>-14 A784 0005 BRC 8,*+10 >> >>> >> >>>-10 180C LR R0,R12 >> >>> >> >>> -E A7F4 007D BRC 15,*+250 >> >>> >> >>> -A 4120 7008 LA R2,8(,R7) >> >>> >> >>> -6 4100 2000 LA R0,0(,R2) >> >>> >> >>> -2 1B11 SR R1,R1 >> >>> >> >>> 007BDD70 0A08 SVC 8(LOAD) >> >>> >> >>> +2 58C0 322C L R12,556(,R3) >> >>> >> >>> +6 166C OR R6,R12 >> >>> >> >>> +8 164C OR R4,R12 >> >>> >> >>> +A A7F4 0071 BRC 15,*+226 >> >>> >> >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >> >>> 21:21:48 >> >>> +2 58C0 322C L R12,556(,R3) >> >>> >> >>> +6 166C OR R6,R12 >> >>> >> >>> +8 164C
Re: Abend 106 (was Generic query on Region allocation failure)
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:06 AM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > 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: 260K EXT:4K SYS:10876K > >> > >>ATB- REAL: 3104K SLOTS: 0K > >> > >> VIRT- ALLOC: 12M SHRD: 0M > >> > >> > > > >Look at module DFHEISUP in the load library. Is it marked RMODE(24)? > According to your Fault Analyzer report, the module is over 7 MB and it > seems to be loaded below the line. Your job is using only 4K above the line. > > > >I would suggest you open a PMR with IBM. > > I looked at DFHEISUP on our system. It is indeed over 7MB in size and is > marked RMODE(24). > > Open a PMR with CICS. IMO, there is no excuse for such a large module > requiring RMODE(24). > > -- > Tom Marchant > > > > >>On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike > wrote: > >> > >>> 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 > >>> System Name . . . . . . . : S0W1 > >>> Job Type. . . . . . . . . : Batch > >>> Job ID. . . . . . . . . . : JOB02430 > >>> Job Name. . . . . . . . . : $SDO512M > >>> Job Step Name . . . . . . : n/a > >>> ASID. . . . . . . . . . . : 1C > >>> Abend TCB Address . . . . : 007FE990 > >>> Job Execution Class . . . : A > >>> Region Size . . . . . . . : 0M > >>> EXEC Program Name . . . . : DFHEISUP > >>> User ID . . . . . . . . . : BDB204 > >>> Accounting Information. . : n/a > >>> > >>> Execution Environment: > >>> > >>> Operating System. . . . . : z/OS V2R2M0 > >>> Data Facility Product . . : DFSMS z/OS V2R2M0 > >>> CPU Model . . . . . . . . : 2817 > >>> > >>> NOTE: The execution environment for this event is no longer valid, save > >>> areas > >>> and data might have subsequently been updated. This is normally > >>> caused > >>> by condition handling routine processing. > >>> > >>> > >>> > >>> Load Module Name. . . . . . : DFHEISUP > >>> > >>> At Address. . . . . . . . : 7F90 > >>> > >>> Load Module Length. . . . : X'7B6070' > >>> > >>> > >>> > >>> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > >>> > >>> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset > X'7B5DE0') > >>> > >>> AMODE . . . . . . . . . . : 31 > >>> > >>> > >>> > >>> Additional instructions around event offset: > >>> > >>> > >>> > >>> Offset HexInstruction > >>> > >>>-2C 58C0 0010 L R12,16 > >>> > >>>-28 58C0 C000 L R12,0(,R12) > >>> > >>>-24 58C0 C004 L R12,4(,R12) > >>> > >>>-20 58C0 C144 L R12,324(,R12) > >>> > >>>-1C 58C0 C004 L R12,4(,R12) > >>> > >>>-18 BFCF C020 ICM R12,15,32(R12) > >>> > >>>-14 A784 0005 BRC 8,*+10 > >>> > >>>-10 180C LR R0,R12 > >>> > >>> -E A7F4 007D BRC 15,*+250 > >>> > >>> -A 4120 7008 LA R2,8(,R7) > >>> > >>> -6 4100 2000 LA R0,0(,R2) > >>> > >>> -2 1B11 SR R1,R1 > >>> > >>> 007BDD70 0A08 SVC 8(LOAD) > >>> > >>> +2 58C0 322C L R12,556(,R3) > >>> > >>> +6 166C OR R6,R12 > >>> > >>> +8 164C OR R4,R12 > >>> > >>> +A A7F4 0071 BRC 15,*+226 > >>> > >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > >>> 21:21:48 > >>> +2 58C0 322C L R12,556(,R3) > >>> > >>> +6 166C OR R6,R12 > >>> > >>> +8 164C OR R4,R12 > >>> > >>> +A A7F4 0071 BRC 15,*+226 > >>> > >>> +E A7F8 0010 LHI R15,16 > >>> > >>> +12 5820 7018 L R2,24(,R7) > >>> > >>> +16 1812 LR R1,R2 > >>> > >>> > >>> > >>> Program Status Word (PSW) . : 078D 807BDD72 > >>> > >>> PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > >>> Problem > >>>State > >>> > >>> > >>> > >>> General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): > >>> >
Re: Abend 106 (was Generic query on Region allocation failure)
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: 260K EXT:4K SYS:10876K >> >>ATB- REAL: 3104K SLOTS: 0K >> >> VIRT- ALLOC: 12M SHRD: 0M >> >> > >Look at module DFHEISUP in the load library. Is it marked RMODE(24)? According >to your Fault Analyzer report, the module is over 7 MB and it seems to be >loaded below the line. Your job is using only 4K above the line. > >I would suggest you open a PMR with IBM. I looked at DFHEISUP on our system. It is indeed over 7MB in size and is marked RMODE(24). Open a PMR with CICS. IMO, there is no excuse for such a large module requiring RMODE(24). -- Tom Marchant > >>On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: >> >>> 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 >>> System Name . . . . . . . : S0W1 >>> Job Type. . . . . . . . . : Batch >>> Job ID. . . . . . . . . . : JOB02430 >>> Job Name. . . . . . . . . : $SDO512M >>> Job Step Name . . . . . . : n/a >>> ASID. . . . . . . . . . . : 1C >>> Abend TCB Address . . . . : 007FE990 >>> Job Execution Class . . . : A >>> Region Size . . . . . . . : 0M >>> EXEC Program Name . . . . : DFHEISUP >>> User ID . . . . . . . . . : BDB204 >>> Accounting Information. . : n/a >>> >>> Execution Environment: >>> >>> Operating System. . . . . : z/OS V2R2M0 >>> Data Facility Product . . : DFSMS z/OS V2R2M0 >>> CPU Model . . . . . . . . : 2817 >>> >>> NOTE: The execution environment for this event is no longer valid, save >>> areas >>> and data might have subsequently been updated. This is normally >>> caused >>> by condition handling routine processing. >>> >>> >>> >>> Load Module Name. . . . . . : DFHEISUP >>> >>> At Address. . . . . . . . : 7F90 >>> >>> Load Module Length. . . . : X'7B6070' >>> >>> >>> >>> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) >>> >>> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') >>> >>> AMODE . . . . . . . . . . : 31 >>> >>> >>> >>> Additional instructions around event offset: >>> >>> >>> >>> Offset HexInstruction >>> >>>-2C 58C0 0010 L R12,16 >>> >>>-28 58C0 C000 L R12,0(,R12) >>> >>>-24 58C0 C004 L R12,4(,R12) >>> >>>-20 58C0 C144 L R12,324(,R12) >>> >>>-1C 58C0 C004 L R12,4(,R12) >>> >>>-18 BFCF C020 ICM R12,15,32(R12) >>> >>>-14 A784 0005 BRC 8,*+10 >>> >>>-10 180C LR R0,R12 >>> >>> -E A7F4 007D BRC 15,*+250 >>> >>> -A 4120 7008 LA R2,8(,R7) >>> >>> -6 4100 2000 LA R0,0(,R2) >>> >>> -2 1B11 SR R1,R1 >>> >>> 007BDD70 0A08 SVC 8(LOAD) >>> >>> +2 58C0 322C L R12,556(,R3) >>> >>> +6 166C OR R6,R12 >>> >>> +8 164C OR R4,R12 >>> >>> +A A7F4 0071 BRC 15,*+226 >>> >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >>> 21:21:48 >>> +2 58C0 322C L R12,556(,R3) >>> >>> +6 166C OR R6,R12 >>> >>> +8 164C OR R4,R12 >>> >>> +A A7F4 0071 BRC 15,*+226 >>> >>> +E A7F8 0010 LHI R15,16 >>> >>> +12 5820 7018 L R2,24(,R7) >>> >>> +16 1812 LR R1,R2 >>> >>> >>> >>> Program Status Word (PSW) . : 078D 807BDD72 >>> >>> PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, >>> Problem >>>State >>> >>> >>> >>> General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): >>> >>>R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') >>> >>>R1: (2,048 bytes of storage addressable) >>> >>>R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') >>> >>>R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') >>> >>>R4: 0064 (1,948 bytes of storage addressable) >>> >>>R5: 6FE8 (8,093,720 bytes of storage addressable) >>> >>>R6: 007BD800 (Module DFHEISUP + X'7B5870') >>> >>>R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') >>> >>>R8: 007AED20 (Module DFHEISUP + X'7A6D90') >>> >>>R9: 007F8190 (32,368 bytes of storage addressable) >>> >>>R10: (2,048 bytes of storage addressable) >>> >>>R11: 807BD82A (Module DFHEISUP +
Re: Abend 106 (was Generic query on Region allocation failure)
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 module. LLA is involved (the DDNAME of *VLF* shows that). The 106-0C is due to an obtain of storage being unsuccessful. I can't think of a way that LLA REFRESH could have an impact (whether done or not done). S106 - 0C - NOT ENOUGH STORAGE WAS AVAILABLE FOR FETCH TO DO A GETMAIN FOR THE MODULE OR CONTROL BLOCKS. CHECK REGISTER 0: If you're going to post something like this, please post from the official documentation. That documentation is "Not enough storage was available for FETCH to get storage for the module or control blocks.". There is no information in register 0. The specific piece of data happens to be in register 4 (feel free to submit an RCF to ask that this be included in the documentation). As shown in one of the posts, the value in reg 4 at time of the abend 106-0C is x'14'. The module appears to be small (less than x'C000') and has no relocation needs. Since there was no relocation, the only reason for the 106-0C for x'14' for *VLF* is that LLA's attempt to obtain storage for that amount was not successful. For all I know, the utility did some variable-length GETMAIN and ate up all the private storage below 16M. Take a dump of the address space and see. And look at the system trace entry for the completion of the conditional getmain (an SSRV entry) which would contain things such as the size requested (in case there was some weirdness going on between the "right size" and the "requested size"). You could always try things like stopping LLA, or not having LLA manage the CEE.SCEERUN (perhaps named SYS1.CEE.SCEERUN) data set. That would keep LLA from trying to obtain the storage, but then normal module fetch would try to obtain the same amount. I wonder if the difference between releases is that the module in question (which sounds like it's CEEBINIT) is now eligible for LLA caching (but doesn't work for some reason once it is cached), whereas it did not used to be. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
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: 3104K SLOTS: 0K > > VIRT- ALLOC: 12M SHRD: 0M > > Look at module DFHEISUP in the load library. Is it marked RMODE(24)? According to your Fault Analyzer report, the module is over 7 MB and it seems to be loaded below the line. Your job is using only 4K above the line. I would suggest you open a PMR with IBM. -- Tom Marchant >On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: > >> 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 >> System Name . . . . . . . : S0W1 >> Job Type. . . . . . . . . : Batch >> Job ID. . . . . . . . . . : JOB02430 >> Job Name. . . . . . . . . : $SDO512M >> Job Step Name . . . . . . : n/a >> ASID. . . . . . . . . . . : 1C >> Abend TCB Address . . . . : 007FE990 >> Job Execution Class . . . : A >> Region Size . . . . . . . : 0M >> EXEC Program Name . . . . : DFHEISUP >> User ID . . . . . . . . . : BDB204 >> Accounting Information. . : n/a >> >> Execution Environment: >> >> Operating System. . . . . : z/OS V2R2M0 >> Data Facility Product . . : DFSMS z/OS V2R2M0 >> CPU Model . . . . . . . . : 2817 >> >> NOTE: The execution environment for this event is no longer valid, save >> areas >> and data might have subsequently been updated. This is normally >> caused >> by condition handling routine processing. >> >> >> >> Load Module Name. . . . . . : DFHEISUP >> >> At Address. . . . . . . . : 7F90 >> >> Load Module Length. . . . : X'7B6070' >> >> >> >> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) >> >> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') >> >> AMODE . . . . . . . . . . : 31 >> >> >> >> Additional instructions around event offset: >> >> >> >> Offset HexInstruction >> >>-2C 58C0 0010 L R12,16 >> >>-28 58C0 C000 L R12,0(,R12) >> >>-24 58C0 C004 L R12,4(,R12) >> >>-20 58C0 C144 L R12,324(,R12) >> >>-1C 58C0 C004 L R12,4(,R12) >> >>-18 BFCF C020 ICM R12,15,32(R12) >> >>-14 A784 0005 BRC 8,*+10 >> >>-10 180C LR R0,R12 >> >> -E A7F4 007D BRC 15,*+250 >> >> -A 4120 7008 LA R2,8(,R7) >> >> -6 4100 2000 LA R0,0(,R2) >> >> -2 1B11 SR R1,R1 >> >> 007BDD70 0A08 SVC 8(LOAD) >> >> +2 58C0 322C L R12,556(,R3) >> >> +6 166C OR R6,R12 >> >> +8 164C OR R4,R12 >> >> +A A7F4 0071 BRC 15,*+226 >> >> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >> 21:21:48 >> +2 58C0 322C L R12,556(,R3) >> >> +6 166C OR R6,R12 >> >> +8 164C OR R4,R12 >> >> +A A7F4 0071 BRC 15,*+226 >> >> +E A7F8 0010 LHI R15,16 >> >> +12 5820 7018 L R2,24(,R7) >> >> +16 1812 LR R1,R2 >> >> >> >> Program Status Word (PSW) . : 078D 807BDD72 >> >> PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, >> Problem >>State >> >> >> >> General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): >> >>R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') >> >>R1: (2,048 bytes of storage addressable) >> >>R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') >> >>R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') >> >>R4: 0064 (1,948 bytes of storage addressable) >> >>R5: 6FE8 (8,093,720 bytes of storage addressable) >> >>R6: 007BD800 (Module DFHEISUP + X'7B5870') >> >>R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') >> >>R8: 007AED20 (Module DFHEISUP + X'7A6D90') >> >>R9: 007F8190 (32,368 bytes of storage addressable) >> >>R10: (2,048 bytes of storage addressable) >> >>R11: 807BD82A (Module DFHEISUP + X'7B589A') >> >>R12: (2,048 bytes of storage addressable) >> >>R13: 6F50 (8,093,872 bytes of storage addressable) >> >>R14: 807BD8FE (Module DFHEISUP + X'7B596E') >> >>R15: 007BDC78 (Module DFHEISUP + X'7B5CE8') >> >> Abend Code. . . . . . . . . : S106-X'C' >> >> Machine Instruction . . . . : 0A0D SVC 13 (ABEND) >>At Address. . . . . . . . : 01074DB8 >>AMODE .
Re: Abend 106 (was Generic query on Region allocation failure) [EXTERNAL]
Wayne is the failure always for module CEEBINIT? If so, CEEBINIT is a 24 bit program. What is the private area size for 24 bit? Are you running out of 24 bit storage? Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [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 00.05 SECSRB: 0 HR 00 MIN 00.01 SEC VIRT: 7908K SYS: 260K EXT:4K SYS:10876K ATB- REAL: 3104K SLOTS: 0K VIRT- ALLOC: 12M SHRD: 0M On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: > 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 > System Name . . . . . . . : S0W1 > Job Type. . . . . . . . . : Batch > Job ID. . . . . . . . . . : JOB02430 > Job Name. . . . . . . . . : $SDO512M > Job Step Name . . . . . . : n/a > ASID. . . . . . . . . . . : 1C > Abend TCB Address . . . . : 007FE990 > Job Execution Class . . . : A > Region Size . . . . . . . : 0M > EXEC Program Name . . . . : DFHEISUP > User ID . . . . . . . . . : BDB204 > Accounting Information. . : n/a > > Execution Environment: > > Operating System. . . . . : z/OS V2R2M0 > Data Facility Product . . : DFSMS z/OS V2R2M0 > CPU Model . . . . . . . . : 2817 > > NOTE: The execution environment for this event is no longer valid, > save areas > and data might have subsequently been updated. This is normally > caused > by condition handling routine processing. > > Load Module Name. . . . . . : DFHEISUP > At Address. . . . . . . . : 7F90 > Load Module Length. . . . : X'7B6070' > > Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') > AMODE . . . . . . . . . . : 31 > > Additional instructions around event offset: > > Offset HexInstruction >-2C 58C0 0010 L R12,16 >-28 58C0 C000 L R12,0(,R12) >-24 58C0 C004 L R12,4(,R12) >-20 58C0 C144 L R12,324(,R12) >-1C 58C0 C004 L R12,4(,R12) >-18 BFCF C020 ICM R12,15,32(R12) >-14 A784 0005 BRC 8,*+10 >-10 180C LR R0,R12 > -E A7F4 007D BRC 15,*+250 > -A 4120 7008 LA R2,8(,R7) > -6 4100 2000 LA R0,0(,R2) > -2 1B11 SR R1,R1 > 007BDD70 0A08 SVC 8(LOAD) > +2 58C0 322C L R12,556(,R3) > +6 166C OR R6,R12 > +8 164C OR R4,R12 > +A A7F4 0071 BRC 15,*+226 > JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 21:21:48 > +2 58C0 322C L R12,556(,R3) > +6 166C OR R6,R12 > +8 164C OR R4,R12 > +A A7F4 0071 BRC 15,*+226 > +E A7F8 0010 LHI R15,16 > +12 5820 7018 L R2,24(,R7) > +16 1812 LR R1,R2 > > Program Status Word (PSW) . : 078D 807BDD72 > > PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > Problem >State > > General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): >R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') >R1: (2,048 bytes of storage addressable) >R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') >R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') >R4: 0064 (1,948 bytes of storage addressable) >R5: 6FE8 (8,093,720 bytes of storage addressable) >R6: 007BD800 (Module DFHEISUP + X'7B5870') >R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') >R8: 007AED20 (Module DFHEISUP + X'7A6D90') >R9: 007F8190 (32,368 bytes of storage addressable) >R10: (2,048 bytes of storage addressable) >R11: 807BD82A (Module DFHEISUP + X'7B589A') >R12: (2,048 bytes of storage addressable) >R13: 6F50 (8,093,872 bytes of storage addressable) >R14: 807BD8FE (Module DFHEISUP + X'7B596E') >R15: 007BDC78 (Module DFHEISUP + X'7B5CE8') > >
Re: Abend 106 (was Generic query on Region allocation failure)
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://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. > 10 - NO STORAGE FOR EXLIST. > 14 - NO STORAGE FOR MODULE. > 18 - UNABLE TO FIX STORAGE. > > But Register 0 has an address in it. > > On Fri, Jan 11, 2019 at 9:53 PM Wayne Bickerdike > wrote: > > > > 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 > > System Name . . . . . . . : S0W1 > > Job Type. . . . . . . . . : Batch > > Job ID. . . . . . . . . . : JOB02430 > > Job Name. . . . . . . . . : $SDO512M > > Job Step Name . . . . . . : n/a > > ASID. . . . . . . . . . . : 1C > > Abend TCB Address . . . . : 007FE990 > > Job Execution Class . . . : A > > Region Size . . . . . . . : 0M > > EXEC Program Name . . . . : DFHEISUP > > User ID . . . . . . . . . : BDB204 > > Accounting Information. . : n/a > > > > Execution Environment: > > > > Operating System. . . . . : z/OS V2R2M0 > > Data Facility Product . . : DFSMS z/OS V2R2M0 > > CPU Model . . . . . . . . : 2817 > > > > NOTE: The execution environment for this event is no longer valid, save > > areas > > and data might have subsequently been updated. This is normally > > caused > > by condition handling routine processing. > > > > > > > > Load Module Name. . . . . . : DFHEISUP > > > > At Address. . . . . . . . : 7F90 > > > > Load Module Length. . . . : X'7B6070' > > > > > > > > Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > > > > At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') > > > > AMODE . . . . . . . . . . : 31 > > > > > > > > Additional instructions around event offset: > > > > > > > > Offset HexInstruction > > > >-2C 58C0 0010 L R12,16 > > > >-28 58C0 C000 L R12,0(,R12) > > > >-24 58C0 C004 L R12,4(,R12) > > > >-20 58C0 C144 L R12,324(,R12) > > > >-1C 58C0 C004 L R12,4(,R12) > > > >-18 BFCF C020 ICM R12,15,32(R12) > > > >-14 A784 0005 BRC 8,*+10 > > > >-10 180C LR R0,R12 > > > > -E A7F4 007D BRC 15,*+250 > > > > -A 4120 7008 LA R2,8(,R7) > > > > -6 4100 2000 LA R0,0(,R2) > > > > -2 1B11 SR R1,R1 > > > > 007BDD70 0A08 SVC 8(LOAD) > > > > +2 58C0 322C L R12,556(,R3) > > > > +6 166C OR R6,R12 > > > > +8 164C OR R4,R12 > > > > +A A7F4 0071 BRC 15,*+226 > > > > JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > > 21:21:48 > > +2 58C0 322C L R12,556(,R3) > > > > +6 166C OR R6,R12 > > > > +8 164C OR R4,R12 > > > > +A A7F4 0071 BRC 15,*+226 > > > > +E A7F8 0010 LHI R15,16 > > > > +12 5820 7018 L R2,24(,R7) > > > > +16 1812 LR R1,R2 > > > > > > > > Program Status Word (PSW) . : 078D 807BDD72 > > > > PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > > Problem > >State > > > > > > > > General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): > > > >R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') > > > >R1: (2,048 bytes of storage addressable) > > > >R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') > > > >R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') > > > >R4: 0064 (1,948 bytes of storage addressable) > > > >R5: 6FE8 (8,093,720 bytes of storage addressable) > > > >R6: 007BD800 (Module DFHEISUP + X'7B5870') > > > >R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') > > > >R8: 007AED20 (Module DFHEISUP + X'7A6D90') > > > >R9: 007F8190 (32,368 bytes of storage addressable) > > > >R10: (2,048 bytes of storage addressable) > > > >R11: 807BD82A (Module DFHEISUP + X'7B589A') > > > >R12: (2,048 bytes of storage addressable) > > > >R13: 6F50 (8,093,872 bytes of storage addressable) > > > >R14: 807BD8FE (Module
Re: Abend 106 (was Generic query on Region allocation failure)
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. 10 - NO STORAGE FOR EXLIST. 14 - NO STORAGE FOR MODULE. 18 - UNABLE TO FIX STORAGE. But Register 0 has an address in it. On Fri, Jan 11, 2019 at 9:53 PM Wayne Bickerdike wrote: > > 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 > System Name . . . . . . . : S0W1 > Job Type. . . . . . . . . : Batch > Job ID. . . . . . . . . . : JOB02430 > Job Name. . . . . . . . . : $SDO512M > Job Step Name . . . . . . : n/a > ASID. . . . . . . . . . . : 1C > Abend TCB Address . . . . : 007FE990 > Job Execution Class . . . : A > Region Size . . . . . . . : 0M > EXEC Program Name . . . . : DFHEISUP > User ID . . . . . . . . . : BDB204 > Accounting Information. . : n/a > > Execution Environment: > > Operating System. . . . . : z/OS V2R2M0 > Data Facility Product . . : DFSMS z/OS V2R2M0 > CPU Model . . . . . . . . : 2817 > > NOTE: The execution environment for this event is no longer valid, save > areas > and data might have subsequently been updated. This is normally > caused > by condition handling routine processing. > > > > Load Module Name. . . . . . : DFHEISUP > > At Address. . . . . . . . : 7F90 > > Load Module Length. . . . : X'7B6070' > > > > Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > > At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') > > AMODE . . . . . . . . . . : 31 > > > > Additional instructions around event offset: > > > > Offset HexInstruction > >-2C 58C0 0010 L R12,16 > >-28 58C0 C000 L R12,0(,R12) > >-24 58C0 C004 L R12,4(,R12) > >-20 58C0 C144 L R12,324(,R12) > >-1C 58C0 C004 L R12,4(,R12) > >-18 BFCF C020 ICM R12,15,32(R12) > >-14 A784 0005 BRC 8,*+10 > >-10 180C LR R0,R12 > > -E A7F4 007D BRC 15,*+250 > > -A 4120 7008 LA R2,8(,R7) > > -6 4100 2000 LA R0,0(,R2) > > -2 1B11 SR R1,R1 > > 007BDD70 0A08 SVC 8(LOAD) > > +2 58C0 322C L R12,556(,R3) > > +6 166C OR R6,R12 > > +8 164C OR R4,R12 > > +A A7F4 0071 BRC 15,*+226 > > JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > 21:21:48 > +2 58C0 322C L R12,556(,R3) > > +6 166C OR R6,R12 > > +8 164C OR R4,R12 > > +A A7F4 0071 BRC 15,*+226 > > +E A7F8 0010 LHI R15,16 > > +12 5820 7018 L R2,24(,R7) > > +16 1812 LR R1,R2 > > > > Program Status Word (PSW) . : 078D 807BDD72 > > PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > Problem >State > > > > General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): > >R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') > >R1: (2,048 bytes of storage addressable) > >R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') > >R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') > >R4: 0064 (1,948 bytes of storage addressable) > >R5: 6FE8 (8,093,720 bytes of storage addressable) > >R6: 007BD800 (Module DFHEISUP + X'7B5870') > >R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') > >R8: 007AED20 (Module DFHEISUP + X'7A6D90') > >R9: 007F8190 (32,368 bytes of storage addressable) > >R10: (2,048 bytes of storage addressable) > >R11: 807BD82A (Module DFHEISUP + X'7B589A') > >R12: (2,048 bytes of storage addressable) > >R13: 6F50 (8,093,872 bytes of storage addressable) > >R14: 807BD8FE (Module DFHEISUP + X'7B596E') > >R15: 007BDC78 (Module DFHEISUP + X'7B5CE8') > > Abend Code. . . . . . . . . : S106-X'C' > > Machine Instruction . . . . : 0A0D SVC 13 (ABEND) >At Address. . . . . . . . : 01074DB8 >AMODE . . . . . . . . . . : 31 > > Instructions around point of failure: > >Offset HexInstruction > -22 43C0 5078 IC R12,120(,R5) > -1E 185C LR R5,R12 > -1C 8950 0008 SLL R5,8 > -18 16F5 OR R15,R5 > -16 1824 LR R2,R4 > -14 1837 LR R3,R7 > -12
Re: Abend 106 (was Generic query on Region allocation failure)
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 module. Reason code will point that out. Roger W. Suhr suhr...@gmail.com Get Outlook for Android 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 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- ALLOC: 12M SHRD: 0M On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: > 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 > System Name . . . . . . . : S0W1 > Job Type. . . . . . . . . : Batch > Job ID. . . . . . . . . . : JOB02430 > Job Name. . . . . . . . . : $SDO512M > Job Step Name . . . . . . : n/a > ASID. . . . . . . . . . . : 1C > Abend TCB Address . . . . : 007FE990 > Job Execution Class . . . : A > Region Size . . . . . . . : 0M > EXEC Program Name . . . . : DFHEISUP > User ID . . . . . . . . . : BDB204 > Accounting Information. . : n/a > > Execution Environment: > > Operating System. . . . . : z/OS V2R2M0 > Data Facility Product . . : DFSMS z/OS V2R2M0 > CPU Model . . . . . . . . : 2817 > > NOTE: The execution environment for this event is no longer valid, save > areas > and data might have subsequently been updated. This is normally > caused > by condition handling routine processing. > > > > Load Module Name. . . . . . : DFHEISUP > > At Address. . . . . . . . : 7F90 > > Load Module Length. . . . : X'7B6070' > > > > Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > > At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') > > AMODE . . . . . . . . . . : 31 > > > > Additional instructions around event offset: > > > > Offset HexInstruction > >-2C 58C0 0010 L R12,16 > >-28 58C0 C000 L R12,0(,R12) > >-24 58C0 C004 L R12,4(,R12) > >-20 58C0 C144 L R12,324(,R12) > >-1C 58C0 C004 L R12,4(,R12) > >-18 BFCF C020 ICM R12,15,32(R12) > >-14 A784 0005 BRC 8,*+10 > >-10 180C LR R0,R12 > > -E A7F4 007D BRC 15,*+250 > > -A 4120 7008 LA R2,8(,R7) > > -6 4100 2000 LA R0,0(,R2) > > -2 1B11 SR R1,R1 > > 007BDD70 0A08 SVC 8(LOAD) > > +2 58C0 322C L R12,556(,R3) > > +6 166C OR R6,R12 > > +8 164C OR R4,R12 > > +A A7F4 0071 BRC 15,*+226 > > JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > 21:21:48 > +2 58C0 322C L R12,556(,R3) > > +6 166C OR R6,R12 > > +8 164C OR R4,R12 > > +A A7F4 0071 BRC 15,*+226 > > +E A7F8 0010 LHI R15,16 > > +12 5820 7018 L R2,24(,R7) > > +16 1812 LR R1,R2 > > > > Program Status Word (PSW) . : 078D 807BDD72 > > PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > Problem >State > > > > General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): > >R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') > >R1: (2,048 bytes of storage addressable) > >R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') > >R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') > >R4: 0064 (1,948 bytes of storage addressable) > >R5: 6FE8 (8,093,720 bytes of storage addressable) > >R6: 007BD800 (Module DFHEISUP + X'7B5870') > >R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') > >R8: 007AED20 (Module DFHEISUP + X'7A6D90') > >R9: 007F8190 (32,368 bytes of storage addressable) > >R10: (2,048 bytes of storage addressable) > &
Re: Abend 106 (was Generic query on Region allocation failure)
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- ALLOC: 12M SHRD: 0M On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: > 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 > System Name . . . . . . . : S0W1 > Job Type. . . . . . . . . : Batch > Job ID. . . . . . . . . . : JOB02430 > Job Name. . . . . . . . . : $SDO512M > Job Step Name . . . . . . : n/a > ASID. . . . . . . . . . . : 1C > Abend TCB Address . . . . : 007FE990 > Job Execution Class . . . : A > Region Size . . . . . . . : 0M > EXEC Program Name . . . . : DFHEISUP > User ID . . . . . . . . . : BDB204 > Accounting Information. . : n/a > > Execution Environment: > > Operating System. . . . . : z/OS V2R2M0 > Data Facility Product . . : DFSMS z/OS V2R2M0 > CPU Model . . . . . . . . : 2817 > > NOTE: The execution environment for this event is no longer valid, save > areas > and data might have subsequently been updated. This is normally > caused > by condition handling routine processing. > > > > Load Module Name. . . . . . : DFHEISUP > > At Address. . . . . . . . : 7F90 > > Load Module Length. . . . : X'7B6070' > > > > Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > > At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') > > AMODE . . . . . . . . . . : 31 > > > > Additional instructions around event offset: > > > > Offset HexInstruction > >-2C 58C0 0010 L R12,16 > >-28 58C0 C000 L R12,0(,R12) > >-24 58C0 C004 L R12,4(,R12) > >-20 58C0 C144 L R12,324(,R12) > >-1C 58C0 C004 L R12,4(,R12) > >-18 BFCF C020 ICM R12,15,32(R12) > >-14 A784 0005 BRC 8,*+10 > >-10 180C LR R0,R12 > > -E A7F4 007D BRC 15,*+250 > > -A 4120 7008 LA R2,8(,R7) > > -6 4100 2000 LA R0,0(,R2) > > -2 1B11 SR R1,R1 > > 007BDD70 0A08 SVC 8(LOAD) > > +2 58C0 322C L R12,556(,R3) > > +6 166C OR R6,R12 > > +8 164C OR R4,R12 > > +A A7F4 0071 BRC 15,*+226 > > JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > 21:21:48 > +2 58C0 322C L R12,556(,R3) > > +6 166C OR R6,R12 > > +8 164C OR R4,R12 > > +A A7F4 0071 BRC 15,*+226 > > +E A7F8 0010 LHI R15,16 > > +12 5820 7018 L R2,24(,R7) > > +16 1812 LR R1,R2 > > > > Program Status Word (PSW) . : 078D 807BDD72 > > PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > Problem >State > > > > General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): > >R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') > >R1: (2,048 bytes of storage addressable) > >R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') > >R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') > >R4: 0064 (1,948 bytes of storage addressable) > >R5: 6FE8 (8,093,720 bytes of storage addressable) > >R6: 007BD800 (Module DFHEISUP + X'7B5870') > >R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') > >R8: 007AED20 (Module DFHEISUP + X'7A6D90') > >R9: 007F8190 (32,368 bytes of storage addressable) > >R10: (2,048 bytes of storage addressable) > >R11: 807BD82A (Module DFHEISUP + X'7B589A') > >R12: (2,048 bytes of storage addressable) > >R13: 6F50 (8,093,872 bytes of storage addressable) > >R14: 807BD8FE (Module DFHEISUP + X'7B596E') > >R15: 007BDC78 (Module DFHEISUP + X'7B5CE8') > > Abend Code. . . . . . . . . : S106-X'C' > > Machine Instruction . . . . : 0A0D SVC 13 (ABEND) >At Address. . . . . . . . : 01074DB8 >AMODE . . . . . . . . . . : 31 > > Instructions around point of failure: > >Offset HexInstruction > -22 43C0 5078 IC R12,120(,R5) > -1E 185C LR R5,R12 > -1C 8950 0008 SLL R5,8 > -18 16F5 OR R15,R5 > -16 1824 LR R2,R4 > -14 1837 LR R3,R7 > -12 184B LR R4,R11 > -10 18E1 LR R14,R1 > -E 89E0 000C SLL R14,12 >
Re: Abend 106 (was Generic query on Region allocation failure)
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 System Name . . . . . . . : S0W1 Job Type. . . . . . . . . : Batch Job ID. . . . . . . . . . : JOB02430 Job Name. . . . . . . . . : $SDO512M Job Step Name . . . . . . : n/a ASID. . . . . . . . . . . : 1C Abend TCB Address . . . . : 007FE990 Job Execution Class . . . : A Region Size . . . . . . . : 0M EXEC Program Name . . . . : DFHEISUP User ID . . . . . . . . . : BDB204 Accounting Information. . : n/a Execution Environment: Operating System. . . . . : z/OS V2R2M0 Data Facility Product . . : DFSMS z/OS V2R2M0 CPU Model . . . . . . . . : 2817 NOTE: The execution environment for this event is no longer valid, save areas and data might have subsequently been updated. This is normally caused by condition handling routine processing. Load Module Name. . . . . . : DFHEISUP At Address. . . . . . . . : 7F90 Load Module Length. . . . : X'7B6070' Machine Instruction . . . . : 0A08 SVC 8 (LOAD) At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') AMODE . . . . . . . . . . : 31 Additional instructions around event offset: Offset HexInstruction -2C 58C0 0010 L R12,16 -28 58C0 C000 L R12,0(,R12) -24 58C0 C004 L R12,4(,R12) -20 58C0 C144 L R12,324(,R12) -1C 58C0 C004 L R12,4(,R12) -18 BFCF C020 ICM R12,15,32(R12) -14 A784 0005 BRC 8,*+10 -10 180C LR R0,R12 -E A7F4 007D BRC 15,*+250 -A 4120 7008 LA R2,8(,R7) -6 4100 2000 LA R0,0(,R2) -2 1B11 SR R1,R1 007BDD70 0A08 SVC 8(LOAD) +2 58C0 322C L R12,556(,R3) +6 166C OR R6,R12 +8 164C OR R4,R12 +A A7F4 0071 BRC 15,*+226 JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 21:21:48 +2 58C0 322C L R12,556(,R3) +6 166C OR R6,R12 +8 164C OR R4,R12 +A A7F4 0071 BRC 15,*+226 +E A7F8 0010 LHI R15,16 +12 5820 7018 L R2,24(,R7) +16 1812 LR R1,R2 Program Status Word (PSW) . : 078D 807BDD72 PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, Problem State General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') R1: (2,048 bytes of storage addressable) R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') R4: 0064 (1,948 bytes of storage addressable) R5: 6FE8 (8,093,720 bytes of storage addressable) R6: 007BD800 (Module DFHEISUP + X'7B5870') R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') R8: 007AED20 (Module DFHEISUP + X'7A6D90') R9: 007F8190 (32,368 bytes of storage addressable) R10: (2,048 bytes of storage addressable) R11: 807BD82A (Module DFHEISUP + X'7B589A') R12: (2,048 bytes of storage addressable) R13: 6F50 (8,093,872 bytes of storage addressable) R14: 807BD8FE (Module DFHEISUP + X'7B596E') R15: 007BDC78 (Module DFHEISUP + X'7B5CE8') Abend Code. . . . . . . . . : S106-X'C' Machine Instruction . . . . : 0A0D SVC 13 (ABEND) At Address. . . . . . . . : 01074DB8 AMODE . . . . . . . . . . : 31 Instructions around point of failure: Offset HexInstruction -22 43C0 5078 IC R12,120(,R5) -1E 185C LR R5,R12 -1C 8950 0008 SLL R5,8 -18 16F5 OR R15,R5 -16 1824 LR R2,R4 -14 1837 LR R3,R7 -12 184B LR R4,R11 -10 18E1 LR R14,R1 -E 89E0 000C SLL R14,12 -A 54E0 9038 N R14,56(,R9) -6 A5EA 8400 OILHR14,X'8400' -2 181E LR R1,R14 01074DB8 0A0D SVC 13(ABEND) +2 18FB LR R15,R11 +4 180C LR R0,R12 +6 181D LR R1,R13 +8 58E0 02FC L R14,764 +C 58D0 E248 L R13,584(,R14) +10 0DED BASRR14,R13 +12 18BF LR R11,R15 Program Status Word (PSW) . : 070C1000 81074DBA PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 0, AMODE 31, Supervisor State General
Re: Abend 106 (was Generic query on Region allocation failure)
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 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 message(s) and/or abend(s). > > It appears that what Wayne posted was truncated. > > IEW4000I FETCH FOR MODULE CEEBINIT FROM DDNAME *VLF*FAILED BECAUSE > INSUFFICI > CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEBINIT, RETURN CODE 24, REASON > CODE 2 > > Can we get the complete information? It probably doesn't matter much. The > missing part of IEW4000I is not going to help, but possibly having the > rest of CSV031I (including the complete reason code) would. > > In at least one case, Fetch processing did a getmain, and the getmain > failed. Why? Because the application needed more region than was defined, > probably. > I'd suggest capturing a dump on the IEW4000I message issued by nucleus > module CSVLLTCH. That's what IBM service will likely ask for. > > The message can also occur because of a problem with doing the relocation > processing (I'm not sure why that lands with a message about insufficient > storage). > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
Great catch, I was totally confused if these 2 posts were different issues, so not it appears there may have been an LLA / LINKLST issue tied to the 106 abend, syslog + abend + return code would help greatly in the diagnosis. I've seen issues with certain vendor product getting refreshed in the linklist causing these types of abends. a new listlist and an LLA update or refresh, may solve the issue., if this was the case. Carmen Vitullo - Original Message - From: "Peter Relson" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, January 9, 2019 12:26:24 PM 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 is just the generic result of a preceding problem which likely had message(s) and/or abend(s). It appears that what Wayne posted was truncated. IEW4000I FETCH FOR MODULE CEEBINIT FROM DDNAME *VLF* FAILED BECAUSE INSUFFICI CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEBINIT, RETURN CODE 24, REASON CODE 2 Can we get the complete information? It probably doesn't matter much. The missing part of IEW4000I is not going to help, but possibly having the rest of CSV031I (including the complete reason code) would. In at least one case, Fetch processing did a getmain, and the getmain failed. Why? Because the application needed more region than was defined, probably. I'd suggest capturing a dump on the IEW4000I message issued by nucleus module CSVLLTCH. That's what IBM service will likely ask for. The message can also occur because of a problem with doing the relocation processing (I'm not sure why that lands with a message about insufficient storage). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 is just the generic result of a preceding problem which likely had message(s) and/or abend(s). It appears that what Wayne posted was truncated. IEW4000I FETCH FOR MODULE CEEBINIT FROM DDNAME *VLF*FAILED BECAUSE INSUFFICI CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEBINIT, RETURN CODE 24, REASON CODE 2 Can we get the complete information? It probably doesn't matter much. The missing part of IEW4000I is not going to help, but possibly having the rest of CSV031I (including the complete reason code) would. In at least one case, Fetch processing did a getmain, and the getmain failed. Why? Because the application needed more region than was defined, probably. I'd suggest capturing a dump on the IEW4000I message issued by nucleus module CSVLLTCH. That's what IBM service will likely ask for. The message can also occur because of a problem with doing the relocation processing (I'm not sure why that lands with a message about insufficient storage). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
