SirTune reports

Overview

The SirTune reporting module produces a listing that is made up of one or more reports. These reports can be used to tune problem areas in an Online.

SIRTUNEREPORT replaces SIRTUNER

In SirTune versions prior to 7.2, reporting is done via SIRTUNER, an assembler module that is separately distributed and installed. In version 7.2 and later, reporting is done by SIRTUNEREPORT, a SOUL program that is distributed in the RKTools file SIRIUS (prior to version 7.7) or M204PROC file (as of RKTools 7.7).

SIRTUNER cannot be used with SirTune 7.2 and later. Conversely, the SIRTUNEREPORT program cannot be used with versions prior to 7.2 of the Sirius Mods, since it is based on the SirTuneReport method of the Dataset class, which was first implemented in version 7.2.

While it is possible to run SIRTUNEREPORT inside a Model 204 Online, it is strongly recommended that it be run in a standalone batch job, as it can consume considerable resources from an Online job. Or, RKTools version 7.7 users can run SIRTUNEREPORT from the RKWeb interface (Build > Tune Reports) and view the output in their browser.

If the SIRIUS or M204PROC file cannot be allocated to a batch job, SIRTUNEREPORT can be moved to another procedure file. To run SIRTUNEREPORT from another file:

1. Move SIRTUNEREPORT and the included procedure SHARED_REPORT to the new file.
2. Change the single reference to SIRIUS or M204PROC to the new file name (this reference is an Include statement near the top of the procedure, after the variable declarations).

SIRTUNER accepts report specifications in control-card format on the SIRTUNEI input DD card. SIRTUNEREPORT accepts report specifications either in control-card format or in XML format on the TUNERPTI input DD card.

Use REPORT or <report> to specify which reports to produce

If not suppressed with the REPORT NODEFAULT statement, the reporting module always produces a default set of reports. Additional reports are requested with the REPORT statement.

The default reports produced are identical to the reports you get with the following REPORT statements:

REPORT INFO REPORT SUMMARY REPORT STATE RUNG WHAT EVAL CHUNK 4000 REPORT STATE RUNG EVAL CHUNK 400 CHUNK 4

In XML format, these default reports are specified like this:

<SirtuneInput maxDelay="10" top="50"> <report type="info"/> <report type="state"/> <report type="waittype"/> <report type="what" state="rung"/> <report type="eval" state="rung"/> <report type="eval" state="rung" chunk="4000"/> <report type="eval" state="rung" chunk="400"/> <report type="eval" state="rung" chunk="4"/> </SirtuneInput>

Note: The XML equivalent to the REPORT SUMMARY control-card statement is two elements:

<report type="state"> <report type="waittype">

In addition to these, a variety of other reports can be produced upon request. These reports are requested via the REPORT statement (see example in Generating reports prior to Sirius Mods 7.2: MVS or Generating reports prior to Sirius Mods 7.2: CMS). The reports appear in the same order in the output (TUNERPTO) as they appear in the input (TUNERPTI).

Deciding which reports to produce

The main considerations to use in determining which reports to produce are (in descending order of importance):

• The completeness of the reports in pointing out problem areas.
• The ease with which the reports can be read.
• The CPU and storage costs of producing the reports.

Said another way, you should strive to get as much data as possible in a SirTune listing without increasing the number of reports to such an extent that the listing becomes unwieldy and overwhelming to work with.

In theory, you can suppress the INFO report, but there is no good reason to do it: The INFO report (one of the defaults) describes the Model 204 environment, and also the selection criteria for the report and the sampling characteristics of the SirTune data collection. Without this information, it is difficult to make sense of the specific performance reports.

Sample data set restrictions

• Due to format changes in the sample data set, only the SIRTUNEREPORT program can process a SirTune version 7.2 and later sample data set.
• Due to format changes in the sample data set, only releases 1.6 and later of SIRTUNER can process a SirTune version 7.0 and later sample data set.
• Due to format changes in the sample data set in SirTune version 1.5, earlier releases of SIRTUNER cannot process a SirTune 1.5 or higher sample data set.

The SirTune reports

In the individual Sirtune report descriptions in this page, optional parameters are listed in brackets ([]) and alternative parameters are separated by vertical bars (|).

INFO reports

Syntax:

REPORT INFO

The INFO report provides environmental information about the Model 204 Online program and SirTune data collection settings used in producing the sample data set. This report includes settings of key Model 204 parameters (NUSERS, NSERVS, NJBUFF, etc.) and SirTune parameters (sampling interval, COLLECT settings, etc.).

This is one of the default reports produced by SirTune. It is recommended that this report always be included in SirTune output, because it establishes the context of all other reports.

In addition to an environmental summary, the INFO report provides a summary of SirTune's data collection activity, which looks like this:

Sampling Rate = 10.00 seconds Number of samples processed = 13359 Number of samples missed = 0 Number of samples skipped = 13347 Number of samples discarded = 3 (MAXDELAY = 10) Number of samples accepted = 9 States collected = RUNG REDY BLKIN BLKON Extra data collected = DISKIO CFR Options = Job start time = Sunday, 23 October 2016 00:18:33 First sample processed = Monday, 24 October 2016 13:23:20 Last sample processed = Monday, 24 October 2016 13:25:10 SIRTUNE version = 8.3 SirTune stopped because End of data in sample dataset

Notes:

• The Sampling Rate times the Number of samples processed gives the overall time span of the journal.
• The Number of samples missed reflects the count of samples SirTune failed to collect.
• A non-zero Number of samples skipped is usually due to a specified time span being narrower than that represented in the full journal; the skipped samples are outside the selected date/time range.
• The Number of samples discarded reports samples discarded when more than MAXDELAY milliseconds pass between the time SirTune wanted to collect the sample and when it actually did. A significant number of discarded samples might indicate the Online is not getting the resources it needs — it certainly indicates that SirTune was not getting the resources it needed when it tried to take a sample.
• The rest of the report shows the user's data collection settings (useful if you request a report and find that the necessary data is not in the collection for that report), the journal's starting time, time brackets for this report, the SirTune version, and the reason data collection stopped (End of data in sample dataset indicates normal completion).

CFRROOT reports

Syntax:

REPORT CFRROOT

The CFRROOT report can be used to determine the root bottleneck behind critical file resource enqueuing. Since critical file resource enqueuing is never a bottleneck in itself but will exacerbate some other bottleneck, this report can be useful in determining what is actually behind most of the critical file resource enqueuing on a system.

Generally, one would expect disk I/O to be the root bottleneck behind critical file resource enqueuing. Unfortunately, this is also usually the most complex bottleneck to correct. If disk I/O shows up as the top root bottleneck on the CFRROOT report, the next step should probably be to look at the STATE CFRBxxx reports to try to locate the programs or statements that produce the disk I/O that results in critical file resource enqueuing. It might also be useful to look at STATE WDISK reports and DISKIO reports to get information on the cause of all waits for disk I/O.

Other than disk I/O, the most likely root causes of critical file resource enqueuing are:

Journal I/O	This cause might be reduced by placing the journal on a faster device (DASD fast write is especially helpful here) or by reducing the quantity of journal data being produced (REPORT STATE WJRNLO might help isolate code that is flooding the journal).
Checkpoint I/O	This cause might be reduced by placing the checkpoint dataset on a faster device (DASD fast write is especially helpful here).
Arbitration	This shows up as ARBMO and is most likely caused by journal I/O or checkpoint I/O. A reasonable guess for which of these is the most likely culprit is provided by the positions of journal and checkpoint I/O in the CFRROOT report.
CPU	A CPU bottleneck can exacerbate the effect of I/O waits on critical file resource enqueuing. CPU tuning, processor upgrades and the MP/204 feature are all options in correcting CPU bottlenecks.
SERVER	A server bottleneck can exacerbate the effect of I/O waits and/or a CPU bottleneck on critical file resource enqueuing. In fact, a server bottleneck can interact with another I/O bottleneck and critical file resource enqueuing in a positive feedback loop that turns a minor bottleneck into a disastrous performance problem. While it is possible that increasing the number of servers might break this feedback loop it is more likely that attacking the I/O bottleneck will improve performance more, even if SERVER shows up at the top of the CFRROOT report.

If anything else appears as a significant root cause of critical file resource enqueuing, it is likely to indicate a severe but possibly easily correctable problem. For help diagnosing and correcting such a problem, contact Technical Support.

CSECT, CSECTM, and CSECTS reports

Syntax:

REPORT {CSECT | CSECTM | CSECTS} TOTAL | CHUNK ch_size

The CSECT, CSECTM, and CSECTS reports break down Model 204 CPU usage by CSECT. These reports are generally only of interest to Model 204 internals experts, though they might be of interest in sites that have extensive in-house $function libraries.

The CSECT report shows CPU usage by CSECT. When running the MP/204 feature, the CSECTM report shows maintask CPU usage by CSECT, and the CSECTS report shows subtask CPU usage by CSECT. If not running the MP/204 feature or running the feature with 0 subtasks, CSECT is equivalent to CSECTM, and CSECTS is always 0.

Note: If using XML for the parameters (Using XML input for report configuration), a single convention can handle these different CSECT report variations: specify a "task=maintask" or "task=subtask" attribute for a "type=csect" report to invoke, repectively, a CSECTM or a CSECTS report.

For example, to get a CSECTM report:

<report type="csect" task="maintask">

The CSECT|M|S reports are further qualified by a TOTAL or CHUNK keyword:

• TOTAL requests a breakdown of CPU usage by whole CSECTs. For example, to produce a breakdown of CPU usage where each entry in the report is an entire CSECT, you use:

  REPORT CSECT TOTAL

  Since TOTAL is the default, a REPORT CSECT statement is equivalent to REPORT CSECT TOTAL.

  If using XML in the report configuration input, REPORT CSECT TOTAL is equivalent to <report type="csect" chunk="total"/>.

• CHUNK request a breakdown of CPU usage by pieces of each CSECT. The size of each piece or chunk is ch_size bytes of object code. Thus to get a breakdown of CPU usage by 128-byte chunks of object code, specify the following in SIRTUNEI:

  REPORT CSECT CHUNK 128

You can specify multiple breakdown types on a single REPORT CSECT statement. For example, this statement requests a breakdown of CPU usage by entire CSECTs, by chunks of 512 bytes, and by chunks of 64 bytes:

REPORT CSECT TOTAL CHUNK 512 CHUNK 64

Note: You can use the MAPCORE statement in the report configuration input to specify that instructions outside of the loaded Model 204 module are to be treated as a "CSECT," allowing analysis of CPU usage in the entire address space.

DISKIO reports

Syntax:

REPORT DISKIO TOTAL | TABLE | CHUNK ch_size

The DISKIO report provides a breakdown of waits on Model 204 disk I/O (database I/O). The breakdowns available are:

TOTAL	This breaks down waits on Model 204 disk I/O by database file. This is useful for determining which files have the heaviest I/O activity.
TABLE	This breaks down waits on Model 204 disk I/O by tables within each database file. The seven database file tables are the FCT, Table A, Table B, Table C, Table D, Table E, and Table X. This breakdown is useful for determining if it is worth tuning the use of specific tables in the database files.
CHUNK	This breaks down waits on Model 204 disk I/O by groups or chunks of a specific number (ch_size) of pages within each file table. This can be particularly useful in isolating device performance or contention problems that affect part of a table that resides on multiple disks. In addition, it can be useful in isolating "hot" areas of activity that might benefit from being placed on a cached or faster DASD. This breakdown is generally only useful when using extremely large tables. Even in these cases, it is recommended that ch_size be set to a large value (>1000) to produce meaningful results.

To produce the DISKIO reports, you must specify this COLLECT statement in the SirTune data collection input stream (SIRTUNEI):

COLLECT DISKIO

• To produce a report breaking down waits on disk I/O by files, specify the following in SIRTUNEI:

  REPORT DISKIO TOTAL

• To produce a report breaking down waits on disk I/O by tables within files, specify the following in SIRTUNEI:

  REPORT DISKIO TABLE

• To produce a report breaking down waits on disk I/O by chunks of 10000 pages within each table within files, specify the following in SIRTUNEI:

  REPORT DISKIO CHUNK 10000

Multiple breakdown types can be specified on a single REPORT DISKIO statement. For example, the following SIRTUNEI specification requests reports breaking down waits on Model 204 disk I/O by file, tables within file, and chunks of 5000 pages within tables:

REPORT DISKIO TOTAL TABLE CHUNK 5000

QUADC, QUADCM, and QUADCS reports

Syntax:

REPORT {QUADC | QUADCM | QUADCS} TOTAL | CHUNK ch_size

The QUADC, QUADCM, and QUADCS reports break down Model 204 CPU usage by quad and CSECT. These reports are generally only of interest to Model 204 internals experts, though they might be of interest in shops that have extensive in-house $function libraries.

The QUADC report breaks down all CPU usage by quad and the CSECTs. Since the breakdown is a CSECT-level breakdown, the MPVIRT configuration parameter has no effect on the QUADCM and QUADCS reports — only the real task on which a request was running is used to distinguish CSECTS and CSECTM.

When running the MP/204 feature, the QUADCM report shows maintask CPU usage by quad and CSECT, and the QUADCS report shows subtask CPU usage by quad and CSECT. If not running the MP/204 feature or running the feature with 0 subtasks, QUADC is equivalent to QUADCM, and QUADCS is always 0.

Note: If using XML for the parameters (Using XML input for report configuration), a single convention can handle these different QUADC report variations: specify a "task=maintask" or "task=subtask" attribute for a "type=quadc" report to invoke, repectively, a QUADCM or a QUADCS report.

For example, to get a QUADCM report:

<report type="quadc" task="maintask">

These quad reports are further qualified by a TOTAL or CHUNK keyword:

• TOTAL requests a breakdown of CPU usage by quads and entire CSECT. For example, to produce a breakdown of CPU usage where each entry in the report is an entire CSECT/quad combination, you use:

  REPORT QUADC TOTAL

  Since TOTAL is the default, a REPORT QUADC statement is equivalent to REPORT QUADC TOTAL.

  If using XML in the report configuration input, REPORT QUADC TOTAL is equivalent to <report type="quadc" chunk="total"/>.

• CHUNK requests a breakdown of CPU usage by pieces of each CSECT for each quad. The size of each piece or chunk is ch_size bytes of object code. Thus to get a breakdown of CPU usage by 128-byte chunks of object code, code the following in SIRTUNEI:

  REPORT QUADC CHUNK 128

You can specify multiple breakdown types on a single REPORT QUADC statement. For example, this statement requests a breakdown of CPU usage by entire CSECT/quad combination, and by CSECT chunks of 512 bytes, and by chunks of 64 bytes:

REPORT QUADC TOTAL CHUNK 512 CHUNK 64

Note: The MAPCORE statement in the report configuration input specifies that instructions outside of the loaded Model 204 module should be treated as a "CSECT," allowing analysis of CPU usage in the entire address space.

REPSTAT reports

Syntax:

REPORT REPSTAT [RESET]

The REPSTAT report provides information on the performance of the report generator itself.

The REPSTAT report breaks down the time for the report generation process into its individual components, CPU time, waiting for input buffer time, waiting for report buffer time, etc. In addition, the REPSTAT report provides information on above-the-line (31 bit) and below-the-line (24 bit) storage usage.

Note: This report is only of interest if the performance or storage usage of SIRTUNER is a concern. It is not supported in SirTune 7.2 and later (using the SIRTUNEREPORT SOUL program), and a repstat keyword is not supported as a report type option in the XML format for specifying report configuration parameters (A template for the XML input).

The RESET parameter requests that usage counters be reset after the REPSTAT report. This makes it easy to determine the cost of actually producing a particular report. For example, in the following sequence the counters reported in the second REPSTAT report will show the cost of producing the REPORT STATE RUNG CHUNK 100 report:

REPORT REPSTAT RESET REPORT STATE RUNG CHUNK 100 REPORT REPSTAT

Note that this report will not indicate the cost of actually collecting the data required by this report. This latter cost will often be significantly greater than the cost of actually generating the report.

When the REPSTAT report is used with the TWOPASS statement, the REPSTAT report shows results only in the second report-generation pass.

SERVIO reports

Syntax:

REPORT SERVIO

The SERVIO report provides a breakdown of waits on Model 204 server I/O by server data sets (CCASERVR, CCASERV1, etc.). This is useful in identifying server data sets on disks that are not performing well because of contention problems, hardware problems, or server data sets with an unusually low level of activity, perhaps because of under-allocated extents.

In general, ideal performance is achieved when all Model 204 server data sets show the same level of activity and response. Model 204's round robin, user-to-server, data set allocation scheme ensures this on a gross level. Disparities in number of users waiting on specific server data sets could be indicative of a problem.

SERVUSE reports

Syntax:

REPORT SERVUSE [CHUNK ch_size]

The SERVUSE report provides a breakdown of users in particular states by server size. This can be useful in determining optimal server size allocations. The states for which information is provided is a subset of all states described in SirTune user states.

Server sizes are grouped by chunk size (ch_size). The default for ch_size is 10000. This default results in 100 possible categories of server sizes between 0 and 1,000,000 bytes.

Groups with no observations are not displayed on the SERVUSE report.

The breakdowns are provided by the following states:

• REDYR

  Running or ready users.

  If state REDY was not collected, this is displayed as RUNG, meaning running users.
• SWPGI

  Users swapping into a server.

  If this state was not collected, it is not displayed on the SERVUSE report.
• OSERVW

  Users waiting on server or swapping out to wait for server.

  If neither state SWPGOW or WTSV was collected, this state is not listed on the SERVUSE report. If only one of these states was collected, the header appears as the collected state rather than as "OSERVW".

  This state is of particular interest in this report because it indicates the size of server that users required but were not able to get immediately. Thus, a large average for number-of-users in state OSERVW for server sizes 190000-199999 would indicate a requirement for more 200K servers.

• BLKIN

  Users blocked in server waiting on something other than user input.

  If this state was not collected, it is not displayed on the SERVUSE report.

• BLKIU

  Users blocked in server waiting on user input.

  If this state was not collected, it is not displayed on the SERVUSE report.

• OSERVN

  Users blocked out of server or swapping out to wait for something other than user input.

  If neither state BLKON or SWPGOBN was collected, this state is not listed on the SERVUSE report. If only one of these states was collected, the header appears as the collected state rather than "OSERVN."
• OSERVU

  Users blocked out of server or swapping out to wait for user input.

  If neither state BLKOU or SWPGOBU was collected, this state is not listed on the SERVUSE report. If only one of these states was collected, the header appears as the collected state rather than "OSERVU."

STATE reports

Syntax:

REPORT STATE state_name activity

The STATE report sorts users in a specified state (state_name) by their current processing activity (activity).

state_name can be any valid SirTune state, and the states are described in SirTune user states.

The activities are described below:

WHAT	By the generic activity groupings used by Model 204 in its "WHAT" flag settings. The most common of these activities is compiling, loading, and evaluating SOUL procedures.
COMP	By the name of the procedure(s) being compiled. Generally, this report is not of interest unless the WHAT report indicates a significant amount of resource usage in compilation.
LOAD	By the name of the precompiled APSY procedure(s) being loaded. Generally, this report is not of interest unless the WHAT report indicates a significant amount of resource usage in loading.
EVAL	By the name of the procedure(s) being evaluated. This report is useful in determining: Which procedures are worth looking at in more detail Whether any non-precompiled or non-APSY procedures are significant resource consumers. This is important because, unless the ALLCOMP option was specified for the data collection portion of SirTune, non-precompiled or non-APSY procedures will not show up on chunk reports.
EVALI	By the name of the innermost procedure(s) being evaluated. This report is useful in environments where the same procedures are INCLUDE'd in several different precompiled APSY procedures. By getting a state breakdown by EVALI, all resource usage that occurs while running an INCLUDE'd procedure gets assigned to the INCLUDE'd procedure. This makes it possible to determine the possible gains from tuning such a procedure.
QUAD	By the current Model 204 quad being evaluated. Quads are the internal representation of SOUL. Every SOUL statement maps to one or more quads. Each $function is considered a separate quad in this breakdown. While a breakdown by quad might generally only be of interest to a Model 204 internals expert, these breakdowns might provide some hints about overall application characteristics, even to programmers unfamiliar with Model 204 internals. The $function breakdown could be of particular interest in shops that have many and/or complex in-house $functions.
CHUNK ch_size	By pieces of evaluating procedures. Every SOUL procedure can be broken up into an arbitrary number of pieces. SirTune allows grouping lines of procedure in "chunks." A chunk is a group of lines in SOUL that are compiled to produce object code (quads) of a specific number of bytes. This number of bytes is known as the chunk size (ch_size). Thus REPORT STATE RUNG CHUNK 300 breaks up procedures into chunks that correspond to approximately 300 bytes of compiled code (quads). A user in a particular state while evaluating a procedure is always in exactly one chunk. A "chunk" report will present each chunk as the corresponding line numbers of the source procedure. Chunks can never cross INCLUDE statement boundaries. In addition, chunks can be terminated by the end of a procedure. For this reason, some chunks in a CHUNK report might actually be smaller than the chunk size specified. A chunk in a procedure will also generally be larger than the size specified on a RESOLUTION statement applicable to the procedure. Since different SOUL statements compile to different numbers of bytes, the actual size of the chunks will generally not be exactly the chunk size specified on the REPORT statement. For this reason, the actual size of each chunk is displayed on all CHUNK reports. Since the smallest possible SOUL chunk is 4 bytes, a chunk size of 1 is equivalent to a chunk size of 4 and a chunk size of 30 is equivalent to a chunk size of 32.
IFJOB	By originating IFAM2 jobname. This can be useful in determining which IFAM jobs are generating a lot of activity. This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFCOMP	By originating IFAM2 compilation name. Caution must be used in this report, because the same compilation name can be used by many different programs for many different purposes. This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFJCOMP	By originating IFAM2 compilation and jobname. This has an advantage over the IFCOMP report: it will not combine two identically named but different compilations for two different jobs. It has the disadvantage that if an identical compilation is used by two jobs, the totals for these compilations will not be combined. This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFFUNC	By IFAM2 function name (IFFIND, IFPUT, etc.). This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFCHUNK ch_size	By pieces of IFAM2 load modules. Every IFAM2 load module can be broken up into an arbitrary number of pieces. SirTune allows grouping bytes of code in "chunks." A chunk is a range of offsets in the load module of a specific number of bytes. This number of bytes is known as the chunk size (ch_size). Thus REPORT STATE RUNG IFCHUNK 256 breaks up load modules into chunks of 256 bytes. This report lists usage by IFAM2 load module name and offset within the load module. For this report to be useful, the offsets withing the load modules must be converted to offsets within specific CSECTs. This can be done use a load map for the load module. Offsets within CSECTs must then be converted to source statement offsets, using compiler listings if a higher level language was used to generate the CSECTs. This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report. This report will produce no useful data on CMS. Under MVS, the IFINTF object deck shipped in the SirTune object library must be linked with the IFAM2 load modules of interest for this report to produce useful information.

For example, to get a breakdown of running users by procedure being compiled, enter the following in SIRTUNEI or TUNERPTI:

REPORT STATE RUNG COMP

Or, using XML, specify this:

<report type="comp" state="rung">

Since a user is using CPU if and only if the user is running, that is, in state RUNG, this report gives an estimate of CPU usage by procedure being compiled.

To get a breakdown of swapping users by individual lines within a procedure, enter the following in SIRTUNEI or TUNERPTI:

REPORT STATE SWPG CHUNK 4

Since a chunk size of 4 is the smallest possible chunk size, this guarantees that no two lines of SOUL will be grouped together in the report. Note that to produce this report, data must be collected for state SWPG by SirTune. This would require a COLLECT statement in SIRTUNEI for SirTune.

To get a breakdown of users waiting for journal I/O by evaluating procedure, enter the following in SIRTUNEI or TUNERPTI:

REPORT STATE WJRIO EVAL

To produce this report, data must be collected for state BLKIN by SirTune.

It is possible to specify several breakdowns on a single REPORT STATE statement. For example:

REPORT STATE WDISK WHAT EVAL CHUNK 1000 REPORT STATE WDISK EVAL CHUNK 100 CHUNK 10

requests breakdown of users waiting for disk I/O by general activity category (WHAT), procedure being evaluated, and chunks of 1000, 100, and 10 in the procedures being evaluated.

SUMMARY reports

Syntax:

REPORT SUMMARY

The SUMMARY report provides a summary of the average number of users in each sample, broken down by user state and wait type.

If using XML to configure the report, the XML equivalent to a REPORT SUMMARY control-card statement is two elements:

<report type="state"> <report type="waittype">

This report is of particular interest in determining potential problem areas. For example, a large average for number of users in the WTSV (waiting for server) state might be indicative of a server shortage. And a large average for number of users waiting for checkpoint I/O might be indicative of problems with the checkpoint data set.

Use caution when interpreting this report, especially when making negative conclusions (that is, deciding that something is not a problem area). For example, if WTSV does not show up on this report, it could mean one of two things:

• There are never any users waiting for server.
• No COLLECT statements were coded to tell SirTune to collect data for users in state WTSV.

SYSPARM reports

Syntax:

REPORT SYSPARM

The SYSPARM report provides the values of all system and scheduler parameters in the Online associated with the sample dataset. This report provides identical output to a VIEW SYSTEM CWAIT command issued in the Online associated with the sample dataset.

This report is only available in the SirTune report writer versions 1.6 and later. In addition, the data presented by this report is only provided in sample data sets collected with the SirTune data collecter version 7.0 and later. For sample data sets created with earlier SirTune data collectors, the SYSPARM report will be empty.

While this is not one of the default reports produced by the report generator, it is recommended that this report always be included in report output, because it provides information about system settings that might prove useful in interpreting the other reports.

WHATC, WHATCM, and WHATCS reports

Syntax:

REPORT {WHATC | WHATCM | WHATCS} TOTAL | CHUNK ch_size

The WHATC, WHATCM, and WHATCS reports break down Model 204 CPU usage by Model 204 "activity" and CSECT. The most common Model 204 activities are evaluating and compiling. These reports are generally only of interest to Model 204 internals experts, though they might be of interest in shops that have extensive in-house $function libraries.

The WHATC report breaks down all CPU usage by Model 204 activity and CSECTs. Since the breakdown is a CSECT-level breakdown, the setting of the MPVIRT parameter (MPVirt) has no effect on the WHATCM and WHATCS reports — only the real task on which a request was running is used to distinguish CSECTS and CSECTM.

When running the MP/204 feature, the WHATCM report breaks down maintask CPU usage by activity and CSECT, and the WHATCS report breaks down subtask CPU usage by activity and CSECT. If not running the MP/204 feature or running the feature with 0 subtasks, WHATC is equivalent to WHATCM, and WHATCS is always 0.

Note: If using XML for the parameters (Using XML input for report configuration), a single convention can handle these different WHATC report variations: specify a task=maintask or task=subtask attribute for a type=whatc report to invoke, repectively, a WHATCM or a WHATCS report.

For example, to get a WHATCS report:

<report type="whatc" task="subtask">

WHATC, WHATCM, and WHATCS reports are further qualified by the TOTAL or CHUNK keyword:

• TOTAL requests a breakdown of CPU usage by Model 204 activities and entire CSECT. For example, to produce a breakdown of CPU usage where each entry in the report is an entire CSECT/Model 204 activity combination, you use:

  REPORT WHATC TOTAL

  Since TOTAL is the default, a REPORT WHATC statement is equivalent to REPORT WHATC TOTAL.

  If using XML in the report configuration input, REPORT WHATC TOTAL is equivalent to <report type="whatc" chunk="total"/>.

• CHUNK requests a breakdown of CPU usage by pieces of each CSECT for each Model 204 activity. The size of each piece or chunk is ch_size bytes of object code. Thus to get a breakdown of CPU usage by 128-byte chunks of object code, code the following in SIRTUNEI or TUNERPTI:

  REPORT WHATC CHUNK 128

You can specify multiple breakdown types on a single REPORT WHATC statement. For example, this statement requests a breakdown of CPU usage by entire CSECT/Model 204 activity combination, and by CSECT chunks of 512 bytes, and by chunks of 64 bytes:

REPORT WHATC TOTAL CHUNK 512 CHUNK 64

Note: The MAPCORE statement in the report configuration input specifies that instructions outside of the loaded Model 204 module should be treated as a "CSECT," allowing analysis of CPU usage in the entire address space.

The TOP parameter

Many reports produce a listing of entities ranked in order of the number of samples for which data was found. The number of entities listed on these reports is either 50 or the value indicated on the last TOP statement before the REPORT statement. Thus, the following statement would list the top 50 evaluating procedures if no TOP statements appear in SIRTUNEI:

REPORT STATE RUNG EVAL

The first REPORT statement below lists the top 10 evaluating procedures, while the second REPORT lists the top 100:

TOP 10 REPORT STATE RUNG EVAL TOP 100 REPORT STATE RUNG EVAL

You can also explicitly specify the number of top entities to be listed on certain REPORT statements. The REPORT statements on which this can be done are:

• REPORT CSECT | CSECTM | CSECTS
• REPORT DISKIO
• REPORT QUADC | QUADCM | QUADCS
• REPORT SERVIO
• REPORT STATE
• REPORT WHATC | WHATCM | WHATCS

For example, to list the top 100 evaluating procedures for state RUNG, specify:

REPORT STATE RUNG EVAL TOP 100

To list the top 75 Model 204 database file tables with waits on disk I/O, specify:

REPORT DISKIO TABLE TOP 75

On REPORT statements with multiple breakdowns, the TOP statement must come after the breakdown description, and it applies only to the immediately preceding breakdown. Thus, the following is invalid:

REPORT STATE RUNG TOP 100 EVAL

The following would result in the top 60 chunks for the CHUNK 1000 breakdown, and the top 100 chunks for the CHUNK 100 breakdown:

TOP 60 REPORT STATE RUNG CHUNK 1000 CHUNK 100 TOP 100

See also

• SirTune introduction
• SirTune data collection under MVS
• SirTune data collection under CMS
• SirTune data collection statements
• SirTune MODIFY and SMSG commands
• SirTune report generation
• SirTune reports
• SirTune user states
• SirTune and Model 204 quad types
• SirTune statement wildcards
• SirTune date processing