I would agree with Barbara on this. We run a mix of traditional work along with a Domino Change Management System with about 400 registered Users and WAS V4 in lightweight mode with about the same amount. Both applications can kill performance to our traditional workloads on our small 2 way. The WAS always sits at the top of the CPU usage monitor, again this is lightweight mode not full blown WAS, with the IDMS right behind it. The Domino application server task, at times, can dominate CPU as well.
Since we have been in a holding pattern while the bean counters basically decide our eventual fate I have been trying to hold the line as the production WAS environment adds Users who then navigate up through our traditional environment into our CA/IDMS. It has been a very delicate balancing act to see that the Production Users get service while I *try* to get cycles to the developers on this LPAR, no we don't have a test LPAR. If I had my druthers I would attempt to run the Unix workloads on their own LPAR where possible to eliminate the performance anomalies to the traditional mainframe workloads. If not possible I would load the LPAR with zAAP's as necessary to defray the impact. We recently also had a problem while running a batch job against a zFS which supports our Tech's Website and PDF files. The WAS in which the PDF's were connected to suddenly went haywire using significant CPU, operations then cancelled and eventually had to force the WAS, then zFS abended - all in all an ugly incident. While there is an open APAR that matches to some degree IBM asked us to try to recreate it as the WAS dump was not helpful. Please see OA15422 with APAR description: "LOOP IN USER CACHE, LOOKS LIKE A HANG IN ZFS" And as Barbara said not to disparage Steve but we have had our share of problems with running the new workloads with the traditional ones. Of course you can also see my rants in the archives about my WAS experiences if this wasn't enough. I do like the new workloads as they keep me employed at this point but they just don't seem to play well with the traditional ones. Barbara Nitz <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> 03/28/2006 12:53 AM Please respond to IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Bringing the fun back to z/OS - new course Steve's post prompts me to relate our MVS Unix/Linux experience - this is in no way meant to disparage Steve's efforts for courses... >Now, the ability to run UNIX on the mainframe melds a lot of strengths: >flexibility (run classic mainframe apps and UNIX apps on the same box), You'd better not. We are running a clustered Lotus Domino Server on our boxes and have to run several unix apps (ADSM - whatever that's called these days, WBIFN - gateway to the SWIFT net and Websphere Application Server). We found out very fast that these beasties tend to take over more than their share of processing power, so all of these UNIX apps quickly got their own lpar where traditional workload did not have to compete with these cpu hogs. >scalability, reduced footprint, reduced footprint?!? Even confined to their own lpars, the Dominoes take everything in terms of assigned processors and lpar weight, to the detriment of other lpars. And if these Unix dominated lpars don't get what they want, they stop working altogether. We are in the process of moving the UNIX apps to Linux under VM, where they can use the other type of processors and save us a lot of software costs (BMC is killing us, followed by CA.) Did I mention that we now run almost as many Linuxes as we run MVS lpars? Reduced foortprint?!? >Utilize the legendary strengths of the mainframe One of which was first failure data capture (and it worked, too, given the right knowledge in looking at a dump). All of these UNIX apps have never even heard the term first failure data capture, much less are familiar with the concept. With the exception of maybe one (stupid) user error on our part, IBM has proved incapable time and again to look at dumps (even those written by the product itself) and find a problem. Unless you can reproduce the problem, provided you have an inkling how, you get a lot of crap which always involves restarting a high availability application. And without a complaint on top a sev1/prio1 IBM doesn't even look at the problem, much less solve it. Even with a complaint, all we get is what we call in German 'holding hands' - meaning they commiserate with us but only attempt to calm us thus infuriating us more. I'd better stop here.... Regards, Barbara Nitz ---------------------------------------------------------------------- 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
