On Sat, 15 Dec 2007 09:09:08 +0000, Michael Poil <[EMAIL PROTECTED]> wrote:
>... >One of the big problems was that the Java design required it to support >"lazy" programming whereby the programmer did not have to clean up >dynamically-allocated data areas ... >... >... resulting in the JIT which compiles on the fly; again >complex and needing storage for compilation and storing the compiled >results. > >All software products in this category need yet more storage to function, >I worked in CICS a few years back and I know that it is the case, it has >to manage the environment and this costs. >... The details obviously vary, but any system that provides a platform for transaction processing shares many of the same problems. They are at the mercy of the whims of the transaction developers. They obviously cannot predict the storage requirements of the transactions they support. However, it is probably known how the platform's own storage requirements scale for number of simultaneous transactions, network connections, open datasets or databases, etc. If the platform can, upon request, report the amount of storage used by transactions, the instalation can roughly determine how storage used by its transaction mix will scale, and come up with a storage estimate. It is certainly best if this estimate can be used by the platform as a soft limit, so that the platform will report when it is approached and dynamically expand its storage allocation when the limit is reached. REGION (if applicable) can be set at a much higher lever and be manually set higher when the soft limit is increased. All this takes some work to be done when new workloads are introduced, but does not seem unreasonable to me. Pat O'Keefe ---------------------------------------------------------------------- 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
