... Or, they could build a new LNKLST dynamically (instead of doing an IPL).
On 2019-01-09 08:47, Allan Staller wrote: > This looks more like the linklst dataset has taken an extent for some reason. > > Try compressing the dataset containing CEEBINIT, followed by F LLA,REFRESH > IF that does not work an IPL will be necessary. > > HTH, > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> 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 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 CSV028I ABEND106-0C JOBNAME=$SDO128M STEPNAME=STEP020 > > IEA995I SYMPTOM DUMP OUTPUT 742 > > SYSTEM COMPLETION CODE=106 REASON CODE=0000000C > > TIME=22.36.34 SEQ=00110 CPU=0000 ASID=001C > > PSW AT TIME OF ERROR 070C1000 81074DBA ILC 2 INTC 0D > > NO ACTIVE MODULE FOUND > > NAME=UNKNOWN > > DATA AT PSW 01074DB4 - 8400181E 0A0D18FB 180C181D > > AR/GR 0: 007FC94C/00001F00 1: 00000000/84106000 > > 2: 00000000/26080021 3: 00000000/0000000C > > 4: 00000000/00000014 5: 00000000/007FF7F8 > > 6: 00000000/7F5F7100 7: 00000000/0000000C > > 8: 00000000/7F5F7168 9: 00000000/010752E0 > > A: 00000000/00000024 B: 00000000/00000014 > > C: 00000000/00000000 D: 00000000/7F5F7168 > > E: 00000000/84106000 F: 00000000/0000000C > > END OF SYMPTOM DUMP > > IEF450I $SDO128M STEP020 - ABEND=S106 U0000 REASON=0000000C > > > On Wed, Jan 9, 2019 at 2:36 PM Peter <dbajava...@gmail.com> wrote: > >> Apologies for being ignorant >> >> So when we move to a higher version of hardware the storage area below >> the line shrinks ? >> >> >> On Wed 9 Jan, 2019, 2:52 AM Mike Schwab <mike.a.sch...@gmail.com wrote: >> >>> 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. >>> >>> >>> On Tue, Jan 8, 2019 at 4:08 PM <ronjhawki...@gmail.com> wrote: >>>> Jesse, >>>> >>>> While I like Region=0, one should always remember that there are >>> installation parms and exits that control how "zero" is actually >>> applied below and above the line. Ann old version of SAS that liked >>> to getmain everything up to the top of private has bitten me in the >>> past as it blew >> up >>> on the system areas allocated down from top ☹ >>>> There is a wealth of data on private area usage in the SMF Type >>>> 30-4 >>> records and the Type 78-2 records that the OP can use to check the >> history >>> of Private and Common usage across changes in CEC, OS, etc. >>>> Simply checking the available private region for addresses before >>>> and >>> after the migration may help to drill down on the problem. A simple >> change >>> in Common storage can mean huge changes in available private. >>>> MXG is our friend. >>>> >>>> Ron Hawkins >>>> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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 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 the week or so afterwards, we >> experienced >>> a handful of 'storage shortage abends' in tasks that had been >>> running unchanged for years. AFAIK no technical explanations ever >>> came forth. In the few PMRs we opened, the advice was to increase region >>> size. We did. >>> Problems went away. Move on. >>>> I do have one piece of advice. Never specify a smallish region >>>> size. If >>> it's worth your time and effort to type in any region size at all, >>> go for some number >16M. It generally 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. >>>> . >>>> . >>>> 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: 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 NNNNNJJJ >>>>> FAILED - SYSTEM ERROR IN INITIATOR IEF472I NNNNNJJJ >>>> That means that the region that was specified is not available. >>>> >>>> Most likely, the region specified is less than 16M and that much >> storage >>> is not available below the line. It is certainly possible that the >>> available region size below the line is smaller on your old system >>> than >> is >>> available on your new system. >>>> -- >>>> 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 >>> >>> >>> -- >>> 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 >>> >> ---------------------------------------------------------------------- >> 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 > ::DISCLAIMER:: > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
