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

Reply via email to