IBM Mainframe Discussion List <[email protected]> wrote on 11/21/2008 01:40:45 PM:
> I'm not saying that I agree that GETMAIN should initialize the storage. > I am just saying that the way storage is handled has changed in z/OS > 1.10 and it bit us in vendor code. As I said earlier, programming 101 > says that you should initialize any area you plan on using so, if the > program was coded correctly, changes in GETMAIN wouldn't have caused > this problem. > That being said, can you guarantee that all of your old assembler > programs initialize their working storage? I thought we had already discussed this on IBM-MAIN, but further investigation reveals that it was on ASSEMBLER-LIST: Date: Tue, 19 Aug 2008 16:05:19 -0400 Reply-To: IBM Mainframe Assembler List <[EMAIL PROTECTED]> Sender: IBM Mainframe Assembler List <[EMAIL PROTECTED]> From: Jim Mulder <[EMAIL PROTECTED]> Subject: Re: Efficiency of code In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="US-ASCII" IBM Mainframe Assembler List <[EMAIL PROTECTED]> wrote on 08/19/2008 03:33:27 AM: > Jim Mulder wrote: > > > In z/OS 1.10, for low private subpools, GETMAIN has been > > changed to allocate forward from the beginning of a page > > boundary. > > About time. That was one of my OS/360 MVT mods. It enabled > lots of compilers (especially PL/I) and lots more programs > to run in ~100K regions, a critical requirement when a 1MB > machine was still rare and very costly. > > But it also broke quite a few things, which we had to ZAP > (preferable then to making a source mod given how hard it > was to obtain the optional material [source] for a moving > target [i.e., elements changed frequently by PTFs]). Code > in some IBM components actually depended upon the odd way > (which was never explained even if it was documented) that > GETMAIN worked. > > Did anything fall out as a consequence of this change in > z/OS 1.10 system testing? If so, I would find that very, > very amusing. DF/HSM, Program Loader, and a local test tool were casualties - fewer than I was anticipating. Less amusing will be possible fallout with customer applications, but we do have an undocumented parmlib switch to revert to the old behavior which IBM Level 2 support can direct the customer to use as a bypass if needed. > Did the fix also include (even inadvertently) a fix to > the problem of (for example) a program that repeatedly > OBTAINs 2056 bytes of storage? In the past, this would > cause 2056 bytes to be allocated from a brand-new 4K > page, each time, instead of the 2056 byte areas being > allocated adjacent to one another. Combining adjacent > areas into the same DQE was also one of my OS/360 MVT > GETMAIN mods. Sadly, it was judged that OS/VS[2] made > that mod unnecessary (since more [virtual] storage was > then available to us than "we would ever use"), so the > mod didn't get carried forward. Later, just before the > arrival of MVS/XA, the problem came back, and VSCR was > again a hot issue. That was the reason for doing this. In tests of how long it takes to open 100,000 data sets in the DB2 address space, a lot of time was spent scanning the long DQE/FQE chains for subpool 252, due to small GETMAINs done by OPEN. This change greatly reduced the number of DQEs/FQEs. However, the merging of new DQE space with an older FQE is done only for request sizes less than 8K, since we had to preserve the unfortunately documented statement that requests for at least 8K from a pageable private subpool are guaranteed to be zeroed by the system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
