>I see the problem and the consequences, but I think your conclusion and >originally already the title are not and cannot be correct: it shouldn't >matter to WLM whether tasks want to play by WLM's rules or not. WLM >should manage the tasks, whether they want to play along or not. Where >is the rule that I should not issue more van x timer pops in 10 msecs?
Exactly. There is no such rule. And if there is, it is always the fault of the application, that needs to be 'tuned'. Which was also the outcome of this ETR, just the tuning wasn't done. >The problem here is, that WLM is not capable of managing its children >when they are a little more exotic than the usual kids in class. or at >least, it is not capable of reporting meaningfully about them. E.g. if I >organize 100 TSO users to repeatedly enter a transaction at the same >time, I bet WLM will fully panic and report PI's in the 100's, although >performance might be good. Well, what's exotic about IMS? We are unable to use any subsystem IMS classification (with actual response time goals, which would be in the range of 99% complete within 0.02s - I cannot specify 100%, and I have a dim recollection that setting the time was also problematic - last I tried several years ago). The reason being that right at 9am sharp transaction rate increases from an idle 100/s to 1200/s. When we tried, all hell broke loose, all alerts started screaming. We were forced to go back to exvel goals for IMS, and it took me quite a while to understand that a goal of 99% velocity is unreasonable, it took even longer to get the IMS people to agree. What started my ETR off was the fact that users had started complaining about very bad response times in WBIFN. And a PI in the triple digits kind of jumps out at you when you start looking at the performance of a system, especially when the box is not full and the lpar doesn't take what it could according to the number of processors and the weight.... Regards, Barbara -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger ---------------------------------------------------------------------- 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
