*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 <[email protected]> wrote: > Typo. "Increasing that value raises COMMON at the expense of PRIVATE, and > vice versa." > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Jesse 1 Robinson > Sent: Wednesday, January 09, 2019 12:32 PM > To: [email protected] > 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 > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Peter Hunkeler > Sent: Tuesday, January 08, 2019 11:03 PM > To: [email protected] > 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 [email protected] with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
