Chris, Just to illustrate your point about being a waste of time, I want to relate a story from a long time ago when I worked at the State of California, CALTRANs. At the time, memory was very expensive, and we were running a S360/60 I believe with one megabyte of real storage under OS/MVT. It was deemed important to accurately determine the amount of memory each job step was going to use, and formulas were provided by many programs for doing just that, both our own programs and IBM utilities. Sizes and numbers of buffers had to be considered, and a lot of desk time was spent determining this number before going to keypunch with our JCL changes.
Each week, installation management would run a series of reports which listed how much core memory each job step requested, how much it used, and if your requested more than 6K more than you actually used, you ended up on the "Excess Core Report" which was distributed to your supervisor. Your supervisor then used this report as a basis for your weekly meeting and in your performance reviews. In addition, the number of JCL errors you received and abends were also listed. Programmers soon found out a new implementation of the law of unintended consequences...to avoid abends, programmers stopped testing. No testing...no abends! Fed up with this nit-witted approach to data center management (I was the young kid on the block at this time), I wrote a program which ATTACHed the program I was running, using a PARM. When the ATTACHed program completed, I did a conditional GETMAIN for the remaining storage and always issued a return code zero. Needless to say, my weekly reviews started looking pretty good, and my programs actually worked in production, since they had been tested. I was soon "loaning" my program out to others in our group, and then surreptiously to almost the entire programming staff. All was laid bare, however, when one of the supervisors asked a young woman programmer who was having a problem with her program what this program and PARM was, and she just said, "Oh, everyone uses that!". I did manage to keep my job, and the reports were dropped, but the story serves to illustrate how different thinking was in that era. Managing any computer resource, be it memory, DASD, CPU, JES Spool space, etc., has always been a difficult issue to get a handle on, and one I think deserves a lot of discussion before any action is taken. The constraints and governors we have in place have served us fairly well over forty years, but many of them are becoming quaint. Whole products have been written around some (STOPX37, for example). It's definitely time to re-visit each one of these, and I believe each one should be addressed separately, since they are so different. After a lot of ideas are presented (and this list will provide a lot of great ideas), maybe someone whose area this is at SHARE can meld this into a requirement or white paper and submit it to IBM. Since we've been discussing virtual memory, that may be a good place to start. It might be interesting to approach this logically, by providing a comprehensive set of what this function is to do, and when it is to do it. And what should be the result if a limit is exceeded? Abend? Allow extensions a number of times with warnings? After its function is defined, we should allow IBM to implement the function in the manner they choose to be consistent with their architectural goals. Additionally, if IBM is able to implement these objectives, it will go a long ways toward simplifying a needlessly archaic and hard-to-understand impediment to zNextGenners use of the system we have come to know and love, without compromising its rich functionality and robustness. Tom Harper NEON Enterprise Software, Inc. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Friday, December 14, 2007 7:15 PM To: [email protected] Subject: Re: REGION=0M and LSQA Jim says > Well, I type too slowly to do much flaming. And of course, I am > willing to discuss this in great detail any time you come to > Poughkeepsie and take me out for a beer. You're so shallow :-) But I'll buy you a beer anyway. > However, I am at somewhat > of a loss to figure out how an operating system would distinguish > between a program which intentionally uses a lot of storage, and a > "runaway" program which unintentionally uses a lot of storage, without > someone telling the operating system how much storage the program > is intended to use. The mind-set behind IEFUSI (and its ancestors) and the REGION keyword is to simply deny access to the computing resource in the first place (S822) if the ambit claim expressed in REGION is larger than the IEFUSI imposed limit, -OR- (and this is the worst case) to crash the job (S878 or S80A) after some period of presumably productive execution, if it had the temerity to use more than the number "guessed" ahead of time by the system programmer or application programmer. In the former case it is just a frustrating waste of people time. In the latter case, all of the resources used by the job up until that point are -wasted- and as I've often said here in the past, there's no mail-in rebate. REGION related problems and job reruns are incredibly common in the wild. Arguably the current design drives up your hw/sw bill because you're wasting resources that could otherwise have been used productively. Obviously that is a knuckle headed concept. Particularly if we accept the notion that the computer's job is to run the work presented to it by the user. Surely the system ought to be able to manage its own resources (including real and AUX) and protect itself from ill-behaved programs, but that is something MVS has steadfastly refused to do for 40 years. "OH WELL" Just (change the REGION and) play it again Sam. There are plenty of ways the system could solve this problem in ways that don't rely on the user making a nebulous guess about something they really can't predict with any reliability in all but the most trivial of cases. Because at the end of the day, the tools we are supposed to use don't actually address the root problem at all. We have way too many knobs in MVS and most of them ought to be disconnected for the customer's own safety. CC ---------------------------------------------------------------------- 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
