Sample output from the WLM Component


This is sample output from the WLM Component. Not all of the report is produced, simply because a lot of findings were made at this site and it did not seem reasonable to bore you with the entire report. Consequently, only example parts of the report are shown.

More comprehensive output can be viewed by following the SAS Output Delivery System sample output thread.

Please note that the output is narrative. The software analyzes data in your performance data base, and produces a narrative report much as would a performance analyst.

The WLM Component User Manual could be consulted for a detailed description of each finding produced by the software. A sample "rule" description from the WLM Component User Manual illustrates the level of documentation provided with each finding.


                              INTRODUCTION

This report consists of six parts: - This Introduction and a page of general run statistics. - A listing of the service policy which CPExpert extracted from the SMF Type 72 records. If the service policy was changed, CPExpert will list the new service policy and show the date/time the new policy was activated. - Service Policy Findings (if any). The Service Policy Findings are rules in the WLM001 to WLM050 range. These findings help identify problems or potential problems with the Workload Manager service definition. It is important to realize that these findings normally identify a POTENTIAL problem. Your systems programming staff must decide whether the findings (and their associated recommendations) make sense in your environment. For example, your systems programming staff might have deliberately selected certain parameter values. The values might be appropriate for your installation and your management objectives, even though CPExpert might fire a rule indicating that there is a potential problem with the parameter. You can disable CPExpert's checking the service definition by modifying the CHKPLCY guidance variable in USOURCE(WLMGUIDE). If the CHKPLCY guidance variable is set to N, CPExpert will not check the service definition for potential problems. - General System Findings (if any). The General System Findings are rules in the WLM050 to WLM099 range. These findings identify problems or potential problems with your overall system. For example, many of the rules deal with problems with the paging subsystem. These findings are made only if CPExpert detected that a performance goal was not met and that some general system problem might have caused the goal to be missed. - Specific Findings. The Specific Findings are rules above WLM100. These findings are made if CPExpert detected that a service class did not meet its performance goal. In the Specific Findings, CPExpert attempts to isolate the reason(s) the performance goal was not met. The Specific Findings also include findings related to Cross System Coupling Facility (XCF) performance. The XCF Findings are rules in the WLM600 to WLM699 range. These findings are made when CPExpert detects problems or potential problems with XCF performance. - Detailed reports. The detailed reports provide information about your system (e.g., CPU activity or applications executing in the SYSOTHER service class). These reports are intended to provide you with information to support the findings produced by CPExpert's analysis of system performance under the Workload Manager. When findings are produced by the WLM Component, please refer to the detailed description of the rule contained in the WLM Component User Manual. The User Manual will describe why the finding was made, give an assessment of the overall performance impact of the finding, and discuss alternatives which may be implemented to solve the problem. Thank you for using CPExpert! We hope that it helps you analyze your system performance under IBM's Workload Manager. Please call Computer Management Sciences at (703) 922-7027 if you have any questions or if you have suggestions for product improvement.


WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: *ALL Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 1 - PART 1 SUMMARY OF WLM COMPONENT OPERATION, EXECUTED ON Tue, May 20, 1997 TOTAL RECORDS READ FROM MXG PDBLIB.TYPE72GO INPUT FILE: 2,982 RECORDS SELECTED BASED UPON SYSTEM/START/END CRITERIA: 2,982 REPORT CLASS RECORDS REJECTED: 2,548 SERVICE CLASS PERIOD RECORDS SELECTED (SELECT LOGIC): 434 SERVICE CLASS RECORDS EXCLUDED (EXCLUDE LOGIC): 0 RECORDS REJECTED (SYSTEM SERVICE CLASS, DISC. GOAL, SERVER, ETC.): 348 TOTAL RECORDS ANALYZED FOR POOR PERFORMANCE: 86 RECORDS WITH PERFORMANCE WORSE THAN GOAL FOR SERVICE CLASS PERIOD: 22 TOTAL RULE RECORDS WRITTEN BY THE WLM COMPONENT: 508
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: *ALL Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 2 - PART 2 SYSPLEX: PRODPLEX SERVICE POLICY: WLMPROD POLICY EFFECTIVE: 04MAR1997:16:17:17 SERVICE COEFICIENTS: CPU=10.0 SRB=10.0 MSO=0.1 IOC=5.0 SERVICE CLASS PERIOD GOAL GOAL CPU CPU CLASS PERIOD DURATION GOAL TYPE IMPORTANCE GOAL PERCENT MIN MAX BATCHHI 1 EX. VELOCITY 2 50% BATCHLOW 1 EX. VELOCITY 4 10% BATCHMED 1 EX. VELOCITY 3 30% CICS 1 % RESPONSE 2 0.600 80 CICSALL 1 AVG RESPONSE 2 0.600 CICSCONV 1 % RESPONSE 3 0:01.0 90 CICSCPSM 1 % RESPONSE 3 0:01.0 90 CICSDEFA 1 % RESPONSE 3 0:01.0 90 CICSLONG 1 % RESPONSE 3 0:01.0 90 CICSMISC 1 % RESPONSE 3 0:01.0 90 CICSRGN 1 EX. VELOCITY *** 2(2) 60% CICSSERV 1 % RESPONSE 3 0:01.0 90 CICSTAU 1 % RESPONSE 2 0.600 80 DB2HIGH 1 EX. VELOCITY 2 50% DISCR 1 DISCRETIONARY 6 IMS 1 EX. VELOCITY 2 50% IMSHIGH 1 EX. VELOCITY 2 60% IRLM 1 EX. VELOCITY 1 85% OMVS 1 3000 EX. VELOCITY 2 30% OMVS 2 5000 EX. VELOCITY 3 20% OMVS 3 EX. VELOCITY 5 10% OMVSKERN 1 EX. VELOCITY 1 40% SYSOTHER 1 DEFAULT CLASS 6 SYSSTC 1 SYSTEM TASKS *** 0(3) SYSTEM 1 SYSTEM TASKS 0 TPNS 1 EX. VELOCITY 2 70% TSO 1 AVG RESPONSE 2 0:02.0 TSOHIGH 1 AVG RESPONSE 1 0.500 The above may not be the complete definition of Service Policy WLMPROD. If no address spaces were active in a service class, SMF Type 72 information may not be available for the service class. Consequently, CPExpert would be unable to determine the service class parameters. Please note that service classes which have '***' by their goal type are uniquely handled by the Workload Manager. The resources assigned to these service classes are dependent upon whether the transactions served are meeting their service goals. The Goal and Goal Importance specified for these SERVER classes normally are used by the Workload Manager only during address space start-up. The highest importance of any served service class is shown in parentheses after the importance of the server. The above policy is listed alphabetically. You can have the policy ordered by service class period importance by changing the POLORDER guidance variable.
WORKLOAD MANAGER ANALYSIS, Tue, Mar 4, 1997 - SYSTEM: *ALL Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 11 - PART 3 RULE WLM002: CONFLICT EXISTS BETWEEN SERVICE CLASS AND REPORT CLASS The Service Policy being analyzed (Policy WLMPROD) contains a Report Class which conflicts with a Service Class. This conflict could cause double accounting of system resources in reports which key off of the class name. This finding has no known effect on performance, but could have a HIGH IMPACT on accounting, billing, or capacity planning. The following Report Class conflicts with a Service Class of the same name: REPORT CLASS CICSCONV CICSCPSM CICSLONG CICSMISC CICSSERV CICSTAU OMVS RULE WLM005: VELOCITY GOAL MAY BE TOO HIGH FOR BATCH SERVICE CLASS CPExpert noticed that BATCHHI Service Class (Period 1) had an execution velocity goal of 50. The BATCHHI Service Class had the word "batch" in its Service Class Description. Consequently CPExpert assumes that the service class consists of batch jobs. Specifying a relatively high velocity goal of 50 for batch jobs may cause performance problems unless the batch jobs are well-behaved. Under some circumstances, this velocity goal could result in 50% of the system being used by batch workload. Please refer to Rule WLM005 in the WLM Component User Manual for a discussion of this issue. RULE WLM012: A SERVER DEFAULTED TO THE SYSSTC SERVICE CLASS CPExpert noticed that a "server" address space defaulted to the SYSSTC service class. Address spaces in the SYSSTC service execute at a very high dispatching priority (either 253 or 254, depending on whether APAR OW19265 has been applied). Performance of other service classes could be significantly degraded during start-up of the server service class, as a relatively large amount of CPU time could be used at a high dispatching priority. A server address space (a CICS region, IMS region, etc.) normally should be explicitly assigned to a service class.
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: S10 Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 12 - PART 5 RULE WLM103: SERVICE CLASS DID NOT ACHIEVE VELOCITY GOAL DB2HIGH (Period 1): Service class did not achieve its velocity goal during the measurement intervals shown below. The velocity goal was 50% execution velocity, with an importance level of 2. The '% USING' and '%TOTAL DELAY' percentages are computed as a function of the average address space ACTIVE time. The 'PRIMARY,SECONDARY CAUSES OF DELAY' are computed as a function of the execution delay samples on the local system. ------LOCAL SYSTEM-------- % % TOTAL EXEC PERF PLEX PRIMARY,SECOND MEASUREMENT INTERVAL USING DELAY VELOC INDX PI CAUSES OF DELAY 11:00-11:15,06MAR1997 45.2 54.8 45% 1.11 1.04 DASD DELAY(88%) RULE WLM361: NON-PAGING DASD I/O ACTIVITY CAUSED SIGNIFICANT DELAYS DB2HIGH (Period 1): A significant part of the delay to the service class can be attributed to non-paging DASD I/O delay. The below data shows intervals when non-paging DASD delay caused DB2HIGH to miss its performance goal: AVG DASD AVG DASD --AVERAGE DASD I/O TIMES- MEASUREMENT INTERVAL I/O RATE USING/SEC RESP WAIT DISC CONN 11:00-11:15,06MAR1997 24 0.040 0.002 0.000 0.000 0.001
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: S10 Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 13 - PART 5 RULE WLM101: SERVICE CLASS DID NOT ACHIEVE AVERAGE RESPONSE GOAL TSO (Period 1): Service class did not achieve its response goal during the measurement intervals shown below. The response goal was 2.000 second average response, with an importance level of 2. The percentages with the primary/secondary causes of delay are computed as a function of the average address space EXECUTING time on the local system. -----LOCAL SYSTEM----- TOTAL AVERAGE PERF PLEX PRIMARY,SECONDARY MEASUREMENT INTERVAL TRANS RESPONSE INDX PI CAUSES OF DELAY 10:45-11:00,06MAR1997 199 2.399 1.20 1.00 UNKNOWN(60%),DENIED CPU(11%) RULE WLM106: RESPONSE TIME DISTRIBUTION FOR SERVICE CLASS TSO (Period 1): Service class did not achieve its average response goal during the measurement intervals shown below. The response goal was 2.000 second average response. Average response can be misleading, since extremes can skew the average. The below information shows the distribution of response times: --PERCENT COMPLETIONS RELATIVE TO GOAL-- 50- 90- 100- 110- 200- TOTAL <50% 9O% 100% 110% 200% 400% >400% MEASUREMENT INTERVAL TRANS GOAL GOAL GOAL GOAL GOAL GOAL GOAL 10:45-11:00,06MAR1997 199 93.5 2.0 0.0 0.5 0.5 1.0 2.5 RULE WLM140: SYSPLEX PERFORMANCE INDEX WAS SIGNIFICANTLY LESS THAN LOCAL TSO (Period 1): The sysplex performance index for this service class period was significantly less than the local performance index. One implication of this is that the Workload Manager might not attempt to improve performance of the service class period on the local system. Please refer to the WLM Component User Manual for a discussion of how the sysplex performance index and local performance index are used by the Workload Manager. This finding applies to the following measurement intervals: PERFORMANCE INDEX MEASUREMENT INTERVAL LOCAL SYSPLEX 10:45-11:00,06MAR1997 1.20 1.00 RULE WLM250: SERVICE CLASS WAITED FOR ACCESS TO CPU TSO (Period 1): Service class was delayed waiting for access to a CPU. During the following RMF measurement intervals, a TCB or SRB was waiting to be dispatched, or a TCB was waiting for a local lock. The "% DENIED CPU" value represents the percent of TSO's EXECUTING time when TSO was waiting for access to a CPU. CPExpert will produce a report at the end of this analysis which shows the CPU time used by all service class periods. % CPU TIME USED BY OTHER CPU USED DENIED ---LEVELS OF IMPORTANCE--- MEASUREMENT INTERVAL (TSO -- 1) CPU HIGHER SAME LOWER 10:45-11:00,06MAR1997 0:00:08 11.5 0:04:02 0:35:43 0:05:19 RULE WLM251: DISPATCHER REDUCED PREEMPTION MIGHT HAVE CAUSED CPU DELAY TSO (Period 1): As shown above, the service class was delayed waiting for access to a CPU. However, the service class period used only a small amount of CPU resources, a relatively small amount of CPU was used by service class periods at a higher importance, and a relatively large amount of CPU time was used by service class periods at the same importance or lower importance. Consequently, CPExpert believes that the CPU delay may have been a natural result of the MVS Dispatcher Reduced Preemption algorithm. Please refer to the WLM Component User Manual for a discussion of this finding. RULE WLM362: NON-PAGING DASD I/O ACTIVITY CAUSED SIGNIFICANT DELAYS TSO (Period 1): A significant part of the delay to the service class can be attributed to non-paging DASD I/O delay. The below data shows intervals when non-paging DASD delay caused TSO to miss its performance goal: AVERAGE DASD I/0 TOTAL DASD ---AVERAGE DASD I/O TIMES-- MEASUREMENT INTERVAL PER TRANS TIME/TRANS RESP DISC CONN PEND 10:45-11:00,06MAR1997 55 .635 0.012 0.005 0.002 0.005 RULE WLM363: NON-PAGING DASD WAIT TIME WAS A MAJOR CAUSE OF DASD DELAYS TSO: A major part of the DASD I/O delay to the service class is attributed to non-paging DASD wait (DASD PEND time and control unit queue time). Please refer to the WLM Component User Manual for advice on how to minimize DASD wait time.
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: S10 Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 15 - PART 5 RULE WLM632: AN INBOUND PATH WAS NON-OPERATIONAL The C586 inbound path was non-operational during the following RMF measurement intervals. The path was defined to XCF, but the path was not usable. A path is not usable by XCF because of hardware problems, or because the path on the other end (the outbound path of another system) was not defined or was not defined correctly. MEASUREMENT INTERVAL 10:45-11:00,06MAR1997 11:00-11:15,06MAR1997 RULE WLM633: AN OUTBOUND PATH WAS NON-OPERATIONAL The C580 outbound path assigned to the DEFSMALL Transport Class was non-operational during the following RMF measurement intervals. The path was defined to XCF, but the path was not usable. A path is not usable by XCF because of hardware problems, or because the path on the other end (the inbound path of another system) was not defined or was not defined correctly. MEASUREMENT INTERVAL 10:45-11:00,06MAR1997 11:00-11:15,06MAR1997 RULE WLM661: SERVICE TIME WAS HIGH FOR ASYNCHRONOUS REQUESTS DSNDB1G_GBP0: The service time for this structure has exceeded the guidelines for asynchronous requests. Service time is accumulated from the time MVS issues a command for the coupling facility until the return from the command is recognized by MVS. Service time is recorded for each structure used by each system. You can alter the times used by CPExpert in making this finding by altering the ASYNCSRV guidance variables in USOURCE(WLMGUIDE) if you are unable to make changes to reduce service time for the structure. TOTAL ASYNC AVERAGE SERVICE MEASUREMENT INTERVAL REQUESTS TIME (MILLISECONDS) 10:45-11:00,06MAR1997 6 5.38 RULE WLM661: SERVICE TIME WAS HIGH FOR ASYNCHRONOUS REQUESTS DSNDB1G_GBP3: The service time for this structure has exceeded the guidelines for asynchronous requests. Service time is accumulated from the time MVS issues a command for the coupling facility until the return from the command is recognized by MVS. Service time is recorded for each structure used by each system. You can alter the times used by CPExpert in making this finding by altering the ASYNCSRV guidance variables in USOURCE(WLMGUIDE) if you are unable to make changes to reduce service time for the structure. TOTAL ASYNC AVERAGE SERVICE MEASUREMENT INTERVAL REQUESTS TIME (MILLISECONDS) 10:45-11:00,06MAR1997 10 9.81 RULE WLM651: LOCK CONTENTION WAS HIGH DSNDB1G_LOCK1: The lock contention for this structure was higher than normal. Higher lock contention can result in an increase in central processor utilization and a reduction in throughput. If this finding continues to occur, you should review the alternatives listed in the WLM Component User Manual. If you are unable to take action, you should consider increasing the LOCKCONT guidance variable, located in USOURCE(WLMGUIDE). The LOCKCONT variable currently is 2%. TOTAL LOCK REQUESTS WITH PERCENT LOCK MEASUREMENT INTERVAL REQUESTS LOCK CONTENTION CONTENTION 10:45-11:00,06MAR1997 2,112 405 19 11:00-11:15,06MAR1997 175,325 10,028 6 RULE WLM660: SERVICE TIME WAS HIGH FOR SYNCHRONOUS REQUESTS DSNDB1G_SCA: The service time for this structure has exceeded the guidelines for synchronous requests. Service time is accumulated from the time MVS issues a command for the coupling facility until the return from the command is recognized by MVS. Service time is recorded for each structure used by each system. You can alter the times used by CPExpert in making this finding by altering the SYNCSRV guidance variables in USOURCE(WLMGUIDE) if you are unable to make changes to reduce service time for the structure. TOTAL SYNC AVERAGE SERVICE MEASUREMENT INTERVAL REQUESTS TIME (MICROSECONDS) 10:45-11:00,06MAR1997 198 538 11:00-11:15,06MAR1997 208 369 RULE WLM660: SERVICE TIME WAS HIGH FOR SYNCHRONOUS REQUESTS ISGLOCK: The service time for this structure has exceeded the guidelines for synchronous requests. Service time is accumulated from the time MVS issues a command for the coupling facility until the return from the command is recognized by MVS. Service time is recorded for each structure used by each system. You can alter the times used by CPExpert in making this finding by altering the SYNCSRV guidance variables in USOURCE(WLMGUIDE) if you are unable to make changes to reduce service time for the structure. TOTAL SYNC AVERAGE SERVICE MEASUREMENT INTERVAL REQUESTS TIME (MICROSECONDS) 10:45-11:00,06MAR1997 2,359 8,140 RULE WLM660: SERVICE TIME WAS HIGH FOR SYNCHRONOUS REQUESTS ISTGENERIC: The service time for this structure has exceeded the guidelines for synchronous requests. Service time is accumulated from the time MVS issues a command for the coupling facility until the return from the command is recognized by MVS. Service time is recorded for each structure used by each system. You can alter the times used by CPExpert in making this finding by altering the SYNCSRV guidance variables in USOURCE(WLMGUIDE) if you are unable to make changes to reduce service time for the structure. TOTAL SYNC AVERAGE SERVICE MEASUREMENT INTERVAL REQUESTS TIME (MICROSECONDS) 10:45-11:00,06MAR1997 4,139 375
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: S20 Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 23 - PART 5 RULE WLM105: SERVICE CLASS DID NOT ACHIEVE PERCENTILE RESPONSE GOAL CICS: Service class did not achieve its response goal during the measurement intervals shown below. The response goal was 80.00 percent of the transactions completing within 0.600 seconds, with an importance level of 2. CICS was defined as a "served" Service Class (e.g., IMS or CICS transactions). The below causes of delay were based upon local Execution Phase samples. CICS was served by CICSRGN -------LOCAL SYSTEM-------- TRANS % TOTAL MEETING MEETING PERF PLEX PRIMARY,SECOND MEASUREMENT INTERVAL TRANS GOAL GOAL INDX PI CAUSE OF DELAY 11:00-11:15,06MAR1997 26,533 16,458 62.0 4.00 0.60 READY(35%),ACTIVE(31%) RULE WLM109: RESPONSE TIME DISTRIBUTION FOR SERVICE CLASS CICS: Service class did not achieve its response goal during the measurement intervals shown below. The response goal was 80.00 percent of the transactions completing within 0.600 seconds. The below information shows the distribution of response times: --PERCENT COMPLETIONS RELATIVE TO GOAL-- 50- 90- 100- 110- 200- TOTAL <50% 9O% 100% 110% 200% 400% >400% MEASUREMENT INTERVAL TRANS GOAL GOAL GOAL GOAL GOAL GOAL GOAL 11:00-11:15,06MAR1997 26,533 53.8 7.3 1.0 0.7 4.3 7.1 25.9 RULE WLM140: SYSPLEX PERFORMANCE INDEX WAS SIGNIFICANTLY LESS THAN LOCAL CICS (Period 1): The sysplex performance index for this service class period was significantly less than the local performance index. One implication of this is that the Workload Manager might not attempt to improve performance of the service class period on the local system. Please refer to the WLM Component User Manual for a discussion of how the sysplex performance index and local performance index are used by the Workload Manager. This finding applies to the following measurement intervals: PERFORMANCE INDEX MEASUREMENT INTERVAL LOCAL SYSPLEX 11:00-11:15,06MAR1997 4.00 0.60 RULE WLM151: SERVER SERVICE CLASS DELAYS CICS: This service class was served by the CICSRGN Service Class. The CICSRGN Service Class experienced the following delays in measurement intervals when the CICS Service Class missed its performance goal (the delays are shown relative to the EXECUTING time of CICSRGN). CICSRGN also served other service classes. The "PCT SERVED" column reflects the percent of service provided by CICSRGN to CICS, relative to the total service provided by CICSRGN to all service classes served by CICSRGN. PCT PCT ---PERCENT CPU--- PAGING I/O UNKNOWN PCT MEASUREMENT INTERVAL USING DELAY CAP WAIT WAIT WAIT SERVED 11:00-11:15,06MAR1997 18.5 77.8 0.0 0.0 0.5 0.1 24.2 RULE WLM152: SERVER SERVED MULTIPLE TRANSACTION SERVICE CLASSES CICSRGN: Service class served multiple transaction service classes during the intervals when CICS missed its performance goal. Consequently, CPExpert must analyze the delays for each transaction service class separately, and must apportion the resources used by CICSRGN based on the number of times CICSRGN served each transaction service class. The below information shows how often CICSRGN provided service to different transaction service class during intervals in which at least one of the transaction service classes missed its performance goal. TRANSACTION MISSED PERCENT MEASUREMENT INTERVAL SERVICE CLASS GOAL ? SERVICE 10:45-11:00,06MAR1997 CICS NO 5.6 10:45-11:00,06MAR1997 CICSCONV YES 2.6 10:45-11:00,06MAR1997 CICSCPSM NO 6.5 10:45-11:00,06MAR1997 CICSDEFA NO 30.2 10:45-11:00,06MAR1997 CICSLONG NO 53.3 10:45-11:00,06MAR1997 CICSMISC NO 0.2 10:45-11:00,06MAR1997 CICSTAU NO 1.6 11:00-11:15,06MAR1997 CICS YES 24.2 11:00-11:15,06MAR1997 CICSCONV YES 1.5 11:00-11:15,06MAR1997 CICSCPSM NO 5.2 11:00-11:15,06MAR1997 CICSDEFA YES 24.9 11:00-11:15,06MAR1997 CICSLONG NO 42.8 11:00-11:15,06MAR1997 CICSMISC NO 0.1 11:00-11:15,06MAR1997 CICSTAU NO 1.3 RULE WLM255: SERVICE CLASS WAS ACTIVE/READY BUT SERVER WAS DENIED CPU CICS: During the above measurement intervals, the service class was in the ACTIVE STATE during a significant portion of its response time. However, at least one address space in the CICSRGN server was denied access to a CPU for a significant percent of this time. During the following RMF measurement intervals, CICSRGN had a TCB or SRB waiting to be dispatched, or a TCB was waiting for a local lock. The below information shows the CPU time used by CICSRGN during the measurement interval, and the "PERCENT DENIED CPU" value represents the percent of CICSRGN's EXECUTING time when at least one address space was waiting for access to a CPU. CPExpert will produce a report at the end of this analysis which shows the CPU time used by all service class periods. CPU TIME USED BY OTHER CPU USED % SERVER ---LEVELS OF IMPORTANCE--- MEASUREMENT INTERVAL BY SERVER DENIED CPU HIGHER SAME LOWER 11:00-11:15,06MAR1997 0:16:49 77.8 0:04:12 0:01:45 0:03:11 RULE WLM120: SIGNIFICANT TRANSACTION TIME WAS IN ACTIVE STATE CICS: A significant amount of the transaction response time for service class was spent in the Active State. For CICS transactions, this is the time accounted for by tasks executing in the CICS region. These tasks would be shown as "Running" by the CEMT INQUIRE TASK command. The fact that CICS reports "Active" state does not mean that the CICS programs are actually processing the transaction, however. MVS allocates CPU cycles based on dispatching priority, and the CICS region may be denied access to a CPU. CPExpert will analyze the CICS regions to determine whether the regions were denied access to a CPU.
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: S20 Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 26 - PART 5 RULE WLM121: SIGNIFICANT TRANSACTION TIME WAS IN READY STATE CICS: A significant amount of the transaction response time for the service class was spent in the Ready State. For CICS transactions, this is the time accounted for by tasks which were not executing in the CICS region, but which were ready to be dispatched. The tasks were not dispatched because CICS had given priority to another task. These Ready tasks would be shown as "Dispatchable" by the CEMT INQUIRE TASK command. If this finding is consistently made for an important service class, you may wish to consider (1) investigating the long-running tasks that ARE being dispatched, (2) adjusting the priority which CICS gives to tasks, (3) adding another CICS region to reduce the Ready time, (4) reviewing the performance goal for this service class, (5) evaluating the goals for other service classes executing on this system, or (6) adding CPU capacity to the system. RULE WLM133: SIGNIFICANT TRANSACTION TIME WAS SWITCHED IN SYSPLEX CICS: A significant amount of the transaction response time for the service class was spent switched to another MVS image in the sysplex. This finding was based on the Begin_to_End Phase samples. Please refer to the description of Rule WLM133 for a discussion of the implications of this finding on the analysis being done by CPExpert.
WORKLOAD MANAGER ANALYSIS, Thu, Mar 6, 1997 - SYSTEM: S10 Analyzed by Version 7.1.0 of CPExpert(tm) (C) Copyright 1997, Computer Management Sciences, Inc. PAGE: 85 - PART 6 SUMMARY OF SERVICE CLASS CPU TIME CAPTURED IN TYPE 72 RECORDS THE DENIED CPU PERCENT IS A FUNCTION OF THE SERVICE CLASS DELAY SAMPLES SERVICE CLASS GOAL % MEASUREMENT INTERVAL CLASS PERIOD GOAL TYPE IMPORT CPU USED CPU 06MAR1997:10:45:00 SYSTEM 1 SYSTEM TASKS 0 0:03:59.50 8.8 06MAR1997:10:45:00 IRLM 1 EX. VELOCITY 1 0:00:02.68 0.1 06MAR1997:10:45:00 CICSRGN 1 SERVER CLASS 2 0:22:07.29 48.9 06MAR1997:10:45:00 DB2HIGH 1 EX. VELOCITY 2 0:00:03.85 0.1 06MAR1997:10:45:00 IMS 1 EX. VELOCITY 2 0:01:50.88 4.1 06MAR1997:10:45:00 IMSHIGH 1 EX. VELOCITY 2 0:00:00.00 0.0 06MAR1997:10:45:00 TPNS 1 EX. VELOCITY 2 0:11:40.61 25.8 06MAR1997:10:45:00 TSO 1 AVG RESPONSE 2 0:00:08.49 0.3 MISSED GOAL: DENIED CPU(11%) 06MAR1997:10:45:00 SYSSTC 1 SERVER CLASS 3 0:05:18.56 11.7 TOTAL SERVICE CLASS CPU TIME CAPTURED IN TYPE 72 RECORDS: 0:45:11.87 SUMMARY OF SERVICE CLASS CPU TIME CAPTURED IN TYPE 72 RECORDS THE DENIED CPU PERCENT IS A FUNCTION OF THE SERVICE CLASS DELAY SAMPLES SERVICE CLASS GOAL % MEASUREMENT INTERVAL CLASS PERIOD GOAL TYPE IMPORT CPU USED CPU 06MAR1997:11:00:00 SYSTEM 1 SYSTEM TASKS 0 0:04:28.42 21.3 06MAR1997:11:00:00 IRLM 1 EX. VELOCITY 1 0:00:17.09 1.4 MISSED GOAL: DENIED CPU(100%) 06MAR1997:11:00:00 CICSRGN 1 SERVER CLASS 2 0:11:05.55 52.8 06MAR1997:11:00:00 DB2HIGH 1 EX. VELOCITY 2 0:00:35.97 2.9 MISSED GOAL: DENIED CPU(69%) 06MAR1997:11:00:00 IMS 1 EX. VELOCITY 2 0:00:16.55 1.3 MISSED GOAL: DENIED CPU(85%) 06MAR1997:11:00:00 IMSHIGH 1 EX. VELOCITY 2 0:00:00.00 0.0 06MAR1997:11:00:00 SYSSTC 1 SERVER CLASS 3 0:04:16.63 20.4 TOTAL SERVICE CLASS CPU TIME CAPTURED IN TYPE 72 RECORDS: 0:21:00.22 Please note that the above distribution of CPU time includes CPU time associated with SERVER service classes. The Goal Importance of the SERVER service classes normally is ignored by the Workload Manager after address space start-up. The importance of the SERVER service classes is a function of the transaction service classes being served. Consequently, the SERVER Goal Importance may be misleading, as the CPU time shown for SERVER service classes may be at a higher or lower importance than that specified for the SERVER service class. The Goal Importance shown is the highest Goal Importance of any transaction service class processed by the SERVER on this system.

Return to main page

Last updated by Don Deese on 10/27/03.