SirTune reports: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (rkt)
m (misc formatting)
Line 3: Line 3:
You've been warned.  ..  (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->
You've been warned.  ..  (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->
<!-- Page name: SirTune reports-->
<!-- Page name: SirTune reports-->
<p></p>
==Overview==
The <var class="product">SirTune</var> reporting module  produces a listing that is made up of
The <var class="product">SirTune</var> reporting module  produces a listing that is made up of one or more reports.
one or more reports.
These reports can be used to tune problem areas in an Online.  
These reports can be used to tune problem areas in an Online
job.
   
   
In <var class="product">SirTune</var> versions prior to 7.2, reporting is done via SIRTUNER,
===SIRTUNEREPORT replaces SIRTUNER===
an assembler module that is separately distributed and installed.
In <var class="product">SirTune</var> versions prior to 7.2, reporting is done via <code>SIRTUNER</code>, an assembler module that is separately distributed and installed.
In version 7.2 and later, reporting is done by SIRTUNEREPORT,
In version 7.2 and later, reporting is done by <code>SIRTUNEREPORT</code>,
a <var class="product">SOUL</var> program that is distributed in the <var class="product">[[RKTools]]</var> file <code>SIRIUS</code>.
a <var class="product">SOUL</var> program that is distributed in the <var class="product">[[RKTools]]</var> file <code>SIRIUS</code>.
   
   
SIRTUNER cannot be used with <var class="product">SirTune</var> 7.2 and later.
SIRTUNER cannot be used with <var class="product">SirTune</var> 7.2 and later. Conversely, the SIRTUNEREPORT program cannot be used with versions prior to 7.2 of the <var class="product">[[Sirius Mods]]</var>, since it is based on the <var>[[SirTuneReport (Dataset function)|SirTuneReport]]</var> method of the <var>Dataset</var> class, which was first implemented in version 7.2.
Conversely, the SIRTUNEREPORT program cannot be used with versions prior to 7.2 of the <var class="product">[[Sirius Mods]]</var>, since it is based on the <code>sirtuneReport</code> method of
the <var>Dataset</var> class which was first implemented in version 7.2.


While it is possible to run SIRTUNEREPORT inside a <var class="product">Model 204</var> Online,
While it is possible to run SIRTUNEREPORT inside a <var class="product">Model&nbsp;204</var> Online, it is strongly recommended that it be run in a standalone batch job,
it is strongly recommended that it be run in a standalone batch job,
as it can consume considerable resources from an Online job.
as it can consume considerable resources from an Online job.
If the SIRIUS file cannot be allocated to a batch job, SIRTUNEREPORT
If the SIRIUS file cannot be allocated to a batch job, SIRTUNEREPORT
Line 27: Line 22:
<ol>
<ol>
<li>Move SIRTUNEREPORT and the
<li>Move SIRTUNEREPORT and the
included procedure SHARED_REPORT to the new file.
included procedure <code>SHARED_REPORT</code> to the new file.


<li>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).
<li>Change the single reference to <code>SIRIUS</code> to the new file name (this reference is an <var>Include</var> statement near the top of the procedure, after the variable declarations).
</ol>
</ol>


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


If not suppressed with the REPORT NODEFAULT statement
===Use REPORT or <report> to specify which reports to produce===
(see [[SirTune Report Generator configuration#REPort report_desc &#124; NODEFAULT|REPort report_desc &#124; NODEFAULT]]), the reporting module always produces a default set of reports.
If not suppressed with the [[SirTune Report Generator configuration#REPort report_desc &#124; NODEFAULT|REPORT NODEFAULT]] statement, the reporting module always produces a default set of reports.
Additional reports are requested with the REPORT statement.
Additional reports are requested with the REPORT statement.


The default reports produced are identical to the reports you
The default reports produced are identical to the reports you
get with the following REPORT statements:
get with the following REPORT statements:
<p class="code"><nowiki>REPORT INFO
<p class="code">REPORT INFO
REPORT SUMMARY
REPORT SUMMARY
REPORT STATE RUNG WHAT EVAL CHUNK 4000
REPORT STATE RUNG WHAT EVAL CHUNK 4000
REPORT STATE RUNG EVAL CHUNK 400 CHUNK 4
REPORT STATE RUNG EVAL CHUNK 400 CHUNK 4
</nowiki></p>
</p>


In XML format, these default reports are specified like this:
In XML format, these default reports are specified like this:
<p class="code"><nowiki><SirtuneInput maxDelay="10" top="50">
<p class="code"><SirtuneInput maxDelay="10" top="50">
   <report type="info">
   <report type="info">
   <report type="state">
   <report type="state">
Line 60: Line 55:
   <report type="eval" state="rung" chunk="4">
   <report type="eval" state="rung" chunk="4">
</SirtuneInput>
</SirtuneInput>
</nowiki></p>
</p>
<blockquote class="note"><b>Note:</b> The XML equivalent to the REPORT SUMMARY control-card statement is two elements:
<blockquote class="note"><b>Note:</b> The XML equivalent to the <code>REPORT SUMMARY</code> control-card statement is two elements:
<p class="code"><report type="state">
<p class="code"><report type="state">
<report type="waittype">
<report type="waittype">
Line 67: Line 62:
</blockquote>
</blockquote>


In addition to these, a variety of other reports can be produced upon request.
In addition to these, a variety of other reports can be produced upon request. These reports can are requested via the REPORT statement (see
These reports can are requested via the REPORT statement (see
example in [[SirTune report generation#repsmvs|Generating reports prior to Sirius Mods 7.2: MVS]]
example in [[SirTune report generation#repsmvs|Generating reports prior to Sirius Mods 7.2: MVS]]
or [[SirTune report generation#repscms|Generating reports prior to Sirius Mods 7.2: CMS]]).
or [[SirTune report generation#repscms|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 reports appear in the same order in the output (<code>TUNERPTO</code>) as they appear in the input (<code>TUNERPTI</code>).
the input (TUNERPTI).


===Deciding which reports to produce===
The main considerations to use in determining which reports to produce
The main considerations to use in determining which reports to produce
are (in descending order of importance):
are (in descending order of importance):
Line 82: Line 76:
</ul>
</ul>


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


Sirtune reports are described in the following subsections.
===Sample data set restrictions===
Optional parameters are listed in brackets (<tt>[</tt><tt>]</tt>) and
alternative parameters are separated by vertical bars (<tt>|</tt>).
<blockquote class="note"><b>Notes:</b>
<ul>
<ul>
<li>Due to format changes in the sample dataset, only the SIRTUNEREPORT
<li>Due to format changes in the sample data set, only the SIRTUNEREPORT
program can process a <var class="product">SirTune</var> version 7.2 and later sample dataset.</li>
program can process a <var class="product">SirTune</var> version 7.2 and later sample data set.</li>


<li>Due to format changes in the sample dataset, only releases 1.6 and
<li>Due to format changes in the sample data set, only releases 1.6 and
later of SIRTUNER can process a <var class="product">SirTune</var> version 7.0 and later sample dataset.</li>
later of SIRTUNER can process a <var class="product">SirTune</var> version 7.0 and later sample data set.</li>


<li>Due to format changes in the sample dataset in <var class="product">SirTune</var> version 1.5, earlier releases of SIRTUNER cannot process a <var class="product">SirTune</var> 1.5 or higher sample dataset.</li>
<li>Due to format changes in the sample data set in <var class="product">SirTune</var> version 1.5, earlier releases of SIRTUNER cannot process a <var class="product">SirTune</var> 1.5 or higher sample data set.</li>
</ul>
</ul>
</blockquote>


==REPORT CFRROOT==
==The SirTune reports==
The CFRROOT report can be used to determine the root bottleneck
In the individual Sirtune report descriptions in this page,
behind critical file resource enqueuing.
optional parameters are listed in brackets (<tt>[</tt><tt>]</tt>) and
alternative parameters are separated by vertical bars (<tt>|</tt>).
 
===REPORT CFRROOT===
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
will exacerbate some other bottleneck, this report can be useful
will exacerbate some other bottleneck, this report can be useful
Line 114: Line 108:
Unfortunately, this is also usually the most complex bottleneck to correct.
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
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 CFRB??? reports
next step should probably be to look at the <code>STATE CFRB<i>xxx</i></code> reports to try to locate the programs or statements that produce the disk I/O that results in critical file resource enqueuing.
to try to locate the programs or statements that produce the disk
It might also be useful to look at <code>STATE WDISK</code> reports and <code>DISKIO</code> reports
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.
to get information on the cause of all waits for disk I/O.


Line 126: Line 118:
<tr><th>Journal I/O</th>
<tr><th>Journal I/O</th>
<td>This cause might be reduced by placing the journal on a faster device (DASD fast write is especially helpful here)
<td>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 (a REPORT STATE WJRNLO might help isolate code that is flooding the journal).</td></tr>
or by reducing the quantity of journal data being produced (<code>REPORT STATE WJRNLO</code> might help isolate code that is flooding the journal).</td></tr>


<tr><th nowrap>Checkpoint I/O</th><td>This cause might be reduced by placing the checkpoint dataset on a faster device (DASD fast write is especially helpful here).</td></tr>
<tr><th nowrap>Checkpoint I/O</th>
<td>This cause might be reduced by placing the checkpoint dataset on a faster device (DASD fast write is especially helpful here).</td></tr>


<tr><th>Arbitration</th>
<tr><th>Arbitration</th>
<td>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.</td></tr>
<td>This shows up as <code>ARBMO</code> 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.</td></tr>


<tr><th>CPU</th><td>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.</td></tr>
<tr><th>CPU</th>
<td>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.</td></tr>


<tr><th>SERVER</th>
<tr><th>SERVER</th>
<td>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.</td></tr>
<td>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 <code>SERVER</code> shows up at the top of the CFRROOT report.</td></tr>
</table>
</table>


Line 144: Line 138:
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==
===REPORT CSECT | CSECTM | CSECTS  TOTAL | CHUNK ch_size===
<p></p>
The <code>CSECT/CSECTM/CSECTS</code> reports break down <var class="product">Model 204</var> CPU usage by CSECT.
The CSECT/CSECTM/CSECTS reports break down <var class="product">Model 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
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.
be of interest in shops that have extensive in-house $function
 
libraries.
The <code>CSECT</code> report shows CPU usage by CSECT.
<p></p>
When running the MP/204 feature, the <code>CSECTM</code> report shows maintask CPU usage by CSECT, and the <code>CSECTS</code> report shows subtask CPU usage by CSECT.
The CSECT report shows 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.
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.
<blockquote class="note">
<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 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:
<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 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.  
<p class="code"><nowiki><report type="csect" task="maintask">
<p>
</nowiki></p>
For example, to get a CSECTM report: </p>
<p class="code"><report type="csect" task="maintask">
</p>
</blockquote>
</blockquote>


The CSECT|M|S reports are further qualified by a TOTAL or CHUNK keyword:
The CSECT|M|S reports are further qualified by a <code>TOTAL</code> or <code>CHUNK</code> keyword:
<ul>
<ul>
<li>TOTAL requests a breakdown of CPU usage by whole CSECTs.
<li>TOTAL requests a breakdown of CPU usage by whole CSECTs.
For example, to produce a breakdown of CPU usage where each entry
For example, to produce a breakdown of CPU usage where each entry
in the report is an entire CSECT, you use:
in the report is an entire CSECT, you use:
<p class="code"><nowiki>REPORT CSECT TOTAL
<p class="code">REPORT CSECT TOTAL
</nowiki></p>
</p>
<p>
<p>
Since TOTAL is the default, a <code>REPORT CSECT</code> statement is
Since TOTAL is the default, a <code>REPORT CSECT</code> statement is
equivalent to <code>REPORT CSECT TOTAL</code>. </p>
equivalent to <code>REPORT CSECT TOTAL</code>. </p>
<p>
<p>
If using XML in the report configuration input, <code>REPORT CSECT TOTAL</code>
If using XML in the report configuration input, <code>REPORT CSECT TOTAL</code> is equivalent to <code><report type="csect" chunk="total"/></code>.
is equivalent to <code><report type="csect" chunk="total"/></code>.
</p></li>
</p></li>


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


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


<div id="diskio"></div>
<div id="diskio"></div>
==REPORT DISKIO  TOTAL | TABLE | CHUNK ch_size==
===REPORT DISKIO  TOTAL | TABLE | CHUNK ch_size===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


The DISKIO report provides a breakdown of waits on <var class="product">Model 204</var> disk I/O (database I/O). The possible breakdowns available are:
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:
<table class="thJustBold">
<table class="thJustBold">
<tr><th>TOTAL</th><td>This breaks down waits on <var class="product">Model 204</var> disk I/O by database file. This is useful for determining which files have the heaviest I/O activity.</td></tr>
<tr><th>TOTAL</th>
<td>This breaks down waits on <var class="product">Model 204</var> disk I/O by database file. This is useful for determining which files have the heaviest I/O activity.</td></tr>


<tr><th>TABLE</th>
<tr><th>TABLE</th>
<td> This breaks down waits on <var class="product">Model 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 five database file tables are the FCT, Table A, Table B, Table C, and Table D.
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>


Line 207: Line 197:
<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 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 <i>ch_size</i> 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, COLLECT DISKIO must have been specified
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).
in the <var class="product">SirTune</var> data collection facilities input stream (SIRTUNEI).


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


<p class="code"><nowiki>REPORT DISKIO TOTAL
<p class="code">REPORT DISKIO TOTAL
</nowiki></p>
</p>


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


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


Multiple breakdown types can be specified on a single REPORT DISKIO statement.
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:
For example, the following SIRTUNEI specification requests reports breaking down waits on <var class="product">Model 204</var> disk I/O by file, tables within file and chunks of 5000 pages within tables:
<p class="code">REPORT DISKIO TOTAL TABLE CHUNK 5000
<p class="code"><nowiki>REPORT DISKIO TOTAL TABLE CHUNK 5000
</p>
</nowiki></p>


<div id="rptinfo"></div>
<div id="rptinfo"></div>
==REPORT INFO==
===REPORT INFO===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


The INFO 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 dataset.
the sample data set.
This report includes settings of key <var class="product">Model 204</var> parameters
This report includes settings of key <var class="product">Model&nbsp;204</var> parameters (<var>NUSERS</var>, <var>NSERVS</var>, <var>NJBUFF</var>, etc.) and <var class="product">SirTune</var> parameters (sampling interval, COLLECT settings, etc.).
(NUSERS, NSERVS, NJBUFF, etc.) and <var class="product">SirTune</var> parameters (sampling interval, COLLECT settings, etc.).


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


<div id="quadc"></div>
<div id="quadc"></div>
==REPORT QUADC | QUADCM | QUADCS  TOTAL | CHUNK ch_size==
===REPORT QUADC | QUADCM | QUADCS  TOTAL | CHUNK ch_size===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


The QUADC/QUADCM/QUADCS reports break down <var class="product">Model 204</var> CPU
The QUADC/QUADCM/QUADCS reports break down <var class="product">Model&nbsp;204</var> CPU
usage by quad and CSECT. These reports are generally only
usage by quad and CSECT. These reports are generally only
of interest to <var class="product">Model 204</var> internals experts, though they might
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.


The QUADC report breaks down all CPU usage by quad and the CSECTs.
The <code>QUADC</code> report breaks down all CPU usage by quad and the CSECTs. Since the breakdown is a CSECT-level breakdown, the
Since the breakdown is a CSECT-level breakdown, the MPVIRT configuration parameter
[[SirTune Report Generator configuration#mpvirt|MPVIRT]] configuration parameter has no effect on the QUADCM and QUADCS reports &mdash; only the
([[SirTune Report Generator configuration#mpvirt|MPVirt]])
has no effect on the QUADCM and QUADCS reports &mdash; only the
real task on which a request was running is used to distinguish CSECTS and CSECTM.
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
When running the MP/204 feature, the <code>QUADCM</code> report shows maintask CPU usage by quad and CSECT, and the <code>QUADCS</code> report shows subtask CPU usage by quad and CSECT. If not running the MP/204 feature or running
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.
the feature with 0 subtasks, QUADC is equivalent to QUADCM, and QUADCS is always 0.


Line 271: Line 252:
<p>
<p>
For example, to get a QUADCM report:</p>
For example, to get a QUADCM report:</p>
<p class="code"><nowiki><report type="quadc" task="maintask">
<p class="code"><report type="quadc" task="maintask">
</nowiki></p>
</p>
</blockquote>
</blockquote>


These quad reports are further qualified by a TOTAL or CHUNK keyword:
These quad reports are further qualified by a <code>TOTAL</code> or <code>CHUNK</code> keyword:
<ul>
<ul>
<li>TOTAL requests a breakdown of CPU usage by quads and entire
<li>TOTAL requests a breakdown of CPU usage by quads and entire
CSECT. For example, to produce a breakdown of CPU usage where each entry
CSECT. For example, to produce a breakdown of CPU usage where each entry
in the report is an entire CSECT/quad combination, you use:
in the report is an entire CSECT/quad combination, you use:
<p class="code"><nowiki>REPORT QUADC TOTAL
<p class="code">REPORT QUADC TOTAL
</nowiki></p>
</p>
<p>
<p>
Since TOTAL is the default, a <code>REPORT QUADC</code> statement is
Since TOTAL is the default, a <code>REPORT QUADC</code> statement is
Line 290: Line 271:


<li>CHUNK requests a breakdown of CPU usage by pieces of each CSECT for each quad.
<li>CHUNK requests a breakdown of CPU usage by pieces of each CSECT for each quad.
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:
Thus to get a breakdown of CPU usage by 128-byte chunks of object code, code the following in SIRTUNEI:
<p class="code"><nowiki>REPORT QUADC CHUNK 128
<p class="code">REPORT QUADC CHUNK 128
</nowiki></p></li>
</p></li>
</ul>
</ul>


You can specify multiple breakdown types on a single REPORT QUADC statement.
You can specify multiple breakdown types on a single <code>REPORT QUADC</code> 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:
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:
<p class="code"><nowiki>REPORT QUADC TOTAL CHUNK 512 CHUNK 64
<p class="code">REPORT QUADC TOTAL CHUNK 512 CHUNK 64
</nowiki></p>
</p>
<p class="note"><b>Note:</b> The MAPCORE statement ([[SirTune Report Generator configuration#mapcore|MAPcore]]) in the report configuration input
<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
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
should be treated as a "CSECT," allowing analysis of CPU usage in the
entire address space.
entire address space.
Line 307: Line 287:


<div id="repstat"></div>
<div id="repstat"></div>
==REPORT REPSTAT [RESET]==
===REPORT REPSTAT [RESET]===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


The REPSTAT report provides information on the performance of the report
The <code>REPSTAT</code> report provides information on the performance of the report
generator itself. The REPSTAT report breaks down the time for the report generation process into
generator itself.  
its individual components, CPU time, waiting for input buffer time, waiting for
<p>
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
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.
on above-the-line (31 bit) and below-the-line (24 bit) storage usage.</p>
 
<p class="note"><b>Note:</b> This report is only of interest if the performance or storage usage of SIRTUNER is a concern. It is not supported in <var class="product">SirTune</var> 7.2 and later (using the SIRTUNEREPORT <var class="product">SOUL</var> program), and a <code>repstat</code> keyword is <i>not</i> supported as a report type option in the XML format for specifying report configuration parameters ([[SirTune Report Generator configuration#templt|A template for the XML input]]).
<p class="note"><b>Note:</b> This report is only of interest if the performance or storage usage of SIRTUNER is a concern. It is not supported in <var class="product">SirTune</var> 7.2 and later (using the SIRTUNEREPORT <var class="product">SOUL</var> program), and a <code>repstat</code> keyword is <i>not</i> supported as a report type option in the XML format for specifying report configuration parameters ([[SirTune Report Generator configuration#templt|A template for the XML input]]).
</p>
</p>


The RESET parameter requests that usage counters be reset after the REPSTAT
The <code>RESET</code> 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. This makes it easy to determine the cost of actually producing a particular
report. For example, in the following sequence
report. For example, in the following sequence
the counters reported in the second REPSTAT report will show the cost of producing
the counters reported in the second REPSTAT report will show the cost of producing
the REPORT STATE RUNG CHUNK 100 report:
the <code>REPORT STATE RUNG CHUNK 100</code> report:
<p class="code"><nowiki>REPORT REPSTAT RESET
<p class="code">REPORT REPSTAT RESET
REPORT STATE RUNG CHUNK 100
REPORT STATE RUNG CHUNK 100
REPORT REPSTAT
REPORT REPSTAT
</nowiki></p>
</p>


Note that this report will not indicate the cost of
Note that this report will not indicate the cost of
Line 332: Line 313:
This latter cost will often be significantly greater than the cost of actually generating the 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
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 will show results only in the second report-generation pass.


==REPORT SERVIO==
===REPORT SERVIO===
The SERVIO report provides a breakdown of waits on <var class="product">Model 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,
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.
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 <var class="product">Model 204</var> 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.
In general, ideal performance is achieved when all <var class="product">Model&nbsp;204</var> server data sets show the same level of activity and response. Model&nbsp;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.
Disparities in number of users waiting on specific server data sets could be indicative of a problem.


<div id="servuse"></div>
<div id="servuse"></div>
==REPORT SERVUSE [CHUNK ch_size]==
===REPORT SERVUSE [CHUNK ch_size]===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


The SERVUSE 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.
The states for which information is provided is a subset of all states
The states for which information is provided is a subset of all states
described in [[SirTune user states]].
described in [[SirTune user states]].


Server sizes are grouped by chunk size (<i>ch_size</i>).
Server sizes are grouped by chunk size (<var class="term">ch_size</var>).
The default for <i>ch_size</i> is 10000. This default results in 100 possible categories of server sizes between 0 and 1,000,000 bytes.
The default for <var class="term">ch_size</var> 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
Groups with no observations are not displayed on the SERVUSE report.
SERVUSE report.


The breakdowns are provided by the following states:
The breakdowns are provided by the following states:
Line 365: Line 342:
Running or ready users.</p>
Running or ready users.</p>
If state REDY was not collected, this is displayed as RUNG, meaning running users.</li>
If state REDY was not collected, this is displayed as RUNG, meaning running users.</li>
<li>SWPGI
<li>SWPGI
<p>
<p>
Line 378: Line 356:
as the collected state rather than "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
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
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.</p></li>
190000-199999 would indicate a requirement for more 200K servers.</p></li>


Line 409: Line 385:


<div id="repst"></div>
<div id="repst"></div>
==REPORT STATE state_name activity==
===REPORT STATE state_name activity===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


The STATE report sorts users in a specified state (<i>state_name</i>)
The <code>STATE</code> report sorts users in a specified state (<var class="term">state_name</var>)
by their current processing activity (<i>activity</i>).
by their current processing activity (<var class="term">activity</var>).
<p>
<p>
<i>state_name</i> can be any valid <var class="product">SirTune</var> state, and
<var class="term">state_name</var> can be any valid <var class="product">SirTune</var> state, and
the states are described in [[SirTune user states]].</p>
the states are described in [[SirTune user states]].</p>
<p>
<p>
Line 421: Line 397:
<table class="thJustBold">
<table class="thJustBold">
<tr><th>WHAT</th>
<tr><th>WHAT</th>
<td>By the generic activity groupings used by <var class="product">Model 204</var> in its "WHAT" flag settings. The most common of these activities is compiling, loading, and evaluating User Language procedures.</td></tr>
<td>By the generic activity groupings used by <var class="product">Model&nbsp;204</var> in its "WHAT" flag settings. The most common of these activities is compiling, loading, and evaluating SOUL procedures.</td></tr>


<tr><th>COMP</th>
<tr><th>COMP</th>
Line 427: Line 403:


<tr><th>LOAD</th>
<tr><th>LOAD</th>
<td>By the name of the pre-compiled 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.</td></tr>
<td>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.</td></tr>


<tr><th>EVAL</th>
<tr><th>EVAL</th>
Line 434: Line 410:
<li>Which procedures are worth looking at in more detail</li>
<li>Which procedures are worth looking at in more detail</li>


<li>Whether any non-precompiled or non-APSY procedures are significant resource consumers.</li> </ul>
<li>Whether any non-precompiled or non-APSY procedures are significant resource consumers.</li>  
</ul>
<p>
<p>
This is important because, unless the ALLCOMP option ([[SirTune configuration statements#allcomp|ALLComp]]) was specified for the data collection portion of <var class="product">SirTune</var>, non-precompiled or non-APSY procedures will not show up on chunk reports.</p></td></tr>
This is important because, unless the [[SirTune configuration statements#allcomp|ALLCOMP]] option was specified for the data collection portion of <var class="product">SirTune</var>, non-precompiled or non-APSY procedures will not show up on chunk reports.</p></td></tr>


<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 pre-compiled 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 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>


<tr><th>QUAD</th>
<tr><th>QUAD</th>
<td>By the current <var class="product">Model 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 User Language. Every User Language 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 204</var> internals expert, these breakdowns might provide some hints about overall application characteristics, even to programmers unfamiliar with <var class="product">Model 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 ch_size</th>
<td>By pieces of evaluating procedures. Every User Language 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 User Language that are compiled to produce object code (quads) of a specific number of bytes. This number of bytes is known as the chunk size (<i>ch_size</i>).
<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>
Thus a 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.</p>
Thus <code>REPORT STATE RUNG CHUNK 300</code> 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.</p>
<p>
<p>
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.</p>
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.</p>
<p>
<p>
A chunk in a procedure will also generally be larger than the size specified on a RESOLUTION statement applicable to the procedure.</p>
A chunk in a procedure will also generally be larger than the size specified on a <code>RESOLUTION</code> statement applicable to the procedure.</p>
<p>
<p>
Since different User Language 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.
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.
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.</p></td></tr>
Since the smallest possible User Language 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.</p></td></tr>


<tr><th>IFJOB</th>
<tr><th>IFJOB</th>
<td>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 ??? WHAT report.</td></tr>
<td>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 <code>REPORT STATE <i>xxx</i> WHAT</code> report.</td></tr>


<tr><th>IFCOMP</th>
<tr><th>IFCOMP</th>
<td>By originating IFAM2 compilation name. Caution must be used in
<td>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 ??? WHAT report.</td></tr>
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 <code>REPORT STATE <i>xxx</i> WHAT</code> report.</td></tr>


<tr><th>IFJCOMP</th>
<tr><th>IFJCOMP</th>
Line 471: Line 447:
It has the disadvantage that if an identical compilation is used by two jobs, the totals for these compilations will not be combined.
It has the disadvantage that if an identical compilation is used by two jobs, the totals for these compilations will not be combined.
<p>
<p>
This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE ??? WHAT report.</p></td></tr>
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.</p></td></tr>


<tr><th>IFFUNC</th>
<tr><th>IFFUNC</th>
<td>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 ??? WHAT 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 ch_size</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 (<i>ch_size</i>). Thus a REPORT STATE RUNG IFCHUNK 256 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.
<p>
<p>
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.</p>
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.</p>
<p>
<p>
This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE ??? WHAT report. </p>
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. </p>
<p>
<p>
This report will produce no useful data on CMS. Under MVS, the IFINTF object deck shipped in the <var class="product">SirTune</var> object library must be linked with the IFAM2 load modules of interest for this report to produce useful information.</p></td></tr>
This report will produce no useful data on CMS. Under MVS, the <code>IFINTF</code> object deck shipped in the <var class="product">SirTune</var> object library must be linked with the IFAM2 load modules of interest for this report to produce useful information.</p></td></tr>
</table>
</table>


Line 492: Line 468:


Or, using XML, specify this:
Or, using XML, specify this:
<p class="code"><nowiki><report type="comp" state="rung">
<p class="code"><report type="comp" state="rung">
</nowiki></p>
</p>


Since a user is using CPU if and only if the user is running, that is,
Since a user is using CPU if and only if the user is running, that is,
Line 499: Line 475:
being compiled.
being compiled.


To get a breakdown of swapping users by individual lines within a procedure,
To get a breakdown of swapping users by individual lines within a procedure, enter the following in SIRTUNEI or TUNERPTI:
enter the following in SIRTUNEI or TUNERPTI:
<p class="code">REPORT STATE SWPG CHUNK 4
<p class="code"><nowiki>REPORT STATE SWPG CHUNK 4
</p>
</nowiki></p>


Since a chunk size of 4 is the smallest possible chunk size,
Since a chunk size of 4 is the smallest possible chunk size,
this guarantees that no two lines of User Language will be grouped together
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
in the report. Note that to produce this report, data must be collected
for state SWPG by <var class="product">SirTune</var>.
for state <code>SWPG</code> by <var class="product">SirTune</var>.
This would require a COLLECT statement ([[SirTune configuration statements#colstat|COLLect state [extra_data&#x5C;]])
This would require a [[SirTune configuration statements#colstat|COLLECT statement]] in SIRTUNEI for <var class="product">SirTune</var>.
in SIRTUNEI for <var class="product">SirTune</var>.


To get a breakdown of users waiting for journal I/O by evaluating procedure,
To get a breakdown of users waiting for journal I/O by evaluating procedure,
enter the following in SIRTUNEI or TUNERPTI:
enter the following in SIRTUNEI or TUNERPTI:
<p class="code"><nowiki>REPORT STATE WJRIO EVAL
<p class="code">REPORT STATE WJRIO EVAL
</nowiki></p>
</p>


To produce this report, data must be collected for state
To produce this report, data must be collected for state
BLKIN by <var class="product">SirTune</var>.
<code>BLKIN</code> by <var class="product">SirTune</var>.


It is possible to specify several breakdowns on a single REPORT STATE
It is possible to specify several breakdowns on a single <code>REPORT STATE</code> statement. For example:
statement. For example:
<p class="code">REPORT STATE WDISK WHAT EVAL CHUNK 1000
<p class="code"><nowiki>REPORT STATE WDISK WHAT EVAL CHUNK 1000
REPORT STATE WDISK EVAL CHUNK 100 CHUNK 10
REPORT STATE WDISK EVAL CHUNK 100 CHUNK 10
</nowiki></p>
</p>
requests breakdown of users waiting for disk I/O by general activity
requests breakdown of users waiting for disk I/O by general activity
category (WHAT), procedure being evaluated, and chunks of 1000, 100, and 10
category (WHAT), procedure being evaluated, and chunks of 1000, 100, and 10 in the procedures being evaluated.
in the procedures being evaluated.


<div id="repsumm"></div>
<div id="repsumm"></div>
==REPORT SUMMARY==
===REPORT SUMMARY===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


Line 558: Line 530:


<div id="sysprm"></div>
<div id="sysprm"></div>
==REPORT SYSPARM==
===REPORT SYSPARM===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


Line 577: Line 549:


<div id="whatc"></div>
<div id="whatc"></div>
==REPORT WHATC | WHATCM | WHATCS  TOTAL | CHUNK ch_size==
===REPORT WHATC | WHATCM | WHATCS  TOTAL | CHUNK ch_size===
<!--Caution: <div> above-->
<!--Caution: <div> above-->


Line 631: Line 603:


<div id="toparm"></div>
<div id="toparm"></div>
==The TOP parameter==
===The TOP parameter===
<!--Caution: <div> above-->
<!--Caution: <div> above-->



Revision as of 01:16, 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 (|).

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.

REPORT CSECT | CSECTM | CSECTS TOTAL | CHUNK ch_size

The CSECT/CSECTM/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 shops 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.

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 five database file tables are the FCT, Table A, Table B, Table C, and Table D. 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, COLLECT DISKIO must have been specified in the SirTune data collection facilities input stream (SIRTUNEI).

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

REPORT DISKIO TOTAL

To produce a report breaking down waits on disk I/O by tables within files, code 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, code 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

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.

REPORT QUADC | QUADCM | QUADCS TOTAL | CHUNK ch_size

The QUADC/QUADCM/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.

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.

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.

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 "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".

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 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.
QUAD By the current Model 204 quad being evaluated. Quads are the internal representation of User Language. Every User Language 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.

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 dataset.

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.

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 datasets collected with the SirTune data collecter version 7.0 and later. For sample datasets created with earlier SirTune data collectors, the REPORT 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.

REPORT WHATC | WHATCM | WHATCS TOTAL | CHUNK ch_size

The WHATC/WHATCM/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|M|S 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 (MAPcore) 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 would list the top 50 evaluating procedures if no TOP statements appear in SIRTUNEI:

REPORT STATE RUNG EVAL

The first report below would list the top 10 evaluating procedures, while the second report would list 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, simply code:

REPORT STATE RUNG EVAL TOP 100

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

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