On Wed, 2 Nov 2005 08:03:48 -0600, Craddock, Chris answered Barbara wwho said: >> No, it isn't. Since someone else is taking control away from me, I >>cannot plan at all or rather, I have to plan for desaster. Your attitude >>makes me think that some BMC products probably do the same - overwrite >>without regard to the stated rules. But then, why shouldn't you? It's not >>your business that gets hung when a bug strikes. > >With respect to your "plan for disaster" point, your DBA has complete >control over the amount of virtual storage allocated for buffering. If >they act responsibly then you won't have a problem. If they don't, then >whose fault is that? > >Right now there are too many conflicting points of control in z/OS. The >DB2 designers have chosen to remove what might otherwise be a hidden >limit (the MEMLIMIT) and in doing so they have given control over (and >responsibility for) storage management to those who, in theory, >understand the database and its business goals. You may disagree with >that philosophy, but you have not presented any case that it's wrong. >Just different.
They missed a very large portion of the puzzle, Chris: Aux. IF the DB2 and z/OS designers had ALSO implemented "private paging" for the (ab)users of virtual storage (like DB2 and perhaps GRS) then they would have moved all of the controls over to the appropriate groups and all would (eventually) be right with the world. If, for example, a new special DDNAME (like //JOBPAGE or //SYSPAGE) were also introduced for local paging for such units of work then the rest of the system's page datasets wouldn't grow so the impact to the non-DB2 sysprog would have been minimal. The DB2 jockeys could grow their buffer pools and would only impact themselves if they blew past their JOBPAGE/SYSPAGE defined limits. They could even potentially allocate their local paging data sets from their own luxurious DASD plantations... we non- DB2 types wouldn't care. (We might care about what they're doing to real storage, but if WLM is setup correctly that "should" take care of itself, too.) But IBM has not (yet, at least) implemented that design. Too bad, since it would do wonders towards addressing the gap between 64-bit virtual and the dearth of page space in currently architected systems. >And while I am up on my soap-box, speaking as a designer of systems >software, the biggest issue I run into is customer "creativity" with >configuration. 100 times more problems arise through that, than through >bugs that can be detected in testing here. I have a great deal of >sympathy for the position the IBM guys (DB2 and GRS at least) have >taken. I've been on both sides and I agree with both... but they missed a really big part. -- Tom Schmidt Madison, WI ---------------------------------------------------------------------- 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
