Mark and Shane, >Do you have enough engines and capacity where bursts won't hurt other >workloads? If so, I might be inclined to run this work in SYSSTC (I >assume discretionary won't work for this since you mentioned "on time") >and then WLM doesn't have to manage it.
thanks for that suggestion. It was vetoed vehemently by the 'head WLM developer' when I suggested it. (And given that the address spaces have a life time from less than a second to forever, there is also no real way to give them a response time goal based on how long they live.) But now that the two of you suggest this, too, I might broach the idea again with my colleague (and ignore the developer). Should things get really nasty, we may want to do that. Let me give you some more information on this: 1. The lpar is not the lpar with the highest weight on that box. There is another sysplex on it that has a significantly higher weight. I mention this because our workload is basically driven by what the stock exchange does (completely outside our control), and in our experience the weights (and number of processors) determine how fast we are once business picks up significantly. During the stock crashes early in the year we ended up taking down and deactivating low importance lpars in advance just to handle the spikes. So I wouldn't really call that 'enough capacity' to spare, given the prohibitive software prices. 2. Varying the spare processor online to that lpar (giving it 3 cps) doesn't even show up in the PI. The reason being, (according to WLM) that the delays are not caused by cpu, but that's not what RMF tells me. RMF MIII says that about 60% is processor delay, the rest falls into 'other'. 3. That application has firm ties in MQSeries, so it shouldn't really run higher than that. (I think.) MQS is in STCHIGH (Imp1, exvel 50%), sysplex wide service class. 4. When the first complaints came, I started looking at STCHIGH, which incidentally was also the SC 'the broker' (these 65 asids on average) run in. 'The broker' only runs on that lpar, together with its own MQS and other infrastructure. The only other stuff there is a websphere application server that does not have that much load and runs in a lower importance SC. 5. First thing we did was put 'the brokers' into their own SC (Imp1, exvel 40%). And that's when the problem really showed up with PIs generally in the double digits, sometimes even more, and never near 1. (I even did a new SAS report to show all intervals with a PI>1 fro all service classes.) - The ETR is still open, and I had sent WLM SMF99 records. The 'head WLM developer' promised to tell us if we can live with this situation when the box gets full (and the lpar gets full). Interestingly enough, the last update in the ETR says "<he> has sent his findings to <you>. Please contact <him> to discuss the situation." Now the question is: Why aren't *we* informed what 'the situation' is? This really has my suspicions up, especially as we still have a complaint open with that ETR. - With this information, any more ideas what to do? Best regards, Barbara -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ---------------------------------------------------------------------- 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
