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

Reply via email to