Just to further address the questions raised. I have no responsibility for the z/OS configuration on any of these 3 systems. One is a major government agency, the second is a non-banking financial institution and the third is IBM hosting our development LPAR.
As far as Tom Marchants assertion that it's a configuration issue, the JCL hasn't changed for running this utility in 12 years. It's almost a regression test between release of CICS to see what code has become more threadsafe. So basically what has changed is : 1. The release of CICS and the associated DFHEISUP module. 2.. Possibly CEEBINIT that is called from STEPLIB. 3. The environment that supports this batch program. (z/OS on 3 completely different configs). 3. The lookup table for APIs that are/aren't threadsafe. If I STEPLIB back to DFH520, it runs fine. DFH530 is erratic, DFH540 is broken. On Thu, Jan 10, 2019 at 10:10 AM Schuffenhauer, Mark <[email protected]> wrote: > 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 <[email protected]> On Behalf > Of Wayne Bickerdike > Sent: Wednesday, January 09, 2019 3:36 PM > To: [email protected] > 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 <[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 > 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 [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
