Kevin, > I wouldn't leave it so large after you have the dump. We have taken >systems down in the past by having MAXSPACE set too high.
I find that hard to believe, at least for z/OS 1.8 and up (haven't checked earlier releases). The svcdump processing clearly avoids a critical aux shortage, as evidenced (among other things) by the partial dump reason code 00000001 for the xxxxxxxx part of the reason: "SVC dump processing truncated the dump because a critical shortage of auxiliary storage existed." As Mark says, the impact depends on how much paging you normally do. On 5GB and 6GB (real) lpars we routinely set maxspace to 6G in order to dump any of those new-fangled applications that execute completely in USS. Dumping OMVS and all of its dataspaces *requires* more than 3GB maxspace, and that doesn't include the application yet. And believe me, we've got the scars of those ETRs where IBM blithely tells us that the required information is not in the dump. (They're only right about 30% of the time, but that's another story.) If it hasn't changed completely, what dumping does (explanation much simplified) is basically 'reroute' the frame ownership of everything that needs to get dumped to DUMPSRV. That's capture phase. During the write-out of the dump, the heavy paging starts, as everybody involved in the dump hits a page fault first (frame is somewhere else), and has to get a new one. This is what can cause the aux storage shortage, but not the critical shortage! (And remember that one is real storage and maxspace is virtual!) In one out of ten dumps we got an aux storage shortage, which forced a few address spaces to non-disp, allowed the dump to be written out and hence dumpsrv to release the frames. After that, all was well again. Our impact from dumping had more to do with long system-wide non-dispatchability (caused by other factors) adn the recovery taking place afterwards. For about a minute online response time gets bad. In essence, test a dump with maxspace set to 8GB during off-time, but don't worry too much about impact, especially if "IBM cannot find the problem without the dump". Regards, Barbara Nitz -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ---------------------------------------------------------------------- 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
