>The reason was that there was a single job running in the test service class and many jobs >running in production. In this case, the PI of the test service class >was greater than the PI of the production one, so WLM gave CPU cycles to >the single test job.
This wouldn't make any difference unless the higher importance work was already meeting its goals. The PI is tied to the importance level to determine where help is needed. >I don't have this particular problem with production CICS because I have >marked the production CICS service class as CPU CRITICAL. This means >that WLM will NEVER steal CPU cycles from CICS to help other, lower >performance, work even if the CICS PI is smaller than the other work's >PI. This is also qualified by the importance level. CPU cycles can certainly be stolen to satisfy service classes at the same (or higher) importance levels. If there are a lot of Importance 1 service classes, then your CICS would routinely be tapped for dispatching priority. >(PI is performance index. The smaller it is, the "better" the work in >that service class is running. A PI of 1 means that the work is >performing as specified in the service class. Less than 1 means that it >is exceeding its performance specification. The larger the PI, the >"worse" the service class is doing.) Much more significantly is whether WLM is "ignoring" the service class because of impossible to reach goals. This is a far more likely scenario where higher importance work is not helped while lower importance work is. Adam ---------------------------------------------------------------------- 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
