System Use Reporting › Interpreting Reports › System Use Report Interpretation

System Use Report Interpretation

The majority of the System Use Reports display an estimate of the level of utilization of system resources during specific intervals of time. These time intervals are user-specified and may be as small as a minute or, in the case of a utilization summary, as long as a shift or day. Generally, these utilization levels are displayed as a percentage of the time interval length, or of some maximum value, user-defined or defaulted.

The utilization data contained in the step and/or job level account records when sorted into chronological sequence, provides the basic information from which the majority of the System Use Report statistics are derived. Since the time intervals over which this data was collected rarely coincides with the specified report time intervals, a prorating or apportioning technique is used to assign utilization estimates to each report time interval from the available step or job level data. By necessity, the technique used assumes that the rate of utilization of each resource, such as CPU time, or an I/O device, for example, was consistent during the duration of the step or job. Since this is occasionally not the case, the specification of a report time interval length which is not less than the average step or job elapsed time (from the Computer Utilization Summary Report) is recommended.

Care must be taken when attempting to compare statistics from one System Use Report to another. To provide the most information possible in the smallest series of reports, each report is designed to provide either different information or information from a slightly different point of view than other reports. What most often leads to an apparent contradiction is an attempt to compare statistics between two reports which base their utilization percentages on different interpretations of real time, primarily either measured time or defined time.

Defined time is the accumulation of the amounts of time in each specified report time interval, shift, or logical day. Measured time is the accumulation of periods of elapsed time commencing with the beginning of the earliest occurrence of recorded activity and terminating with the end of the latest recorded activity within each defined shift or day. A recorded activity is either a step or job execution or the accounting of a wait-time interval (type 70 SMF records). Only when a recorded activity crosses the beginning and end of a defined shift or day is measured time the same as defined time.

Because of the periodic recording of system wait or idle time in z/OS, differences between measured and defined time can normally be attributed to gaps between system shutdown and re-IPL, the loss of SMF data due to a system failure, or simply the absence of any SMF data for portions of a defined shift or day because of the times of day when the SMF collection data sets were dumped.

On each type of report, Time of Measurement identifies the beginning and ending of the measured time period for that report, Total Includes identifies the beginning and ending dates of the defined time period, and the body of the report defines the beginning and ending times of the defined time period. Note that when a report is a summary type covering more than one day, there may be gaps in measured time such that the accumulated measured time is less than the difference between the end of the last measured time period and the beginning of the first.

Note that the System Use Reports were originally designed for data covering a relatively short period of real time; that is, a day or a week. The internal accumulation of data may experience overflows when the amount of data processed exceeds design limits. In general, the accumulation for queue and turnaround times used in the production of the Computer Utilization Summary report are subject to overflows when the amount of time being accumulated exceeds approximately 65,000 hours. In addition, the accumulation of service units overflows if the amount being accumulated exceeds approximately 2,000,000,000.

Considerations

• The only meaningful inputs to System Use Reports are SMF/TSO records or a history file created from SMF/TSO input (level 6 or 7). When processing a level 6 history file, you must code a J in position 11 of the SYSUSE1 statement.
• All numeric data is handled as binary full words. The times are carried in hundredths of seconds. This could result in truncation of data if bringing a large amount of very active data. There is no checking for overflow and this can cause problems.
• Prorating is done by:
  • multiplying the number, for example CPU time, by the defined time interval
  • dividing the result by the total elapsed time of the job or step

  The assumption, due to using batch data, is that CPU usage was the same during the entire length of the job.

• Prorating is done only for steps or jobs that span more than one interval.
• The shift and day flags on the SYSUSE1 statement can be used to select any or all:
  • shift oriented reports for each day
  • 24-hour reports for each day
  • shift oriented reports for all days combined
  • 24-hour reports for all days combined
• Page numbers start at 1 for each report.
• When reports for each day and for all days combined are generated, most of the core requirements are doubled.
• Numbers are all rounded by half-adding.
• Time of measurement dates and times are taken from the SMF run dates, not reader start date, for the records used in the reports requested. This means that the dates and times may vary depending upon the reports requested because not all the system type records are necessary for all the reports. If an asterisk appears in the dates, check:
  • PARMS statement positions 11-34
  • CRITERIA statement date
  • use of a summary level history file (level 1-5)
• Shift start times must always be larger than the preceding shift time. You cannot define first shift as 0700, second as 1400 and the third as 0000.
• When using a criteria date, IPL idle, overhead and wait times are from the criteria date to the next IPL. If an IPL record contains data from the time period prior to the criteria date, we prorate the information. This is done by adding like data together and dividing by 2. This may cause too little or too much time to be accounted for.
• System use or system related records are created for IPL idle time, SMF data lost and wait time. These records are less than 160 bytes in length and are retained on an account file and job step and job level history files. The format of the records is given in your Systems Programmer Guide.

The following table is designed to assist you in understanding the graphs presented later in this chapter.