SirTune data collection under MVS: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (add link)
m (add word)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
How you invoke <var class="product">SirTune</var> depends on its version.
The data collection portion of <var class="product">SirTune</var> is part of the <var class="product">[[Sirius Mods]]</var> object
as of SirTune 7.1, and it was integrated into the Model&nbsp;204 nucleus as of Model&nbsp;204 7.5.


==<b id="vercurr"></b>Versions of <var class="product">SirTune</var> after 1.5==
Depending on your SirTune and Model&nbsp;204 versions, then, you might need to link edit the <var class="product">Sirius Mods</var> with the <var class="product">Model&nbsp;204</var> Online module.  
The data collection portion of <var class="product">SirTune</var> is part of the <var class="product">Sirius Mods</var> object.
The data collector becomes available once the <var class="product">Sirius Mods</var> is link edited with the <var class="product">Model&nbsp;204</var> Online module.


===<b id="stunjcl"></b>JCL for SirTune===
This page describes how to modify your Model&nbsp;204 Online job to accommodate SirTune.
To invoke <var class="product">SirTune</var>,
 
The EXEC statement in your JCL should directly invoke the <var class="product">Model&nbsp;204</var> load module:
==<b id="stunjcl"></b>JCL for SirTune==
To invoke <var class="product">SirTune</var>, the EXEC statement in your JCL should directly invoke the <var class="product">Model&nbsp;204</var> load module:
<p class="code"><nowiki>//ONLINE  EXEC PGM=ONLINE,...
<p class="code"><nowiki>//ONLINE  EXEC PGM=ONLINE,...
</nowiki></p>
</nowiki></p>


This statement differs from that required for version 1.5 and earlier of <var class="product">SirTune</var>
In addition, the JCL that invokes <var class="product">Model&nbsp;204</var> must include a DD statement for the SIRTUNED dataset (see [[#stundds|The SirTune DD statements]]).
(which is described in [[#invstun|Invoking the SIRTUNE module]]).
Then, if <var class="product">SirTune</var> is authorized for use at your site, the <var class="product">SirTune</var> data collector will be initialized.
 
In addition, the JCL that invokes <var class="product">Model 204</var> must include a DD statement for the SIRTUNED dataset (see [[#stundds|The SirTune DD statements]]).
Then, if <var class="product">SirTune</var> is authorized for use at your site, the <var class="product">SirTune</var>
data collector will be initialized.


If you are upgrading from an earlier version of <var class="product">SirTune</var>,
If you are upgrading from an earlier version of <var class="product">SirTune</var>,
no changes are necessary to the <var class="product">SirTune</var> DD statements you were using.
no changes are necessary to the <var class="product">SirTune</var> DD statements you were using.
However, if you specified SIRTUNEI configuration statements for the data collector, the PGM statement
However, if you specified SIRTUNEI configuration statements for the data collector, the PGM statement is ignored, since <var class="product">SirTune</var> no longer loads the <var class="product">Model&nbsp;204</var> ONLINE load module.
is ignored, since <var class="product">SirTune</var> no longer loads the <var class="product">Model 204</var> ONLINE load module.


If you want to prevent the <var class="product">SirTune</var> data collector from being initialized,
If you want to prevent the <var class="product">SirTune</var> data collector from being initialized, do either of the following:
do either of the following:
<ul>
<ul>
<li>Under z/OS or OS/390, include no SIRTUNED DD statement during initialization.</li>
<li>Under z/OS or OS/390, include no SIRTUNED DD statement during initialization.</li>
Line 47: Line 41:
</ul>
</ul>


===<b id="stundds"></b>The SirTune DD statements===
==<b id="stundds"></b>The SirTune DD statements==
<var class="product">SirTune</var> uses one or both of the DD statements described below.
<var class="product">SirTune</var> uses one or both of the DD statements described below.
<p class="note"><b>Note:</b> The SIRTUNEO dataset used in earlier versions of <var class="product">SirTune</var> is obsolete in versions of <var class="product">SirTune</var> after 1.5.
<p class="note"><b>Note:</b> The SIRTUNEO dataset used in earlier versions of <var class="product">SirTune</var> is obsolete in versions of <var class="product">SirTune</var> after 1.5.
Line 71: Line 65:
Simply allocate SIRTUNED at 20 megabytes (or less if disk space is
Simply allocate SIRTUNED at 20 megabytes (or less if disk space is
tight), and adjust the size based on experience.
tight), and adjust the size based on experience.
For more information on sizing SIRTUNED, see [[SirTune size requirement for SIRTUNED]].
For more information on sizing SIRTUNED, see [[#SirTune size requirement for SIRTUNED|SirTune size requirement for SIRTUNED]], below.
To keep available data from several runs, make SIRTUNED part of a GDG.</p></li>
To keep available data from several runs, make SIRTUNED part of a GDG.</p></li>


Line 82: Line 76:
which data is collected, the sampling rate, authorization to issue
which data is collected, the sampling rate, authorization to issue
MODIFY commands, and more.
MODIFY commands, and more.
For a list of the available statements, see [[SirTune configuration statements]].</p>
For a list of the available statements, see [[#SirTune data collection statements]].</p>
<p>
<p>
SIRTUNEI can have either fixed or variable format, and it can have any record length.</p></li>
SIRTUNEI can have either fixed or variable format, and it can have any record length.</p></li>
</ul>
</ul>


==Version 1.5 or earlier of SirTune==
==SirTune size requirement for SIRTUNED==
The data collection portion of <var class="product">SirTune</var> consists of a single load module called <code>SIRTUNE</code>.
{{Template: SirTune size requirement for SIRTUNED}}
 
===<b id="invstun"></b>Invoking the SIRTUNE module===
To have <var class="product">SirTune</var> collect data for a particular Online job, you must do the following so that
<var class="product">SirTune</var> will run <var class="product">Model&nbsp;204</var> as a subtask of SIRTUNE, collecting polling data as required:
<ul>
<li>Modify the JCL that invokes <var class="product">Model&nbsp;204</var> so that it invokes SIRTUNE instead. For example, to have <var class="product">SirTune</var> monitor an Online invoked with:
<p class="code">//ONLINE  EXEC PGM=ONLINE,REGION=4096K,TIME=1440,
//              PARM='LIBUFF=600,SYSOPT=155,NJBUFF=2'
</p>
<p>
Change the line to read:</p>
<p class="code">//ONLINE  EXEC PGM=SIRTUNE,REGION=4096K,TIME=1440,
//              PARM='LIBUFF=600,SYSOPT=155,NJBUFF=2'
</p></li>
 
<li>Place the SIRTUNE load module into the
same load library as the Online load library, or
concatenate the library containing the SIRTUNE load module
with the <var class="product">Model 204</var> load library.</li>
</ul>
 
<var class="product">SirTune</var> data collection should have no significant impact on the performance of the Online region.
 
If the <var class="product">Model&nbsp;204</var> load module that is being monitored with <var class="product">SirTune</var> must run authorized, the SIRTUNE load module must be placed
into an APF-authorized library.
 
If SIRTUNE is able to load <var class="product">Model&nbsp;204</var> but cannot sample for some reason
(including unknown <var class="product">Model 204</var> release, <var class="product">SirTune</var> expiration, or operation on an unauthorized CPU), <var class="product">Model&nbsp;204</var> will still proceed. This lets you leave SIRTUNE in place in your JCL while a temporary problem is being solved.
 
===<b id="stddv15"></b>The SIRTUNE DD statements===
The SIRTUNE load module uses as many as three DD statements: the first
(<code>SIRTUNED</code>) is required and specifies the data set to receive the collected data; the other two are optional:
<table class="thJustBold">
<tr><th>SIRTUNED</th>
<td>See [[#sirtuned|SIRTUNED]], above.</td></tr>
 
<tr><th>SIRTUNEI</th>
<td>See [[#sirtunei|SIRTUNEI]], above.</td></tr>
 
<tr><th>SIRTUNEO</th>
<td>This optional DD receives informational SIRTUNE messages. If this DD is not specified, these messages go to the MVS job log. SIRTUNEO must have LRECL greater than or equal to 80.</td></tr>
</table>
 
===<b id="stunxmp"></b>JCL example===
The following is an example of JCL that runs a BATCH204 job under <code>SIRTUNE</code> in an MVS environment.
 
<!-- get non-BATCH204 example -->
<p class="code"><nowiki>//DAILY204 JOB  (0),CLASS=C,MSGCLASS=A
//BATCH204 EXEC PGM=SIRTUNE,REGION=4096K,
//              PARM='SYSOPT=209,LIBUFF=1000'
//STEPLIB  DD  DSN=M204.V410.LOADLIB,DISP=SHR
//        DD  DSN=SIRIUS.LOAD,DISP=SHR
//SIRTUNEI DD  *
PGM BATCH204
/*
//SIRTUNED DD  DSN=SIRTUNE.SAMPLE.DATA,DISP=SHR
//CCAPRINT DD  SYSOUT=*
//CCAAUDIT DD  SYSOUT=*
//CCASNAP  DD  SYSOUT=*
//CCATEMP  DD  UNIT=WORK,SPACE=(CYL,(40,0))
//CCASTAT  DD  DSN=M204.CCASTAT.DISP=SHR
//POPDATA  DD  DSN=LOCAL.PROD.POPDATA,DISP=SHR
//POPPROC  DD  DSN=LOCAL.PROD.POPPROC,DISP=SHR
//CCAIN    DD  *
SPCORE=20000,MAXBUF=1000,MINBUF=50,SERVSIZE=300000
    .....
//
</nowiki></p>


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

Latest revision as of 22:18, 8 August 2017

The data collection portion of SirTune is part of the Sirius Mods object as of SirTune 7.1, and it was integrated into the Model 204 nucleus as of Model 204 7.5.

Depending on your SirTune and Model 204 versions, then, you might need to link edit the Sirius Mods with the Model 204 Online module.

This page describes how to modify your Model 204 Online job to accommodate SirTune.

JCL for SirTune

To invoke SirTune, the EXEC statement in your JCL should directly invoke the Model 204 load module:

//ONLINE EXEC PGM=ONLINE,...

In addition, the JCL that invokes Model 204 must include a DD statement for the SIRTUNED dataset (see The SirTune DD statements). Then, if SirTune is authorized for use at your site, the SirTune data collector will be initialized.

If you are upgrading from an earlier version of SirTune, no changes are necessary to the SirTune DD statements you were using. However, if you specified SIRTUNEI configuration statements for the data collector, the PGM statement is ignored, since SirTune no longer loads the Model 204 ONLINE load module.

If you want to prevent the SirTune data collector from being initialized, do either of the following:

  • Under z/OS or OS/390, include no SIRTUNED DD statement during initialization.
  • Set the SIRTUNE parameter to 0.

    SIRTUNE, which is only allowed as a parameter in the EXEC JCL statement, controls whether the SirTune data collector is initialized at the start of a Model 204 run.

    The SIRTUNE parameter can be set to either of these values:

    0 Disables initialization of the integrated SirTune product for a particular run.
    1 Enables initialization (this is the default).

    For example:

    //ONLINE EXEC PGM=ONLINE,PARM='SIRTUNE=0'

The SirTune DD statements

SirTune uses one or both of the DD statements described below.

Note: The SIRTUNEO dataset used in earlier versions of SirTune is obsolete in versions of SirTune after 1.5.

  • SIRTUNED

    This required DD specifies the data set that receives the data collected by SirTune. This data set must have variable blocked (VB) format, and it should generally have a large block size (>10000). If DCB information is not explicitly specified, the defaults selected by SirTune should be adequate for all but the most extreme cases.

    If SIRTUNED is preallocated under ISPF or its equivalent, the recommended blocksizes are 23,476 on a 3380 and 27,998 on a 3390. If this dataset fills up, SirTune will simply stop collecting data for the duration of the run. A 20 megabyte SIRTUNED should be sufficient for most shops, while a 50 megabyte SIRTUNED should be sufficient for almost any requirements.

    Since the only cost of running out of space in SIRTUNED is the loss of some data, it's not worth spending a lot of time trying to size SIRTUNED exactly. Simply allocate SIRTUNED at 20 megabytes (or less if disk space is tight), and adjust the size based on experience. For more information on sizing SIRTUNED, see SirTune size requirement for SIRTUNED, below. To keep available data from several runs, make SIRTUNED part of a GDG.

  • SIRTUNEI

    This optional DD specifies a data set that contains statements that alter the SirTune defaults. These statements allow control over the name of the Model 204 load module, the level of detail to which data is collected, the time intervals over which data is collected, the sampling rate, authorization to issue MODIFY commands, and more. For a list of the available statements, see #SirTune data collection statements.

    SIRTUNEI can have either fixed or variable format, and it can have any record length.

SirTune size requirement for SIRTUNED

It is recommended that you do not spend a lot of time trying to size SIRTUNED, because the consequences of under- or over-estimating the SIRTUNED space requirements are relatively benign. However, if you do want to size SIRTUNED, this section provides some basic rules of thumb for estimating the correct size.

A formula for the estimate

The size of SIRTUNED is mainly determined by these factors:

  • The number of lines of compilations saved. This is the number of lines in precompiled APSY procedures compiled in the run, or if the ALLCOMP statement is specified for SirTune, the number of lines of all compiled procedures. In any case, a line counts as 1 each time it is compiled.
  • The number of samples collected.
  • The average number of users for which data is collected per sample.

To estimate the number of lines of compilations saved when the ALLCOMP statement has not been specified, and when subsystems are not START'ed and STOP'ed multiple times in a run, simply total the number of lines in all precompiled procedures in START'ed subsystems. To get an estimate of this:

  1. Count the total number of precompiled procedures.
  2. Estimate the average number of lines per precompiled procedure by entering the editor for a representative sample of them.
  3. Multiply these two values.

Call the number of compiled lines COMP_LINES.

To estimate the number of samples, divide the number of seconds over which data is to be collected, by the sample interval length (1 or whatever was specified on the INTERVAL statement). Call this value NUM_SAMP.

The best guide to estimating the number of users for which data is collected per sample is the Model 204 performance monitor. There are certain worst-case values that one can assume, however:

  • If only state RUNG is being collected, at most 1 user will have data collected per sample, unless MP/204 is installed (in which case, the upper limit is 1 plus the number of subtasks).
  • If only REDY, RUNG, BLKIN, BLKIU, SWPGI, SWPGOW, SWPGOBN, and/or SWPGOBU states are being collected, the upper limit is the number of servers.
  • Otherwise, a crude upper limit is the number of users.

Call whatever value one comes up with AVG_USERS.

The total number of bytes required for SIRTUNED can be estimated by this:

100,000 + ( 12 * COMP_LINES ) + ( NUM_SAMP * 64 * ( 1 + AVG_USERS ) )

This estimator provides a fairly generous estimate without being excessive. To determine the number of disk tracks required, divide the number of bytes produced by this estimator by the number of bytes per track at the block size for SIRTUNED (46,952 is the default bytes per track on a 3380, and 55,996 is the default on a 3390).

An example estimate

Suppose a shop has 100,000 lines of pre-compiled User Language code, expects to collect samples over 8 hours at 1 per second, is collecting data for states RUNG, REDY, and BLKIN, and has 30 servers defined in the Online. These factors are clear:

COMP_LINES = 100,000 NUM_SAMP = 8 * 60 * 60 / 1 = 28,800

Since all the users in a collected state must be in a server, use the number of servers as a gross estimator for AVG_USERS, that is:

AVG_USERS = 30

This means that the estimated space requirements in this case is:

100,000 + ( 12 * 100,000 ) + 28,800 * 64 * ( 1 + 30 ) = 58,439,200

If the sample data was going to a 3380 with the SirTune default block size, it would require 1245 tracks or 83 cylinders.

The number of samples collected in this example is fairly extreme: generally there is not much benefit to collecting more than 10,000 samples. If sampling is limited to some key hours to restrict the number of samples collected to 10,000, the estimator becomes:

100,000 + ( 12 * 100,000 ) + 10,000 * 64 * ( 1 + 30 ) = 21,140,000

If the sample data in this case was going to a 3380 with the SirTune default block size, it would require 451 tracks or 31 cylinders.

See also