I would agree with you Mike. In our case, and this was single instance WebSphere, I was unable to do any precise predetermination of storage requirements prior to implementation. We had IBM WAS, vendor software and CTG. Not that CTG was going to kill us from a requirements viewpoint. Before I was outsourced I had looked at *potential* requirements of moving from single instance WAS V4 (in 3.5 compat mode) to WAS V5 cell group, adding a cell group of 7 address spaces. Again near impossible to precisely predetermine requirements for node agent, daemon, deploy control, deploy server, app. control and app server the other address space escapes me at this moment. I believe in this case, Java & WAS, since these historically came from single server hardware/single application the storage requirements were not nearly as critical or scrutinized. Of course moving WAS to mainframe it now had to play nicely with other more traditional and mostly well behaved applications. There are plenty of rants from a few of us in the archives. In my case I had lobbied to get as much of the WAS applications as I could over to the mainframe. And although WAS can wreak havoc on the traditional workloads I was more than happy to try to accommodate WAS, Domino and our more traditional workloads on a small g5 2 way and I think we did a nice job of keeping all of these workloads relatively happy but it can be nerve wracking at times. Michael Poil <[EMAIL PROTECTED]> wrote: Sometimes it is impossible to do that as is the case with Java. The amount of storage used within the JVM has a static component based on user definitions, but after that it is a function of what the Java program is doing and there is no way the calculate that as it is completely dynamic and can vary from one run to another based on what the program does. It also depends on how the customer has set up LE, CTG, DB2 etc. etc., so there are other variables to make it even harder. You can get typical sizes for the application by experience.
Not trying to excuse Java, it is just how the software works. Storage creep can also be due to the way that the users write their code, it is not always the fault of the software vendor. It would be nice if everything was straight-forward in this world, but it refuses to play ball. ------------------------------------------------------------------------------------------------------------------ Mike Poil Java z/OS Level 3 Service IBM United Kingdom Limited, Hursley Park, Winchester SO21 2JN Internal: 246824 External: +44 (0)1962 816824 Java debugging: http://www.ibm.com/developerworks/java/jdk/diagnosis/ ------------------------------------------------------------------------------------------------------------------ Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
