Wayne, Does your company or the same company do the z/OS on all the sites you mentioned?
I think we should have mean the SCEERUN library, from the LINKLIST that contains the LE modules. Since CEEBINIT is the module indicated, there could be, a custom module in another library in the link list (from an old LE or whatever). I just worked through one of these where somehow a pre-maintenance module ended up mixed in with the post maintenance module. Abends and error messages that made no sense, that were no help to find the real problem. There is probably some piece of truth in the errors, but some of it is misleading and garbage. The trick is to figure out which, or of course it's a real bug that makes you and IBM question your sanity, until the problem is found. Mark -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Wayne Bickerdike Sent: Wednesday, January 09, 2019 3:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Generic query on Region allocation failure *to IBM-MAIN* *On Wed, 9 Jan 2019 13:47:48 +0000, Allan Staller wrote:>This looks more like the linklst dataset has taken an extent for some reason.Not to me. I would expect S106 reason code 0F, not reason code 0C.>>Try compressing the dataset containing CEEBINIT, followed by F LLA,REFRESHI don't recommend it.* The dataset is not in extents and it is in STEPLIB. And a 0C return never pointed to that as the problem. I'll repeat, this condition occurs on multiple configurations. The one I have posted is from our early development LPAR, a zVM hosted z/OS 2.2. But I have this problem on two other customer sites, one a Z13 running CICS 5.3 and 5.4. The other a BC12 on CICS 5.3. Do IBM test between releases? On Thu, Jan 10, 2019 at 7:37 AM Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > Typo. "Increasing that value raises COMMON at the expense of PRIVATE, > and vice versa." > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jesse 1 Robinson > Sent: Wednesday, January 09, 2019 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Generic query on Region allocation failure > > I don't expect below-the-line CSA to be much affected by a hardware > change (not in 2018 for sure) but in the case of a true push/pull swap > out, you are likely using a whole new IODF--which is software. That > was certainly true for us. Putting aside the question of whether this > explains the current problem, let me share the advice I always give my > colleagues. > > As Peter notes, the dividing line between common and private is > determined by the system at IPL time. I don't know all the details, > but the process is something like this. > > 1. Calculate the 24 bit PLPA total. > 2. Add in the amount of 24 bit common requested in PARMLIB member CSA=. > 3. Round up to the next 1M boundary. > > Everything below that boundary is 24 bit COMMON. Everything above it > to the 16M line is 24 bit PRIVATE. You can tweak the contents of 24 > bit PLPA to some extent, but the main control is CSA=. Increasing that > value raises PRIVATE at the expense of COMMON, and vice versa. > Changing the ratio one way or the other can be problematic, especially > if it's unexpected. For example, CICS tends to want lots of PRIVATE, > while DB2 tends to want LOTS of COMMON. (At one time anyway.) So you > want to keep a ratio that is known to work. > > My advice is to look at your happily running system. Calculate a value > in the middle of the 24 bit COMMON area; basically 500K below the boundary. > That is the sweet value for CSA=. It allows for maximum fluctuation up > or down in PLPA before the boundary changes unexpectedly. You need to > review this calculation periodically, but don't obsess over it. > > . > . > 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 Peter Hunkeler > Sent: Tuesday, January 08, 2019 11:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):AW: Re: Generic query on Region allocation failure > > >So when we move to a higher version of hardware the storage area > >below the > line shrinks ? > > > > Not necessarily. It may or may not, and the cautious system programmer > may or may not be able to avoid it. There are certain boundaries in > the address space map that must lie on a megabyte boundary. The > boundary between the common and the private areas is one. > > > A single byte more used in the common area might move the > common-private boundary down by one megabyte. One is often able to > reduced the size of some common areas (CSA/SQA) by a small about and > thus avoid the common-private boundary shift. > > > HTH > Peter Hunkeler > > ---------------------------------------------------------------------- > 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: This email and any attachments may contain confidential information that is intended solely for use by the intended recipient(s). If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the communication. If you received this email in error, please contact the sender by reply email and immediately delete the communication. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
