SirTune reports: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (more conversion cleanup)
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<!--Page automatically generated by CMSTOWIK EXEC and will be
==Overview==
** automatically replaced ** -- any manual edits will be lost.
The <var class="product">SirTune</var> reporting module  produces a listing that is made up of one or more reports.
You've been warned.  ..  (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->
These reports can be used to tune problem areas in an Online.
<!-- Page name: SirTune reports-->
<p></p>
===SIRTUNEREPORT replaces SIRTUNER===
The <var class="product">SirTune</var> reporting module  produces a listing that is made up of
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.
one or more reports.
In version 7.2 and later, reporting is done by <code>SIRTUNEREPORT</code>,
These reports can be used to tune problem areas in an Online
a <var class="product">SOUL</var> program that is distributed in the <var class="product">[[RKTools]]</var> file <code>SIRIUS</code> (prior to version 7.7) or <code>M204PROC</code> file (as of RKTools 7.7).
job.
<p></p>
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.
In <var class="product">SirTune</var> 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 <var class="product">SOUL</var> program that is distributed in the <var class="product">UL/SPF</var> file SIRIUS.
<p></p>
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 <code>sirtuneReport</code> method of
the Dataset 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, as it can consume considerable resources from an Online job. Or, RKTools version 7.7 users can run SIRTUNEREPORT from the [[RKWeb]] interface (<code>Build > Tune Reports</code>) and view the output in their browser.
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 <code>SIRIUS</code> or <code>M204PROC</code> file cannot be allocated to a batch job, SIRTUNEREPORT can be moved to another procedure file. To run SIRTUNEREPORT from another file:
If the SIRIUS file cannot be allocated to a batch job, SIRTUNEREPORT
can be moved to another procedure file.
<p></p>
<p></p>
To run SIRTUNEREPORT from another file:
<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
<li>Change the single reference to <code>SIRIUS</code> or <code>M204PROC</code> to the new file name (this reference is an <var>Include</var> statement near the top of the procedure, after the variable declarations).
reference to SIRIUS to the new file name (this reference is an
INCLUDE 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 generation#report|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"/>
   <report type="waittype">
   <report type="waittype"/>
   <report type="what" state="rung">
   <report type="what" state="rung"/>
   <report type="eval" state="rung">
   <report type="eval" state="rung"/>
   <report type="eval" state="rung" chunk="4000">
   <report type="eval" state="rung" chunk="4000"/>
   <report type="eval" state="rung" chunk="400">
   <report type="eval" state="rung" chunk="400"/>
   <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 73: Line 55:
</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 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):
<ul>
<ul>
<li>The completeness of the reports in pointing out problem areas.
<li>The completeness of the reports in pointing out problem areas. </li>
<li>The ease with which the reports can be read.
<li>The ease with which the reports can be read. </li>
<li>The CPU and storage costs of producing the reports.
<li>The CPU and storage costs of producing the reports. </li>
</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.
In theory, you can suppress the <code>INFO</code> report, but there is no good reason to do it: The <code>INFO</code> report (one of the defaults) describes the Model&nbsp;204 environment, and also the selection criteria for the report and the sampling characteristics of the SirTune data collection. Without this information, it is difficult to make sense of the specific performance reports.
Optional parameters are listed in brackets (<tt>[</tt><tt>]</tt>) and
 
===Sample data set restrictions===
<ul>
<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 data set.</li>
 
<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 data set.</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>
 
==The SirTune reports==
In the individual Sirtune report descriptions in this page,
optional parameters are listed in brackets (<tt>[</tt><tt>]</tt>) and
alternative parameters are separated by vertical bars (<tt>|</tt>).
alternative parameters are separated by vertical bars (<tt>|</tt>).
<blockquote class="note"><b>Notes:</b>  
 
===<b id="rptinfo"></b>INFO reports===
<p>
Syntax: </p>
<p class="syntax">REPORT INFO </p>
 
The <code>INFO</code> report provides environmental information about the <var class="product">Model&nbsp;204</var> Online program and <var class="product">SirTune</var> data collection settings used in producing
the sample data set.
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.).
 
This is one of the default reports produced by SirTune.
It is recommended that this report always be included in SirTune output,
because it establishes the context of all other reports.
 
In addition to an environmental summary, the <code>INFO</code> report provides a summary of <var class="product">SirTune</var>'s data collection activity, which looks like this:
 
<p class="code"> Sampling Rate              =    10.00 seconds
Number of samples processed =    13359
Number of samples missed    =    0
Number of samples skipped  =    13347
Number of samples discarded =    3  (MAXDELAY = 10)
Number of samples accepted  =    9
States collected            =    RUNG REDY BLKIN BLKON
Extra data collected        =    DISKIO CFR
Options                    =
Job start time              =    Sunday, 23 October 2016 00:18:33
First sample processed      =    Monday, 24 October 2016 13:23:20
Last sample processed      =    Monday, 24 October 2016 13:25:10
SIRTUNE version            =    8.3
SirTune stopped because          End of data in sample dataset</p>
 
Notes:
<ul>
<ul>
<li>Due to format changes in the sample dataset, only the SIRTUNEREPORT
<li>The <code>Sampling Rate</code> times the <code>Number of samples processed</code> gives the overall time span of the journal. </li>
program can process a <var class="product">SirTune</var> version 7.2 and later sample dataset.</li>
 
<li>The <code>Number of samples missed</code> reflects the count of samples <var class="product">SirTune</var> failed to collect. </li>
 
<li>A non-zero <code>Number of samples skipped</code> is usually due to a specified time span being narrower than that represented in the full journal; the skipped samples are outside the selected date/time range. </li>


<li>Due to format changes in the sample dataset, only releases 1.6 and
<li>The <code>Number of samples discarded</code> reports samples discarded when more than [[SirTune report generation#MAXDelay max_msec|MAXDELAY]] milliseconds pass between the time <var class="product">SirTune</var> wanted to collect the sample and when it actually did. A significant number of discarded samples might indicate the Online is not getting the resources it needs &mdash; it certainly indicates that <var class="product">SirTune</var> was not getting the resources it needed when it tried to take a sample. </li>
later of SIRTUNER can process a <var class="product">SirTune</var> version 7.0 and later sample dataset.</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>The rest of the report shows the user's data collection settings (useful if you request a report and find that the necessary data is not in the collection for that report), the journal's starting time, time brackets for this report, the <var class="product">SirTune</var> version, and the reason data collection stopped (<code>End of data in sample dataset</code> indicates normal completion). </li>
</ul>
</ul>
</blockquote>


==REPORT CFRROOT==
===CFRROOT reports===
The CFRROOT report can be used to determine the root bottleneck
<p>
behind critical file resource enqueuing.
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.
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 120: Line 150:
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 132: Line 160:
<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 150: Line 180:
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===
<p></p>
<p>
The CSECT/CSECTM/CSECTS reports break down <var class="product">Model 204</var> CPU usage by CSECT.
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
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.
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 generation#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 <code>CSECTM</code> or a <code>CSECTS</code> report.  
<p class="code"><nowiki><report type="csect" task="maintask">
<p>
</nowiki></p>
For example, to get a <code>CSECTM</code> 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 512 bytes, and by chunks of 64 bytes:
For example, this statement requests a breakdown of CPU usage by entire CSECTs, by chunks of
<p class="code">REPORT CSECT TOTAL CHUNK 512 CHUNK 64
512 bytes, and by chunks of 64 bytes:
</p>
<p class="code"><nowiki>REPORT CSECT TOTAL CHUNK 512 CHUNK 64
<p class="note"><b>Note:</b> You can use the [[SirTune report generation#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.
</nowiki></p>
<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>
===<b id="diskio"></b>DISKIO reports===
==REPORT DISKIO TOTAL | TABLE | CHUNK ch_size==
<p>
<!--Caution: <div> above-->
Syntax: </p>
 
<p class="syntax">REPORT DISKIO TOTAL | TABLE | CHUNK <span class="term">ch_size</span>
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:
</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><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 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 <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, you must specify this [[SirTune data collection statements#colstat|COLLECT statement]] in the <var class="product">SirTune</var> data collection input stream (<code>SIRTUNEI</code>):
in the <var class="product">SirTune</var> data collection facilities input stream (SIRTUNEI).
<p class="code">COLLECT DISKIO</p>
<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></li>


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


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 chunks of 10000 pages within each table within files, specify the following
files, code the following in SIRTUNEI:
<p class="code"><nowiki>REPORT DISKIO TABLE
</nowiki></p>
 
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:
in SIRTUNEI:
<p class="code"><nowiki>REPORT DISKIO CHUNK 10000
<p class="code">REPORT DISKIO CHUNK 10000
</nowiki></p>
</p></li>
</ul>


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>
===<b id="quadc"></b>QUADC, QUADCM, and QUADCS reports===
==REPORT INFO==
<p>
<!--Caution: <div> above-->
Syntax: </p>
 
<p class="syntax">REPORT {QUADC | QUADCM | QUADCS} TOTAL | CHUNK <span class="term">ch_size</span>
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
</p>
the sample dataset.
The <code>QUADC</code>, <code>QUADCM</code>, and <code>QUADCS</code> 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
This report includes settings of key <var class="product">Model 204</var> parameters
(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.
It is recommended that this report always be included in SIRTUNER output,
because it establishes the context of all other reports.
 
<div id="quadc"></div>
==REPORT QUADC | QUADCM | QUADCS  TOTAL | CHUNK ch_size==
<!--Caution: <div> above-->
 
The QUADC/QUADCM/QUADCS reports break down <var class="product">Model 204</var> CPU
usage by quad and CSECT. 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.
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 generation#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.


<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 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.
<blockquote class="note"><b>Note:</b> If using XML for the parameters ([[SirTune report generation#xmlrpti|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.
<p>
<p>
For example, to get a QUADCM report:</p>
For example, to get a <code>QUADCM</code> 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 296: Line 304:


<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 generation#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.
</p>
</p>


<div id="repstat"></div>
===<b id="repstat"></b>REPSTAT reports===
==REPORT REPSTAT [RESET]==
<p>
<!--Caution: <div> above-->
Syntax: </p>
<p class="syntax">REPORT REPSTAT [RESET]
</p>
The <code>REPSTAT</code> report provides information on the performance of the report generator itself.
<p>
The <code>REPSTAT</code> 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 <code>REPSTAT</code> report provides information on above-the-line (31 bit) and below-the-line (24 bit) storage usage.</p>


The REPSTAT report provides information on the performance of the report
<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 generation#templt|A template for the XML input]]).
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.
<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 338: Line 345:
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 <code>REPSTAT</code> report is used with the <code>TWOPASS</code> statement, the <code>REPSTAT</code> report shows results only in the second report-generation pass.
report will show results only in the second report-generation pass.


==REPORT SERVIO==
===SERVIO reports===
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
<p>
server data sets on disks that are not performing well because of contention problems,
Syntax: </p>
hardware problems, or server data sets with an unusually low level of activity,
<p class="syntax">REPORT SERVIO
perhaps because of under-allocated extents.
</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
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 <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>
===<b id="servuse"></b>SERVUSE reports===
==REPORT SERVUSE [CHUNK ch_size]==
<p>
<!--Caution: <div> above-->
Syntax: </p>
 
<p class="syntax">REPORT SERVUSE [CHUNK <span class="term">ch_size</span>]
The SERVUSE report provides a breakdown of users in particular states by
</p>
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 371: Line 379:
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 381: Line 390:
<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 <code>SERVUSE</code> 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
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 405: Line 411:
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 <code>SERVUSE</code> 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 411: Line 417:
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 <code>SERVUSE</code> 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>
===<b id="repst"></b>STATE reports===
==REPORT STATE state_name activity==
<p>
<!--Caution: <div> above-->
Syntax: </p>
 
<p class="syntax">REPORT STATE <span class="term">state_name</span> <span class="term">activity</span>
The STATE report sorts users in a specified state (<i>state_name</i>)
</p>
by their current processing activity (<i>activity</i>).
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>).
<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 427: Line 434:
<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 433: Line 440:


<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 440: Line 447:
<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 data collection 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 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 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 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 <i>ch_size</i></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>
<td>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.
<td>By originating IFAM2 compilation and jobname. This has an advantage over the <code>IFCOMP</code> 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.
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 <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 (<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 498: Line 505:


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 505: Line 512:
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 data collection 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>
===<b id="repsumm"></b>SUMMARY reports===
==REPORT SUMMARY==
<p>
<!--Caution: <div> above-->
Syntax: </p>
<p class="syntax">REPORT SUMMARY
</p>
The <code>SUMMARY</code> 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 559: Line 557:
<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 data collection 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>
===<b id="sysprm"></b>SYSPARM reports===
==REPORT SYSPARM==
<p>
<!--Caution: <div> above-->
Syntax: </p>
<p class="syntax">REPORT SYSPARM
</p>
The <code>SYSPARM</code> 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 <code>SYSPARM</code> report will be empty.
REPORT 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>
===<b id="whatc"></b>WHATC, WHATCM, and WHATCS reports===
==REPORT WHATC | WHATCM | WHATCS TOTAL | CHUNK ch_size==
<p>
<!--Caution: <div> above-->
Syntax: </p>
 
<p class="syntax">REPORT {WHATC | WHATCM | WHATCS} TOTAL | CHUNK <span class="term">ch_size</span>
The WHATC/WHATCM/WHATCS reports break down <var class="product">Model 204</var> CPU
</p>
The <code>WHATC</code>, <code>WHATCM</code>, and <code>WHATCS</code> 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 <code>WHATC</code> 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 generation#mpvirt|MPVirt]]) has no effect on the <code>WHATCM</code> and <code>WHATCS</code> 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 generation#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 <code>WHATCM</code> or a <code>WHATCS</code> report.
<p>
<p>
For example, to get a WHATCS report:</p>
For example, to get a <code>WHATCS</code> 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:
<code>WHATC</code>, <code>WHATCM</code>, and <code>WHATCS</code> 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 617: Line 610:
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 generation#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>


<div id="toparm"></div>
===<b id="toparm"></b>The TOP parameter===
==The TOP parameter==
<!--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 generation#TOP num_top|TOP statement]] before the REPORT statement. Thus, the following statement would list the top 50 evaluating procedures if no TOP statements appear in SIRTUNEI:
statement before the REPORT statement. Thus, the following
<p class="code">REPORT STATE RUNG EVAL
would list the top 50 evaluating procedures if no TOP statements
</p>
appear in SIRTUNEI:
<p class="code"><nowiki>REPORT STATE RUNG EVAL
</nowiki></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 670: Line 654:


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==

Latest revision as of 09:01, 15 August 2017

Overview

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

SIRTUNEREPORT replaces SIRTUNER

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deciding which reports to produce

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

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

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

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

Sample data set restrictions

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

The SirTune reports

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

INFO reports

Syntax:

REPORT INFO

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

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

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

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

Notes:

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

CFRROOT reports

Syntax:

REPORT CFRROOT

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

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

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

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

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

CSECT, CSECTM, and CSECTS reports

Syntax:

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

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

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

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

For example, to get a CSECTM report:

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

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

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

    REPORT CSECT TOTAL

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

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

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

    REPORT CSECT CHUNK 128

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

REPORT CSECT TOTAL CHUNK 512 CHUNK 64

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

DISKIO reports

Syntax:

REPORT DISKIO TOTAL | TABLE | CHUNK ch_size

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

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

This breakdown is generally only useful when using extremely large tables. Even in these cases, it is recommended that ch_size be set to a large value (>1000) to produce meaningful results.

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

COLLECT DISKIO

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

    REPORT DISKIO TOTAL

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

    REPORT DISKIO TABLE

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

    REPORT DISKIO CHUNK 10000

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

REPORT DISKIO TOTAL TABLE CHUNK 5000

QUADC, QUADCM, and QUADCS reports

Syntax:

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

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

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

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

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

For example, to get a QUADCM report:

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

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

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

    REPORT QUADC TOTAL

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

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

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

    REPORT QUADC CHUNK 128

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

REPORT QUADC TOTAL CHUNK 512 CHUNK 64

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

REPSTAT reports

Syntax:

REPORT REPSTAT [RESET]

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

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

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

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

REPORT REPSTAT RESET REPORT STATE RUNG CHUNK 100 REPORT REPSTAT

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

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

SERVIO reports

Syntax:

REPORT SERVIO

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

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

SERVUSE reports

Syntax:

REPORT SERVUSE [CHUNK ch_size]

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

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

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

The breakdowns are provided by the following states:

  • REDYR

    Running or ready users.

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

    Users swapping into a server.

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

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

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

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

  • BLKIN

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

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

  • BLKIU

    Users blocked in server waiting on user input.

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

  • OSERVN

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

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

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

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

STATE reports

Syntax:

REPORT STATE state_name activity

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

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

The activities are described below:

WHAT By the generic activity groupings used by Model 204 in its "WHAT" flag settings. The most common of these activities is compiling, loading, and evaluating SOUL procedures.
COMP By the name of the procedure(s) being compiled. Generally, this report is not of interest unless the WHAT report indicates a significant amount of resource usage in compilation.
LOAD By the name of the precompiled APSY procedure(s) being loaded. Generally, this report is not of interest unless the WHAT report indicates a significant amount of resource usage in loading.
EVAL By the name of the procedure(s) being evaluated. This report is useful in determining:
  • Which procedures are worth looking at in more detail
  • Whether any non-precompiled or non-APSY procedures are significant resource consumers.

This is important because, unless the ALLCOMP option was specified for the data collection portion of SirTune, non-precompiled or non-APSY procedures will not show up on chunk reports.

EVALI By the name of the innermost procedure(s) being evaluated. This report is useful in environments where the same procedures are INCLUDE'd in several different precompiled APSY procedures. By getting a state breakdown by EVALI, all resource usage that occurs while running an INCLUDE'd procedure gets assigned to the INCLUDE'd procedure. This makes it possible to determine the possible gains from tuning such a procedure.
QUAD By the current Model 204 quad being evaluated. Quads are the internal representation of SOUL. Every SOUL statement maps to one or more quads.

Each $function is considered a separate quad in this breakdown.

While a breakdown by quad might generally only be of interest to a Model 204 internals expert, these breakdowns might provide some hints about overall application characteristics, even to programmers unfamiliar with Model 204 internals. The $function breakdown could be of particular interest in shops that have many and/or complex in-house $functions.

CHUNK ch_size By pieces of evaluating procedures. Every SOUL procedure can be broken up into an arbitrary number of pieces. SirTune allows grouping lines of procedure in "chunks." A chunk is a group of lines in SOUL that are compiled to produce object code (quads) of a specific number of bytes. This number of bytes is known as the chunk size (ch_size).

Thus REPORT STATE RUNG CHUNK 300 breaks up procedures into chunks that correspond to approximately 300 bytes of compiled code (quads). A user in a particular state while evaluating a procedure is always in exactly one chunk. A "chunk" report will present each chunk as the corresponding line numbers of the source procedure.

Chunks can never cross INCLUDE statement boundaries. In addition, chunks can be terminated by the end of a procedure. For this reason, some chunks in a CHUNK report might actually be smaller than the chunk size specified.

A chunk in a procedure will also generally be larger than the size specified on a RESOLUTION statement applicable to the procedure.

Since different SOUL statements compile to different numbers of bytes, the actual size of the chunks will generally not be exactly the chunk size specified on the REPORT statement. For this reason, the actual size of each chunk is displayed on all CHUNK reports. Since the smallest possible SOUL chunk is 4 bytes, a chunk size of 1 is equivalent to a chunk size of 4 and a chunk size of 30 is equivalent to a chunk size of 32.

IFJOB By originating IFAM2 jobname. This can be useful in determining which IFAM jobs are generating a lot of activity. This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFCOMP By originating IFAM2 compilation name. Caution must be used in this report, because the same compilation name can be used by many different programs for many different purposes. This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFJCOMP By originating IFAM2 compilation and jobname. This has an advantage over the IFCOMP report: it will not combine two identically named but different compilations for two different jobs.

It has the disadvantage that if an identical compilation is used by two jobs, the totals for these compilations will not be combined.

This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.

IFFUNC By IFAM2 function name (IFFIND, IFPUT, etc.). This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.
IFCHUNK ch_size By pieces of IFAM2 load modules. Every IFAM2 load module can be broken up into an arbitrary number of pieces. SirTune allows grouping bytes of code in "chunks."

A chunk is a range of offsets in the load module of a specific number of bytes. This number of bytes is known as the chunk size (ch_size). Thus REPORT STATE RUNG IFCHUNK 256 breaks up load modules into chunks of 256 bytes.

This report lists usage by IFAM2 load module name and offset within the load module. For this report to be useful, the offsets withing the load modules must be converted to offsets within specific CSECTs. This can be done use a load map for the load module. Offsets within CSECTs must then be converted to source statement offsets, using compiler listings if a higher level language was used to generate the CSECTs.

This report is not likely to be of interest unless IFAM2 shows up as significant on a REPORT STATE xxx WHAT report.

This report will produce no useful data on CMS. Under MVS, the IFINTF object deck shipped in the SirTune object library must be linked with the IFAM2 load modules of interest for this report to produce useful information.

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

REPORT STATE RUNG COMP

Or, using XML, specify this:

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

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

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

REPORT STATE SWPG CHUNK 4

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

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

REPORT STATE WJRIO EVAL

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

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

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

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

SUMMARY reports

Syntax:

REPORT SUMMARY

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

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

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

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

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

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

SYSPARM reports

Syntax:

REPORT SYSPARM

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

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

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

WHATC, WHATCM, and WHATCS reports

Syntax:

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

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

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

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

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

For example, to get a WHATCS report:

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

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

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

    REPORT WHATC TOTAL

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

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

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

    REPORT WHATC CHUNK 128

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

REPORT WHATC TOTAL CHUNK 512 CHUNK 64

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

The TOP parameter

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

REPORT STATE RUNG EVAL

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

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

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

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

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

REPORT STATE RUNG EVAL TOP 100

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

REPORT DISKIO TABLE TOP 75

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

REPORT STATE RUNG TOP 100 EVAL

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

TOP 60 REPORT STATE RUNG CHUNK 1000 CHUNK 100 TOP 100

See also