Hmmmh IBM-DB2 l2 often refuse to even at partial dumps!!!! Also AFAIR the PAGEDEL didn't release all storage so massive combination of PAGEADD/PAGEDEL can cause problems too. We had this problem because of automation, sick
Roland -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Friday, November 09, 2007 8:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Real storage usage - a quick question On Fri, 9 Nov 2007 19:32:51 +0000, Martin Packer <[EMAIL PROTECTED]> wrote: > >You'd better be able to contain the dump space requirements. MAXSPACE= on your dump options. >Worst case in >paging space. Better case in memory, though that might not be >economically feasible. I've known 3 separate cases of customers either >running out of paging space or getting awfully close. And no, I don't >know the syntax for PAGEADD or whatever it's called. Do you in a hurry? >:-) > Yes, but maybe I can't type that fast or probably I am not looking at the console. :-) That is what automation is for. But using automation to add pagespace after a aux shortage message begs the question: If you are already putting the DASD aside for the spare page data set(s), why not just add it to begin with? Perhaps in the "old days" you kept a spare on the back end of some volume where response time mattered. But now, unless you have SLED DASD that wouldn't be an issue (unless you had it on the back of a volume that you let get RESERVEd). With customizable volume sizes... or even if you don't use custom sizes (DR considerations), DASD is still cheap enough to define all your spares up front and always have them available for the worst case scenario. ---------------------------------------------------------------------- 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
