SirTune reports: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<!--Page automatically generated by CMSTOWIK EXEC and will be
** automatically replaced ** -- any manual edits will be lost.
You've been warned.  ..  (Page built by JAL at the SIRIUS VM; file: FUNPGNEW SYSUT2) -->
<!-- Page name: SirTune reports-->
==Overview==
==Overview==
The <var class="product">SirTune</var> reporting module  produces a listing that is made up of one or more reports.
The <var class="product">SirTune</var> reporting module  produces a listing that is made up of one or more reports.
Line 10: Line 6:
In <var class="product">SirTune</var> versions prior to 7.2, reporting is done via <code>SIRTUNER</code>, an assembler module that is separately distributed and installed.
In <var class="product">SirTune</var> versions prior to 7.2, reporting is done via <code>SIRTUNER</code>, an assembler module that is separately distributed and installed.
In version 7.2 and later, reporting is done by <code>SIRTUNEREPORT</code>,
In version 7.2 and later, reporting is done by <code>SIRTUNEREPORT</code>,
a <var class="product">SOUL</var> program that is distributed in the <var class="product">[[RKTools]]</var> file <code>SIRIUS</code>.
a <var class="product">SOUL</var> program that is distributed in the <var class="product">[[RKTools]]</var> file <code>SIRIUS</code> (prior to version 7.7) or <code>M204PROC</code> file (as of RKTools 7.7).
   
   
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.
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.


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,
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.
as it can consume considerable resources from an Online job.
 
If the SIRIUS file cannot be allocated to a batch job, SIRTUNEREPORT
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:
can be moved to another procedure file.
To run SIRTUNEREPORT from another file:
<ol>
<ol>
<li>Move SIRTUNEREPORT and the
<li>Move SIRTUNEREPORT and the
included procedure <code>SHARED_REPORT</code> to the new file.
included procedure <code>SHARED_REPORT</code> to the new file.


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


Line 33: Line 26:


===Use REPORT or <report> to specify which reports to produce===
===Use REPORT or <report> to specify which reports to produce===
If not suppressed with the [[SirTune Report Generator configuration#REPort report_desc &#124; NODEFAULT|REPORT NODEFAULT]] statement, the reporting module always produces a default set of reports.
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.


Line 46: Line 39:
In XML format, these default reports are specified like this:
In XML format, these default reports are specified like this:
<p class="code"><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>
</p>
</p>
Line 62: Line 55:
</blockquote>
</blockquote>


In addition to these, a variety of other reports can be produced upon request. These reports can are requested via the REPORT statement (see
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 [[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]]).
Line 71: Line 64:
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>


Line 80: Line 73:
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.
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.


===Sample data set restrictions===
===Sample data set restrictions===
Line 97: Line 92:
alternative parameters are separated by vertical bars (<tt>|</tt>).
alternative parameters are separated by vertical bars (<tt>|</tt>).


<div id="rptinfo"></div>
===<b id="rptinfo"></b>INFO reports===
===INFO reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
<p class="syntax">REPORT INFO
<p class="syntax">REPORT INFO </p>
</p>
 
The <code>INFO</code> report provides environmental information about the <var class="product">Model 204</var> ONLINE program and <var class="product">SirTune</var> data collection settings used in producing
The <code>INFO</code> report provides environmental information about the <var class="product">Model&nbsp;204</var> Online program and <var class="product">SirTune</var> data collection settings used in producing
the sample data set.
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 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.).
Line 114: Line 107:
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:
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
<p class="code"> Sampling Rate              =    10.00 seconds
  Number of samples processed =    13359
Number of samples processed =    13359
  Number of samples missed    =    0
Number of samples missed    =    0
  Number of samples skipped  =    13347
Number of samples skipped  =    13347
  Number of samples discarded =    3  (MAXDELAY = 10)
Number of samples discarded =    3  (MAXDELAY = 10)
  Number of samples accepted  =    9
Number of samples accepted  =    9
  States collected            =    RUNG REDY BLKIN BLKON
States collected            =    RUNG REDY BLKIN BLKON
  Extra data collected        =    DISKIO CFR
Extra data collected        =    DISKIO CFR
  Options                    =
Options                    =
  Job start time              =    Sunday, 23 October 2016 00:18:33
Job start time              =    Sunday, 23 October 2016 00:18:33
  First sample processed      =    Monday, 24 October 2016 13:23:20
First sample processed      =    Monday, 24 October 2016 13:23:20
  Last sample processed      =    Monday, 24 October 2016 13:25:10
Last sample processed      =    Monday, 24 October 2016 13:25:10
  SIRTUNE version            =    8.3
SIRTUNE version            =    8.3
  SirTune stopped because          End of data in sample dataset</p>
SirTune stopped because          End of data in sample dataset</p>
 
Notes:
<ul>
<li>The <code>Sampling Rate</code> times the <code>Number of samples processed</code> gives the overall time span of the journal. </li>


The <em>sampling rate</em> times the <em>number of samples processed</em> will give you the overall length of the timespan of the journal. <em>Samples missed</em> reflects the count of samples <var class="product">SirTune</var> failed to collect, the <em>number of sample skipped</em>, usually because the user specified a narrower timespan than was represented in the full journal, and the <em>number of samples discarded</em>: Samples get discarded when more than 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 (it certainly indicates that <var class="product">SirTune</var> was not getting the resources it needed when it tried to take a sample).
<li>The <code>Number of samples missed</code> reflects the count of samples <var class="product">SirTune</var> failed to collect. </li>


The rest of the info 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 start of journal, time brackets for this report, the <var class="product">SirTune</var> version and the reason data collection stopped - <em>End of sample dataset</em> indicates normal completion.
<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>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>
 
<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>


===CFRROOT reports===
===CFRROOT reports===
Line 188: Line 190:


The <code>CSECT</code> report shows CPU usage by CSECT.
The <code>CSECT</code> report shows CPU usage by CSECT.
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.
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.
If not running the MP/204 feature or running the feature with 0 subtasks, CSECT is equivalent to CSECTM, and CSECTS is always 0.
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.  
<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>
<p>
For example, to get a CSECTM report: </p>
For example, to get a <code>CSECTM</code> report: </p>
<p class="code"><report type="csect" task="maintask">
<p class="code"><report type="csect" task="maintask">
</p>
</p>
Line 218: Line 220:
</ul>
</ul>


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


<div id="diskio"></div>
===<b id="diskio"></b>DISKIO reports===
===DISKIO reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
Line 246: Line 245:
</table>
</table>


To produce the DISKIO reports, you must specify this [[SirTune configuration statements#colstat|COLLECT statement]] in the <var class="product">SirTune</var> data collection input stream (<code>SIRTUNEI</code>):  
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>):  
<p class="code">COLLECT DISKIO</p>
<p class="code">COLLECT DISKIO</p>
<ul>
<ul>
Line 268: Line 267:
</p>
</p>


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


The <code>QUADC</code> report breaks down all CPU usage by quad and the CSECTs. Since the breakdown is a CSECT-level breakdown, the   
The <code>QUADC</code> report breaks down all CPU usage by quad and the CSECTs. Since the breakdown is a CSECT-level breakdown, the   
[[SirTune Report Generator configuration#mpvirt|MPVIRT]] configuration parameter has no effect on the QUADCM and QUADCS reports &mdash; only the
[[SirTune report generation#mpvirt|MPVIRT]] configuration parameter 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.


Line 285: Line 282:
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"><report type="quadc" task="maintask">
<p class="code"><report type="quadc" task="maintask">
</p>
</p>
Line 317: Line 314:
<p class="code">REPORT QUADC TOTAL CHUNK 512 CHUNK 64
<p class="code">REPORT QUADC TOTAL CHUNK 512 CHUNK 64
</p>
</p>
<p class="note"><b>Note:</b> The [[SirTune Report Generator configuration#mapcore|MAPCORE]] statement in the report configuration input specifies that instructions outside of the loaded <var class="product">Model&nbsp;204</var> module
<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
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===
===REPSTAT reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
<p class="syntax">REPORT REPSTAT [RESET]
<p class="syntax">REPORT REPSTAT [RESET]
</p>
</p>
The <code>REPSTAT</code> report provides information on the performance of the report
The <code>REPSTAT</code> report provides information on the performance of the report generator itself.  
generator itself.  
<p>
<p>
The REPSTAT report breaks down the time for the report generation process into its individual components, CPU time, waiting for input buffer time, waiting for
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 REPSTAT report provides information
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>
on above-the-line (31 bit) and below-the-line (24 bit) storage usage.</p>


<p class="note"><b>Note:</b> This report is only of interest if the performance or storage usage of SIRTUNER is a concern. It is not supported in <var class="product">SirTune</var> 7.2 and later (using the SIRTUNEREPORT <var class="product">SOUL</var> program), and a <code>repstat</code> keyword is <i>not</i> supported as a report type option in the XML format for specifying report configuration parameters ([[SirTune Report Generator configuration#templt|A template for the XML input]]).
<p class="note"><b>Note:</b> This report is only of interest if the performance or storage usage of SIRTUNER is a concern. It is not supported in <var class="product">SirTune</var> 7.2 and later (using the SIRTUNEREPORT <var class="product">SOUL</var> program), and a <code>repstat</code> keyword is <i>not</i> supported as a report type option in the XML format for specifying report configuration parameters ([[SirTune report generation#templt|A template for the XML input]]).
</p>
</p>


Line 352: 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 <code>TWOPASS</code> statement, the REPSTAT report shows results only in the second report-generation pass.
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.


===SERVIO reports===
===SERVIO reports===
Line 365: Line 358:
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===
===SERVUSE reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
Line 399: 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 as the collected state rather than as "OSERVW."</p>
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>
<p>
<p>
This state is of particular interest in this report because it indicates the size of server that users required but were not able to get immediately. Thus, a large average for number-of-users in state OSERVW for server sizes
This state is of particular interest in this report because it indicates the size of server that users required but were not able to get immediately. Thus, a large average for number-of-users in state OSERVW for server sizes
Line 420: 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 426: 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===
===STATE reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
Line 461: Line 450:
</ul>
</ul>
<p>
<p>
This is important because, unless the [[SirTune configuration statements#allcomp|ALLCOMP]] option was specified for the data collection portion of <var class="product">SirTune</var>, non-precompiled or non-APSY procedures will not show up on chunk reports.</p></td></tr>
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>
Line 492: Line 481:


<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>
Line 531: Line 520:
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 <code>SWPG</code> by <var class="product">SirTune</var>.
for state <code>SWPG</code> by <var class="product">SirTune</var>.
This would require a [[SirTune configuration statements#colstat|COLLECT statement]] in SIRTUNEI for <var class="product">SirTune</var>.
This would require a [[SirTune data collection statements#colstat|COLLECT statement]] 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,
Line 548: Line 537:
category (WHAT), procedure being evaluated, and chunks of 1000, 100, and 10 in the procedures being evaluated.
category (WHAT), procedure being evaluated, and chunks of 1000, 100, and 10 in the procedures being evaluated.


<div id="repsumm"></div>
===<b id="repsumm"></b>SUMMARY reports===
===SUMMARY reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
<p class="syntax">REPORT SUMMARY
<p class="syntax">REPORT SUMMARY
</p>
</p>
The SUMMARY report provides a summary of the average number of users in each sample, broken down by user state and wait type.
The <code>SUMMARY</code> 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 <code>REPORT SUMMARY</code> control-card statement is two elements:
If using XML to configure the report, the XML equivalent to a <code>REPORT SUMMARY</code> control-card statement is two elements:
Line 571: Line 558:
<li>There are never any users waiting for server.</li>
<li>There are never any users waiting for server.</li>


<li>No [[SirTune configuration statements#colstat|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===
===SYSPARM reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
<p class="syntax">REPORT SYSPARM
<p class="syntax">REPORT SYSPARM
</p>
</p>
The SYSPARM report provides the values of all system and scheduler parameters in the Online associated with the sample dataset.
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.
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 data sets
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
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 data sets 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.
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.
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.


<div id="whatc"></div>
===<b id="whatc"></b>WHATC, WHATCM, and WHATCS reports===
===WHATC, WHATCM, and WHATCS reports===
<!--Caution: <div> above-->
<p>
<p>
Syntax: </p>
Syntax: </p>
<p class="syntax">REPORT {WHATC | WHATCM | WHATCS} TOTAL | CHUNK <span class="term">ch_size</span>
<p class="syntax">REPORT {WHATC | WHATCM | WHATCS} TOTAL | CHUNK <span class="term">ch_size</span>
</p>
</p>
The WHATC, WHATCM, and WHATCS reports break down <var class="product">Model&nbsp;204</var> CPU
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&nbsp;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&nbsp;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&nbsp;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 and CSECTM.
([[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.


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
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
Line 611: Line 593:


<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 WHATC report variations: specify a <code>task=maintask</code> or <code>task=subtask</code> attribute for a <code>type=whatc</code> report to invoke, repectively, a WHATCM or a WHATCS report.
<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"><report type="whatc" task="subtask">
<p class="code"><report type="whatc" task="subtask">
</p>
</p>
</blockquote>
</blockquote>


WHATC, WHATCM, and WHATCS reports are further qualified by the <code>TOTAL</code> or <code>CHUNK</code> 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&nbsp;204</var> activities
<li>TOTAL requests a breakdown of CPU usage by <var class="product">Model&nbsp;204</var> activities
Line 642: Line 624:
<p class="code">REPORT WHATC TOTAL CHUNK 512 CHUNK 64
<p class="code">REPORT WHATC TOTAL CHUNK 512 CHUNK 64
</p>
</p>
<p class="note"><b>Note:</b> The [[SirTune Report Generator configuration#mapcore|MAPCORE]] statement in the report configuration input specifies that instructions outside of the loaded <var class="product">Model&nbsp;204</var> module should be treated as a "CSECT," allowing analysis of CPU usage in the entire address space.
<p class="note"><b>Note:</b> The [[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>
</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 [[SirTune Report Generator configuration#TOP num_top|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
statement would list the top 50 evaluating procedures if no TOP statements
appear in SIRTUNEI:
<p class="code">REPORT STATE RUNG EVAL
<p class="code">REPORT STATE RUNG EVAL
</p>
</p>

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