*It says REGION=512M to scan up to 100 modules.  How many modules are you
scanning?  Does it work with 10 modules, or 1?*

Some more detail.

Only one module is scanned at a time.

I build a member list and step1 is an IEBCOPY for the nth member in the
list. The temp dataset is input to DFHEISUP.

I've been running this process for years and since CICS 5.3, it's
problematic.

My original process was to take 100 modules at a time but since it now
fails with 1 module, something has changed for the worse with CICS 5.3 and
5.4.

I've tried REGION=0M, REGION=512M and gone as high as 1600M.



On Wed, Jan 9, 2019 at 3:38 PM Wayne Bickerdike <[email protected]> wrote:

> 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 <[email protected]> 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 <[email protected] 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 <[email protected]> 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: [email protected]
>> > >
>> > > -----Original Message-----
>> > > From: IBM Mainframe Discussion List <[email protected]> On
>> > Behalf Of Jesse 1 Robinson
>> > > Sent: Wednesday, 9 January 2019 06:13
>> > > To: [email protected]
>> > > 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
>> > > [email protected]
>> > >
>> > > -----Original Message-----
>> > > From: IBM Mainframe Discussion List [mailto:[email protected]]
>> > On Behalf Of Tom Marchant
>> > > Sent: Tuesday, January 08, 2019 7:49 AM
>> > > To: [email protected]
>> > > 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 [email protected] with the message: INFO IBM-MAIN
>> > >
>> > > ----------------------------------------------------------------------
>> > > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > > send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN
>> >
>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to [email protected] with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to