Martin,
Our systems group tries to be as pro-active as possible and tune systems so
that
there is the least impact when resources are unavailable. Especially. since
our
real time cash lanes are tied indirectly to our DB2 system for Credit Cards
sales,
etc. So, no DB2, no Sale.
So being, pro-active, the only problem I have is the word 'unlimited' which
is related to specifying 0K|0M. This allows extended private to grow to any
size
without a check until in infringes on the Buffer pools, work pools, edm pool
etc.
If everything were perfect and every piece of code in DB2 and MVS were
perfect,
I wouldn't be concerned. So if there is .0001% chance that this could
happen, and Murphy's law runs rampant in 24/7 shops, then we have to try and
determine ahead of time what the least amount of impact would be.
Given that this is a possibility, then what would be the least impact on
DB2,
and take the least amount of time to resolve? Running out of Extended
Private,
or running out of Work Space? If I have a cap on extended private and the
DB2
modules are already loaded, then the big problem would be VSAM processing
which
would show up as data set open and close failures. This could be alleviated
very
quickly by lowering DSMAX on the fly, assuming I had 8K to load IDCAMS close
module below the line. Or, we could stop a database that is known to have a
lot
of objects.
Now if I don't have a cap on extended private and it does grow to the point
that it uses DB2 work space, then I have seen various performance problems
and
even DB2 crash. Usually the first sign is the SOS reason code you get back
in the applications, but if this is a critical SYSOPR unit of work that is
in a must complete status or is holding locks then it gets more complicated.
At that point, if the system is up, we are involved in a more timely
analysis
to determine what unit or units of work are causing the problem. And cycling
DB2 is usually the last resort after console dumps and storage analysis.
I hope you see my point on this and you can probably add 1000 more since
this is your specialty. But it seems the damage and repair would take less
time on a private storage failure than a shortage in a work pool. So, having
a hard cap on private storage appears to be the best route to go.
-----Original Message-----
Sent: Friday, July 04, 2003 3:42 AM
To: IBM-MAIN@no-spam
Jeremiah scribbled... :-)
> Hey Martin, believe it or not I put a Cap on DBM1 of 64M, so if something
is
> filling up low extended private besides DB2 load modules and what he
needs
> for the table space allocations, I will know about it.
I think I heard you mention that before.
So do you expect DB2 to Abend or just for the load/GETMAIN to fail? In the
former case I'm not sure your users'd be happy about it. :-)
Martin Packer, MBCS Martin Packer/UK/IBM
020-8832-5167 in the UK (+44) (MOBX 273643, Internal 7-325167, Mobile
07802-245584)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html