First, sorry for the rant yesterday and the shot at EG, I agree not necessary. I've been very frustrated with this migration. I've learned quite a bit though so there are some positives.
Secondly our migration to WAS V5.1 has shown how it can be difficult for small shops on tight purse strings to bridge to newer technology with a mostly traditional environment. We run CICS, IDMS, Batch, TSO, some UNIX stuff TSO and batch, I think we even still support some Adabas/Complete stuff but this will go away soon and throw in a Domino Change Management system. This is all on RB6 on an LPAR with 2.4 GB of storage. We also currently run WAS V4 in 3.5 compatibility or lightweight mode meaning we have on one task to manage for any given application. Now along comes WAS V5.1 and as we have it at current, in test, we have 7 tasks as part of one cell group; node agent, http server, daemon, deployment control, deployment servant, application control, application servant. Now, along comes HATS with a potential to deploy another 26 or so applications and what we're now learning is it may be more feasible from a performance as well as an architectural viewpoint to run 1 application per servant. So add 1 application control and 26 servants tasks. So now in test for our Call Center/HATS environment I'm up to 34 tasks. This is just test, we have acceptance and production to replicate. Now I'm up to 102 tasks. I also have another application to support and this could mean another 21 tasks for test, prod. and acceptance. I think you all see where I'm going and why I'm concerned. I agree with your sentiments, WAS is good for us and if we pull this off we probably keep our jobs. Our developers can see the value of the mainframe as a means of one stop shopping, if you will, for how they want to get the data and then present it. But, the cost to manage this environment may, in our case, be prohibitive to management spending the money we'll need to furnish a clean running environment. Now, my job is to be as cost effective as possible but show where we may will need to adjust for an upgrade that has already been put in front of management. Based on new requirements and how those requirements need to be managed from a resource perspective should help me justify additional resources. All I can do is present the data and then its all up to the suits. Thanks for your input. "Knutson, Sam" <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List <[email protected]> 10/19/2005 04:02 PM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: WAS z/OS and 64 bit (was Re: WebSphere/HATS Odyssey) Hi Patrick, It seems that WAS z/OS is in a similar stage of development to DB2 when it was first introduced. The initial response was fear and loathing due to the resource requirements. As people recognized the value that DB2 added as a relational DBMS, hardware and software grew more capable, and DB2 itself matured it became an accepted workload. WebSphere on z/OS right now has the reputation of being a dog but it may be that it will be one of the keys to web enablement and Java deployment on zSeries. If so maybe we will not look so harshly at it over time. Personally I least object to paying for memory as of the things on the floor that count it is one of them that I pay for mostly just once. CPU & I/O capacity comes with software ripple charges and more maintenance costs. Memory is relatively cheap. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." ---------------------------------------------------------------------- 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
