Resource Demand Distribution


The Resource Demand Distribution report summarizes the use of CPU and I/O resources by the task execution and file access activities in the measured job step, and shows a chronological record of activity during the measurement session. All percentages of resource use are based on the total run time.

By default, the report limits the number of task entries to six and the number of file access activities to eleven. If there are more than six active tasks or eleven active files, the report groups the least active in an entry labeled .OTHER. It also combines file access operations that Strobe cannot attribute to a specific file access activity (such as open and close activities) in a separate entry labeled . FILEMGT. If their collective activity is low, the report includes them in the .OTHER line entry instead. If you requested that Strobe combine tasks when creating the Performance Profile by specifying the NOTASK parameter, the Resource Demand Distribution report contains a single line showing the combined time distribution of all tasks. If ALLDD was specified, the report lists all ddnames in which Strobe detected activity.

Tip

Analysis tips:

Analyzing the Resource Demand Distribution Report

If most of the wait time is attributed to files, examine the Data Set Characteristics report for buffers, block sizes, CI/CA splits and the EXCP count.

If most of the wait time is attributed to .FILEMGT, look at:

  • the Wait Time by Module report to get the function description of the modules in which the wait state began
  • the Attribution of CPU Wait Time report to see which transactions and modules invoked the functions associated with the wait time (for example, which transactions and modules open and close files).

Use the Distribution of activity over run time graph to understand when tasks and files were busy:

  • Vertical blank spaces on this report may be due to wait time for tape mounts. Look at the Wait Time by Module report to see if there is wait in tape activities (End of Volume, Open, Close, and so on). Also look at the I/O Facility Usage report to see which file the wait is associated with. Additional tape drives might help reduce this time.
  • If the report shows two or more files to be busy simultaneously, check the Resource Demand Distribution report to see if they are causing wait. If they are, check the I/O Facility Usage report to see if these files are on the same pack. If these conditions are true and if the files are accessed sequentially, consider moving one or more of the data sets to a different pack to eliminate this contention.

Report details

  • Task or DDNAME shows the task name or data definition name (DDNAME) of each active task and data set encountered during the measurement session. Tasks are identified by the name of the module in which execution was initiated, or by the name specified in the invocation of an ATTACH macro.

When there is a task of .FILEMGT and the Causing CPU wait column shows a wait time greater than 0, a link is provided to the Wait Time by Module report so you can determine what is causing the CPU wait time. Refer to the FILEMGT help topic for more information.

When a load module supports more than one task, the report shows, along with module name, a number that corresponds to a unique task control block (TCB) address. For example, at the first occurrence of a load module that is executed in multiple tasks, Strobe assigns the module name: LOADMOD 1, with the 1 being the unique identifying number. At the second occurrence of the same load module, Strobe assigns LOADMOD 2. At the third occurrence of the same load module, Strobe assigns LOADMOD 3. The unique identifier differentiates the instances that the load module occurs. If the load module executes only once, Strobe does not associate a number with the load module's name.

  • Resource shows the following:
    • For file access activities, the model number of the I/O device that serviced each task. If the model is not available, the following device types appear:

      C

      Communication

      DA

      Direct access

      G

      Graphic

      MT

      Magnetic tape

      UR

      Unit record

    • For CPU activities, Resource is CPU.
    • For activity in I/O services routines, Resource is I/O.
    • For files processed by the BatchPipes subsystem, Resource is B_PIPES.
  • Percent of Run Time Serviced by CPU: the percentage of run time spent by a CPU in servicing or performing the activity. For more information, see Percent-of-Run-Time-Serviced-by-CPU.
  • Percent of Run Time Serviced by I/O: the percentage of run time spent by I/O facilities in servicing the activity. For more information, see Percent-of-Run-Time-Serviced-by-I-O.
  • Percent of Run Time Serviced by Either: the percentage of run time in which either CPU or I/O facilities were servicing the activity.
  • Percent of Run Time Spent in Solo CPU: the percentage of run time during which a CPU was servicing the activity and no file access activity was occurring.

    • For a task execution activity, the time during which the task was being executed and no other activity was taking plac High CPU solo time represents a performance improvement opportunity.
    • For a file access activity, the time during which a CPU was executing file management routines for the activity, and no CPU or I/O facility was servicing any other activity within the address spac
  • Percent of Run Time Spent in Solo I/O: the percentage of run time spent by the I/O facility in servicing the file access activity, during which no I/O facility or CPU was servicing any other activity within the address space. The report further subdivides solo I/O facility use of each file access activity by unit and volume in the I/O Facility Usage report. For a task execution activity, the I/O solo time is always zero. High I/O solo time represents a performance improvement opportunity.
  • Percent of Run Time Spent in Solo Either: the percentage of run time during which one activity alone was being serviced for the measured job step, whether the servicing was by CPU, an I/O facility, or both.
  • Percent of Run Time Causing CPU Wait: the percentage of run time during which execution was delayed pending the occurrence of an awaited event, usually an I/O completion event. For more information, see Percent-of-Run-Time-Causing-CPU-Wait.
  • Distribution of Activity Over Run Time: a chronological record of the activity level of the program or subsystem and file access activities. For more information, see Distribution of Activity Over Run Time.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*