SirTune reports: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (misc formatting)
m (misc cleanup)
Line 97: Line 97:
alternative parameters are separated by vertical bars (<tt>|</tt>).
alternative parameters are separated by vertical bars (<tt>|</tt>).


===REPORT CFRROOT===
===CFRROOT reports===
<p>
Syntax: </p>
<p class="syntax">REPORT CFRROOT
</p>
The <code>CFRROOT</code> report can be used to determine the root bottleneck behind critical file resource enqueuing.
The <code>CFRROOT</code> 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
Since critical file resource enqueuing is never a bottleneck in itself but
Line 138: Line 142:
For help diagnosing and correcting such a problem, [[Contacting Rocket Software Technical Support|contact Technical Support]].
For help diagnosing and correcting such a problem, [[Contacting Rocket Software Technical Support|contact Technical Support]].


===REPORT CSECT | CSECTM | CSECTS TOTAL | CHUNK ch_size===
===CSECT, CSECTM, and CSECTS reports===
The <code>CSECT/CSECTM/CSECTS</code> reports break down <var class="product">Model 204</var> CPU usage by CSECT.
<p>
Syntax: </p>
<p class="syntax">REPORT {CSECT | CSECTM | CSECTS} TOTAL | CHUNK <span class="term">ch_size</span>
</p>
The CSECT, CSECTM, and CSECTS reports break down <var class="product">Model&nbsp;204</var> CPU usage by CSECT.
These reports are generally only
These reports are generally only
of interest to <var class="product">Model 204</var> internals experts, though they might be of interest in shops that have extensive in-house $function libraries.
of interest to <var class="product">Model&nbsp;204</var> internals experts, though they might be of interest in sites that have extensive in-house $function libraries.


The <code>CSECT</code> report shows CPU usage by CSECT.
The <code>CSECT</code> report shows CPU usage by CSECT.
Line 182: Line 190:


<div id="diskio"></div>
<div id="diskio"></div>
===REPORT DISKIO TOTAL | TABLE | CHUNK ch_size===
===DISKIO reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
The <code>DISKIO</code> report provides a breakdown of waits on <var class="product">Model 204</var> disk I/O (database I/O). The breakdowns available are:
Syntax: </p>
<p class="syntax">REPORT DISKIO TOTAL | TABLE | CHUNK <span class="term">ch_size</span>
</p>
The <code>DISKIO</code> report provides a breakdown of waits on <var class="product">Model&nbsp;204</var> disk I/O (database I/O). The breakdowns available are:
<table class="thJustBold">
<table class="thJustBold">
<tr><th>TOTAL</th>
<tr><th>TOTAL</th>
Line 191: Line 202:


<tr><th>TABLE</th>
<tr><th>TABLE</th>
<td>This breaks down waits on <var class="product">Model&nbsp;204</var> disk I/O by tables within each database file. The five database file tables are the FCT, Table A, Table B, Table C, and Table D.
<td>This breaks down waits on <var class="product">Model&nbsp;204</var> disk I/O by tables within each database file. The seven [[File architecture overview#The components of a Model 204 file|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.</td></tr>
This breakdown is useful for determining if it is worth tuning the use of specific tables in the database files.</td></tr>


<tr><th>CHUNK</th>
<tr><th>CHUNK</th>
<td>This breaks down waits on <var class="product">Model 204</var> disk I/O by groups or chunks of a specific number (<i>ch_size</i>) 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.
<td>This breaks down waits on <var class="product">Model&nbsp;204</var> disk I/O by groups or chunks of a specific number (<i>ch_size</i>) 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.
<p>
<p>
This breakdown is generally only useful when using extremely large tables. Even in these cases, it is recommended that <var class="term">ch_size</var> be set to a large value (>1000) to produce meaningful results.</p></td></tr>
This breakdown is generally only useful when using extremely large tables. Even in these cases, it is recommended that <var class="term">ch_size</var> be set to a large value (>1000) to produce meaningful results.</p></td></tr>
</table>
</table>


To produce the DISKIO reports, <code>COLLECT DISKIO</code> must have been specified in the <var class="product">SirTune</var> data collection facilities input stream (SIRTUNEI).
To produce the DISKIO reports, you must specify this [[SirTune configuration statements#colstat|COLLECT statement]] in the <var class="product">SirTune</var> data collection input stream (<code>SIRTUNEI</code>):
 
<p class="code">COLLECT DISKIO</p>
To produce a report breaking down waits on disk I/O by files, code the following in SIRTUNEI:
<ul>
 
<li>To produce a report breaking down waits on disk I/O by files, specify the following in SIRTUNEI:
<p class="code">REPORT DISKIO TOTAL
<p class="code">REPORT DISKIO TOTAL
</p>
</p></li>


To produce a report breaking down waits on disk I/O by tables within
<li>To produce a report breaking down waits on disk I/O by tables within
files, code the following in SIRTUNEI:
files, specify the following in SIRTUNEI:
<p class="code">REPORT DISKIO TABLE
<p class="code">REPORT DISKIO TABLE
</p>
</p></li>


To produce a report breaking down waits on disk I/O by chunks of 10000 pages within each table within files, code the following
<li>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:
in SIRTUNEI:
<p class="code">REPORT DISKIO CHUNK 10000
<p class="code">REPORT DISKIO CHUNK 10000
</p>
</p></li>
</ul>


Multiple breakdown types can be specified on a single <code>REPORT DISKIO</code> statement. For example, the following SIRTUNEI specification requests reports breaking down waits on <var class="product">Model&nbsp;204</var> disk I/O by file, tables within file, and chunks of 5000 pages within tables:
Multiple breakdown types can be specified on a single <code>REPORT DISKIO</code> statement. For example, the following SIRTUNEI specification requests reports breaking down waits on <var class="product">Model&nbsp;204</var> disk I/O by file, tables within file, and chunks of 5000 pages within tables:
Line 222: Line 233:


<div id="rptinfo"></div>
<div id="rptinfo"></div>
===REPORT INFO===
===INFO reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
Syntax: </p>
<p class="syntax">REPORT INFO
</p>
The <code>INFO</code> report provides environmental information about the <var class="product">Model 204</var> ONLINE program and <var class="product">SirTune</var> data collection settings used in producing
The <code>INFO</code> report provides environmental information about the <var class="product">Model 204</var> ONLINE program and <var class="product">SirTune</var> data collection settings used in producing
the sample data set.
the sample data set.
Line 234: Line 248:


<div id="quadc"></div>
<div id="quadc"></div>
===REPORT QUADC | QUADCM | QUADCS TOTAL | CHUNK ch_size===
===QUADC, QUADCM, and QUADCS reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
The QUADC/QUADCM/QUADCS reports break down <var class="product">Model&nbsp;204</var> CPU
Syntax: </p>
usage by quad and CSECT. These reports are generally only
<p class="syntax">REPORT {QUADC | QUADCM | QUADCS} TOTAL | CHUNK <span class="term">ch_size</span>
of interest to <var class="product">Model&nbsp;204</var> internals experts, though they might
</p>
The QUADC, QUADCM, and QUADCS reports break down <var class="product">Model&nbsp;204</var> CPU usage by quad and CSECT. These reports are generally only of interest to <var class="product">Model&nbsp;204</var> internals experts, though they might
be of interest in shops that have extensive in-house $function libraries.
be of interest in shops that have extensive in-house $function libraries.


Line 287: Line 302:


<div id="repstat"></div>
<div id="repstat"></div>
===REPORT REPSTAT [RESET]===
===REPSTAT reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
Syntax: </p>
<p class="syntax">REPORT REPSTAT [RESET]
</p>
The <code>REPSTAT</code> report provides information on the performance of the report
The <code>REPSTAT</code> report provides information on the performance of the report
generator itself.  
generator itself.  
Line 315: Line 333:
When the REPSTAT report is used with the <code>TWOPASS</code> statement, the REPSTAT report shows results only in the second report-generation pass.
When the REPSTAT report is used with the <code>TWOPASS</code> statement, the REPSTAT report shows results only in the second report-generation pass.


===REPORT SERVIO===
===SERVIO reports===
<p>
Syntax: </p>
<p class="syntax">REPORT SERVIO
</p>
The <code>SERVIO</code> report provides a breakdown of waits on <var class="product">Model&nbsp;204</var> server I/O by server data sets (CCASERVR, CCASERV1, etc.). This is useful in identifying
The <code>SERVIO</code> report provides a breakdown of waits on <var class="product">Model&nbsp;204</var> 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.
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.
Line 323: Line 345:


<div id="servuse"></div>
<div id="servuse"></div>
===REPORT SERVUSE [CHUNK ch_size]===
===SERVUSE reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
Syntax: </p>
<p class="syntax">REPORT SERVUSE [CHUNK <span class="term">ch_size</span>]
</p>
The <code>SERVUSE</code> report provides a breakdown of users in particular states by
The <code>SERVUSE</code> report provides a breakdown of users in particular states by
server size. This can be useful in determining optimal server size allocations.
server size. This can be useful in determining optimal server size allocations.
Line 353: Line 378:
<p>
<p>
If neither state SWPGOW or WTSV was collected, this state is not listed on
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
the SERVUSE report. If only one of these states was collected, the header appears as the collected state rather than as "OSERVW."</p>
as the collected state rather than "OSERVW".</p>
<p>
<p>
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
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
Line 375: Line 399:
Users blocked out of server or swapping out to wait for something other than user input.
Users blocked out of server or swapping out to wait for something other than user input.
</p>
</p>
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".</li>
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."</li>


<li>OSERVU
<li>OSERVU
Line 381: Line 405:
Users blocked out of server or swapping out to wait for user input.
Users blocked out of server or swapping out to wait for user input.
</p>
</p>
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".</li>
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."</li>
</ul>
</ul>


<div id="repst"></div>
<div id="repst"></div>
===REPORT STATE state_name activity===
===STATE reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
Syntax: </p>
<p class="syntax">REPORT STATE <span class="term">state_name</span> <span class="term">activity</span>
</p>
The <code>STATE</code> report sorts users in a specified state (<var class="term">state_name</var>)
The <code>STATE</code> report sorts users in a specified state (<var class="term">state_name</var>)
by their current processing activity (<var class="term">activity</var>).
by their current processing activity (<var class="term">activity</var>).
Line 416: Line 443:


<tr><th>EVALI</th>
<tr><th>EVALI</th>
<td>By the name of the innermost procedure(s) being evaluated. This report is useful in environments where the same procedure(s) are INCLUDE'd in 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.</td></tr>
<td>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.</td></tr>


<tr><th>QUAD</th>
<tr><th>QUAD</th>
<td>By the current <var class="product">Model&nbsp;204</var> quad being evaluated. Quads are the internal representation of User Language. Every User Language statement maps to one or more quads.
<td>By the current <var class="product">Model&nbsp;204</var> 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.
Each $function is considered a separate quad in this breakdown.
<p>
<p>
While a breakdown by quad might generally only be of interest to a <var class="product">Model&nbsp;204</var> internals expert, these breakdowns might provide some hints about overall application characteristics, even to programmers unfamiliar with <var class="product">Model&nbsp;204</var> internals. The $function breakdown could be of particular interest in shops that have many and/or complex in-house $functions.</p></td></tr>
While a breakdown by quad might generally only be of interest to a <var class="product">Model&nbsp;204</var> internals expert, these breakdowns might provide some hints about overall application characteristics, even to programmers unfamiliar with <var class="product">Model&nbsp;204</var> internals. The $function breakdown could be of particular interest in shops that have many and/or complex in-house $functions.</p></td></tr>


<tr><th nowrap>CHUNK ch_size</th>
<tr><th nowrap>CHUNK <i>ch_size</i></th>
<td>By pieces of evaluating procedures. Every SOUL procedure can be broken up into an arbitrary number of pieces. <var class="product">SirTune</var> 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 (<var class="term">ch_size</var>).
<td>By pieces of evaluating procedures. Every SOUL procedure can be broken up into an arbitrary number of pieces. <var class="product">SirTune</var> 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 (<var class="term">ch_size</var>).
<p>
<p>
Line 452: Line 479:
<td>By IFAM2 function name (<var>IFFIND</var>, <var>IFPUT</var>, etc.). This report is not likely to be of interest unless IFAM2 shows up as significant on a <code>REPORT STATE <i>xxx</i> WHAT</code> report.</td></tr>
<td>By IFAM2 function name (<var>IFFIND</var>, <var>IFPUT</var>, etc.). This report is not likely to be of interest unless IFAM2 shows up as significant on a <code>REPORT STATE <i>xxx</i> WHAT</code> report.</td></tr>


<tr><th nowrap>IFCHUNK ch_size</th>
<tr><th nowrap>IFCHUNK <i>ch_size</i></th>
<td>By pieces of IFAM2 load modules. Every IFAM2 load module can be broken up into an arbitrary number of pieces. <var class="product">SirTune</var> allows grouping bytes of code in "chunks."
<td>By pieces of IFAM2 load modules. Every IFAM2 load module can be broken up into an arbitrary number of pieces. <var class="product">SirTune</var> 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 (<var class="term">ch_size</var>). Thus <code>REPORT STATE RUNG IFCHUNK 256</code> breaks up load modules into chunks of 256 bytes.
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 (<var class="term">ch_size</var>). Thus <code>REPORT STATE RUNG IFCHUNK 256</code> breaks up load modules into chunks of 256 bytes.
Line 501: Line 528:


<div id="repsumm"></div>
<div id="repsumm"></div>
===REPORT SUMMARY===
===SUMMARY reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
<p>
Syntax: </p>
<p class="syntax">REPORT SUMMARY
</p>
The SUMMARY report provides a summary of the average number of users in each sample, broken down by user state and wait type.


The SUMMARY report provides a summary of the average number of users in each
If using XML to configure the report, the XML equivalent to a <code>REPORT SUMMARY</code> control-card statement is two elements:
sample, broken down by user state and wait type.
<p class="code"><report type="state">
 
If using XML to configure the report, the XML equivalent to a REPORT SUMMARY
control-card statement is two elements:
<p class="code"><nowiki><report type="state">
<report type="waittype">
<report type="waittype">
</nowiki></p>
</p>


This report is of particular interest in determining potential problem areas.
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.
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 dataset.


Use caution when interpreting this report, especially when making
Use caution when interpreting this report, especially when making
Line 525: Line 549:
<ul>
<ul>
<li>There are never any users waiting for server.</li>
<li>There are never any users waiting for server.</li>
<li>No COLLECT statements were coded to tell <var class="product">SirTune</var> to collect data for
 
<li>No [[SirTune configuration statements#colstat|COLLECT statements]] were coded to tell <var class="product">SirTune</var> to collect data for
users in state WTSV.</li>
users in state WTSV.</li>
</ul>
</ul>


<div id="sysprm"></div>
<div id="sysprm"></div>
===REPORT SYSPARM===
===SYSPARM reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
<p>
Syntax: </p>
<p class="syntax">REPORT SYSPARM
</p>
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 <code>VIEW SYSTEM CWAIT</code> command issued in the Online associated with the sample dataset.


The SYSPARM report provides the values of all system and scheduler parameters
This report is only available in the <var class="product">SirTune</var> report writer versions 1.6 and later. In addition, the data presented by this report is only provided in sample data sets
in the Online associated with the sample dataset.
This report provides identical output to a <code>VIEW SYSTEM CWAIT</code> command
issued in the Online associated with the sample dataset.
 
This report is only available in the <var class="product">SirTune</var> report writer versions 1.6 and later. In addition, the data presented by this report is only provided in sample datasets
collected with the <var class="product">SirTune</var> data collecter version 7.0 and later.
collected with the <var class="product">SirTune</var> data collecter version 7.0 and later.
For sample datasets created with earlier <var class="product">SirTune</var> data collectors, the
For sample data sets created with earlier <var class="product">SirTune</var> data collectors, the
REPORT SYSPARM report will be empty.
SYSPARM report will be empty.


While this is not one of the default reports produced by the report generator,
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.
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.


<div id="whatc"></div>
<div id="whatc"></div>
===REPORT WHATC | WHATCM | WHATCS TOTAL | CHUNK ch_size===
===WHATC, WHATCM, and WHATCS reports===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
 
<p>
The WHATC/WHATCM/WHATCS reports break down <var class="product">Model 204</var> CPU
Syntax: </p>
<p class="syntax">REPORT {WHATC | WHATCM | WHATCS} TOTAL | CHUNK <span class="term">ch_size</span>
</p>
The WHATC, WHATCM, and WHATCS reports break down <var class="product">Model&nbsp;204</var> CPU
usage by <var class="product">Model 204</var> "activity" and CSECT.
usage by <var class="product">Model 204</var> "activity" and CSECT.
The most common <var class="product">Model 204</var> activities are evaluating and compiling.
The most common <var class="product">Model&nbsp;204</var> activities are evaluating and compiling.
These reports are generally only of interest to <var class="product">Model 204</var> internals experts, though they might be of interest in shops that have extensive in-house $function libraries.
These reports are generally only of interest to <var class="product">Model&nbsp;204</var> 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 <var class="product">Model 204</var> activity and CSECTs. Since the breakdown is a CSECT-level breakdown, the setting of the MPVIRT parameter
The WHATC report breaks down all CPU usage by <var class="product">Model&nbsp;204</var> activity and CSECTs. Since the breakdown is a CSECT-level breakdown, the setting of the MPVIRT parameter
([[SirTune Report Generator configuration#mpvirt|MPVirt]]) has no effect on the WHATCM and WHATCS reports &mdash; only the real task on which a request was running is used to distinguish CSECTS
([[SirTune Report Generator configuration#mpvirt|MPVirt]]) has no effect on the WHATCM and WHATCS reports &mdash; only the real task on which a request was running is used to distinguish CSECTS and CSECTM.
and CSECTM.


When running the MP/204 feature, the WHATCM report breaks down maintask
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
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.
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.


<blockquote class="note"><b>Note:</b> If using XML for the parameters ([[SirTune Report Generator configuration#xmlrpti|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.
<blockquote class="note">
<b>Note:</b> If using XML for the parameters ([[SirTune Report Generator configuration#xmlrpti|Using XML input for report configuration]]), a single convention can handle these different WHATC report variations: specify a <code>task=maintask</code> or <code>task=subtask</code> attribute for a <code>type=whatc</code> report to invoke, repectively, a WHATCM or a WHATCS report.
<p>
<p>
For example, to get a WHATCS report:</p>
For example, to get a WHATCS report:</p>
<p class="code"><nowiki><report type="whatc" task="subtask">
<p class="code"><report type="whatc" task="subtask">
</nowiki></p>
</p>
</blockquote>
</blockquote>


WHATC|M|S reports are further qualified by the TOTAL or CHUNK keyword:
WHATC, WHATCM, and WHATCS reports are further qualified by the <code>TOTAL</code> or <code>CHUNK</code> keyword:
<ul>
<ul>
<li>TOTAL requests a breakdown of CPU usage by <var class="product">Model 204</var> activities
<li>TOTAL requests a breakdown of CPU usage by <var class="product">Model&nbsp;204</var> activities
and entire CSECT. For example, to produce a breakdown of CPU usage where each entry
and entire CSECT. For example, to produce a breakdown of CPU usage where each entry in the report is an entire CSECT/<var class="product">Model&nbsp;204</var> activity combination, you use:
in the report is an entire CSECT/<var class="product">Model 204</var> activity combination, you use:
<p class="code"><nowiki>REPORT WHATC TOTAL
<p class="code"><nowiki>REPORT WHATC TOTAL
</nowiki></p>
</nowiki></p>
Line 583: Line 607:
equivalent to <code>REPORT WHATC TOTAL</code>.</p>
equivalent to <code>REPORT WHATC TOTAL</code>.</p>
<p>
<p>
If using XML in the report configuration input, <code>REPORT WHATC TOTAL</code>
If using XML in the report configuration input, <code>REPORT WHATC TOTAL</code> is equivalent to <code><report type="whatc" chunk="total"/></code>.</p></li>
is equivalent to <code><report type="whatc" chunk="total"/></code>.</p></li>


<li>CHUNK requests a breakdown of CPU usage by pieces of
<li>CHUNK requests a breakdown of CPU usage by pieces of
each CSECT for each <var class="product">Model 204</var> activity.
each CSECT for each <var class="product">Model 204</var> activity.
The size of each piece or chunk is <i>ch_size</i> bytes of object code.
The size of each piece or chunk is <var class="term">ch_size</var> 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:
Thus to get a breakdown of CPU usage by 128-byte chunks of object code, code the following in SIRTUNEI or TUNERPTI:
<p class="code"><nowiki>REPORT WHATC CHUNK 128
<p class="code">REPORT WHATC CHUNK 128
</nowiki></p></li>
</p></li>
</ul>
</ul>


You can specify multiple breakdown types on a single REPORT WHATC statement.
You can specify multiple breakdown types on a single <code>REPORT WHATC</code> statement.
For example, this statement requests a breakdown of CPU usage by entire CSECT/<var class="product">Model 204</var> activity combination, and by
For example, this statement requests a breakdown of CPU usage by entire CSECT/<var class="product">Model&nbsp;204</var> activity combination, and by CSECT chunks of 512 bytes, and by chunks of 64 bytes:
CSECT chunks of 512 bytes, and by chunks of 64 bytes:
<p class="code">REPORT WHATC TOTAL CHUNK 512 CHUNK 64
<p class="code"><nowiki>REPORT WHATC TOTAL CHUNK 512 CHUNK 64
</p>
</nowiki></p>
<p class="note"><b>Note:</b> The [[SirTune Report Generator configuration#mapcore|MAPCORE]] statement in the report configuration input specifies that instructions outside of the loaded <var class="product">Model&nbsp;204</var> module should be treated as a "CSECT," allowing analysis of CPU usage in the entire address space.
<p class="note"><b>Note:</b> The MAPCORE statement ([[SirTune Report Generator configuration#mapcore|MAPcore]]) in the report configuration input specifies that instructions outside of the loaded <var class="product">Model 204</var> module should be treated as a "CSECT," allowing analysis of CPU usage in the entire address space.
</p>
</p>


Line 605: Line 627:
===The TOP parameter===
===The TOP parameter===
<!--Caution: <div> above-->
<!--Caution: <div> above-->
Many reports produce a listing of entities ranked in order of the number
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
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
on these reports is either 50 or the value indicated on the last [[SirTune Report Generator configuration#TOP num_top|TOP
statement before the REPORT statement. Thus, the following
statement]] before the REPORT statement. Thus, the following
would list the top 50 evaluating procedures if no TOP statements
statement would list the top 50 evaluating procedures if no TOP statements
appear in SIRTUNEI:
appear in SIRTUNEI:
<p class="code"><nowiki>REPORT STATE RUNG EVAL
<p class="code">REPORT STATE RUNG EVAL
</nowiki></p>
</p>


The first report below would list the top 10 evaluating procedures, while
The first <code>REPORT</code> statement below lists the top 10 evaluating procedures, while the second <code>REPORT</code> lists the top 100:
the second report would list the top 100:
<p class="code">TOP 10
<p class="code"><nowiki>TOP 10
REPORT STATE RUNG EVAL
REPORT STATE RUNG EVAL
TOP 100
TOP 100
REPORT STATE RUNG EVAL
REPORT STATE RUNG EVAL
</nowiki></p>
</p>


You can also explicitly specify the number of top entities to
You can also explicitly specify the number of top entities to
be listed on certain REPORT statements.
be listed on certain REPORT statements.
The report statements on which this can be done are:
The REPORT statements on which this can be done are:
<ul>
<ul>
<li>REPORT CSECT | CSECTM | CSECTS</li>
<li>REPORT CSECT | CSECTM | CSECTS</li>
Line 636: Line 656:


For example, to list the top 100 evaluating procedures for state
For example, to list the top 100 evaluating procedures for state
RUNG, simply code:
RUNG, specify:
<p class="code"><nowiki>REPORT STATE RUNG EVAL TOP 100
<p class="code">REPORT STATE RUNG EVAL TOP 100
</nowiki></p>
</p>


To list the top 75 <var class="product">Model 204</var> database file tables with waits on
To list the top 75 <var class="product">Model 204</var> database file tables with waits on disk I/O, specify:
disk I/O, code:
<p class="code">REPORT DISKIO TABLE TOP 75
<p class="code"><nowiki>REPORT DISKIO TABLE TOP 75
</p>
</nowiki></p>


On REPORT statements with multiple breakdowns, the TOP statement must
On REPORT statements with multiple breakdowns, the TOP statement must
come after the breakdown description, and it applies only to the immediately
come after the breakdown description, and it applies only to the immediately preceding breakdown. Thus, the following is <b><i>invalid</i></b>:
preceding breakdown. Thus, the following is <b><i>invalid</i></b>:
<p class="code">REPORT STATE RUNG TOP 100 EVAL
<p class="code"><nowiki>REPORT STATE RUNG TOP 100 EVAL
</p>
</nowiki></p>


The following would result in the top 60 chunks for the CHUNK 1000 breakdown, and the top
The following would result in the top 60 chunks for the <code>CHUNK 1000</code> breakdown, and the top 100 chunks for the <code>CHUNK 100</code> breakdown:
100 chunks for the CHUNK 100 breakdown:
<p class="code">TOP 60
<p class="code"><nowiki>TOP 60
REPORT STATE RUNG CHUNK 1000 CHUNK 100 TOP 100
REPORT STATE RUNG CHUNK 1000 CHUNK 100 TOP 100
</nowiki></p>
</p>


==See also==
==See also==

Revision as of 22:19, 6 November 2015

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.

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. If the SIRIUS 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 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 can 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.

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 (|).

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

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.

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