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
