SirTune data collection under CMS: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (misc cleanup)
m (add SIRTUNED creation comment and break up section into list)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
<!--Page automatically generated by CMSTOWIK EXEC and will be
The data collection portion of <var class="product">SirTune</var> is integrated with the <var class="product">[[Sirius Mods]]</var> as of SirTune 7.1, and it is integrated into the Model&nbsp;204 nucleus as of Model&nbsp;204 7.5.
** 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 data collection under CMS -->


As of the integration of the <var class="product">SirTune</var> data collector with the <var class="product">[[Sirius Mods]]</var>
Depending on your SirTune and Model&nbsp;204 versions, then, you might need to link edit the <var class="product">Sirius Mods</var> into the <var class="product">Model&nbsp;204</var> <code>ONLINE</code> module to make the SirTune data collector available.
(in <var class="product">Sirius Mods</var> version 6.9), how you invoke <var class="product">SirTune</var> depends on its version.


==Versions of SirTune after 1.5==
The SirTune data collector also requires a load module called <code>SIRTUNED</code>, which runs in a separate service machine, to be made available.
The data collection portion of <var class="product">SirTune</var> is part of the <var class="product">Sirius Mods</var> object.
It also requires a load module called <code>SIRTUNED</code>, which runs in a separate service machine.
The data collector becomes available once the <var class="product">Sirius Mods</var> is link edited into the <var class="product">Model 204</var> <code>ONLINE</code> module and once the SIRTUNED service machine is made available.
 
<div id="stuncms"></div>
===Invoking SirTune===
<!--Caution: <div> above-->


==<b id="stuncms"></b>Invoking SirTune==
To invoke <var class="product">SirTune</var>,
To invoke <var class="product">SirTune</var>,
the EXEC that invokes the <var class="product">Model 204</var> load module should do so directly:
the EXEC that invokes the <var class="product">Model 204</var> load module should do so directly:
<p class="code"><nowiki>M204CMS M204ONLN ...
<p class="code">M204CMS M204ONLN ...
</nowiki></p>
</p>


This statement differs from that required for version 1.5 and earlier of <var class="product">SirTune</var>
This statement differs from that required for version 1.5 and earlier of <var class="product">SirTune</var>
Line 51: Line 41:
</ul>
</ul>


<div id="stdd"></div>
==<b id="stdd"></b>Optional SirTune DD name==
===Optional SirTune DD name===
<!--Caution: <div> above-->
<p>
<p>
<var class="product">SirTune</var> has the optional DD described below, for which a FILEDEF can be added to M204FDEF EXEC or any other
<var class="product">SirTune</var> has the optional DD described below, for which a FILEDEF can be added to M204FDEF EXEC or any other
EXEC invoked before the ONLINE module.</p>  
EXEC invoked before the ONLINE module.
<p class="note"><b>Note:</b> The SIRTUNEO DD used in earlier versions of <var class="product">SirTune</var> is obsolete in versions of <var class="product">SirTune</var> after 1.5.</p>
</p>  
<p class="note"><b>Note:</b> The SIRTUNEO DD used in earlier versions of <var class="product">SirTune</var> is obsolete in versions of <var class="product">SirTune</var> after 1.5.
</p>
<table class="thJustBold">
<table class="thJustBold">
<tr><th>SIRTUNEI</th>
<tr><th>SIRTUNEI</th>
<td>This optional DD contains configuration statements that alter the <var class="product">SirTune</var> defaults.
<td>This optional DD contains configuration statements that alter the <var class="product">SirTune</var> defaults.
These statements ([[SirTune configuration statements]]) allow control over the name of the allow control over the name of the <var class="product">Model 204</var> load module,
These statements ([[SirTune data collection statements]]) allow control over the name of the allow control over the name of the <var class="product">Model&nbsp;204</var> 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.
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.
<p>
<p>
Line 71: Line 61:
</table>
</table>


==Version 1.5 or earlier of SirTune==
==<b id="stundvm"></b>The SIRTUNED virtual machine==
The data collection portion of <var class="product">SirTune</var> consists of:
<var class="product">SirTune</var> requires the presence of a virtual machine running the SIRTUNED load module. It is recommended that this virtual machine be given the user ID <code>SIRTUNED</code>.
<p>
Notes:</p>
<ul>
<ul>
<li>A load module called <code>SIRTUNE</code>, which runs in the <var class="product">Model&nbsp;204</var> <code>ONLINE</code> virtual machine or virtual machines.
<li>When you create virtual machine SIRTUNED, give it access to the appropriate load modules and execs, which must include the following:
 
<ul>
<li>A load module called <code>SIRTUNED</code>, which runs in a separate service machine.
<li>PROFILE EXEC </li>
<li>SIRTUNEA EXEC </li>
<li>SIRTUNEF EXEC </li>
<li>SIRTUNED MODULE</li>
</ul>
</ul>
<div id="istncms"></div>
===Invoking the SIRTUNE module===
<!--Caution: <div> above-->
To have <var class="product">SirTune</var> collect data for a particular
ONLINE machine, do the following:
<ol>
<li>Place the SIRTUNE load module
on a minidisk accessible to the virtual machine running
<var class="product">Model 204</var>.</li>
<li>Modify the EXEC that invokes <var class="product">Model 204</var> so that it invokes SIRTUNE instead.
<p>
<p>
For example, to have SIRTUNE monitor an ONLINE that is invoked with:</p>
The SirTune code contains a sample exec called <code>SIRTUNED EXEC</code> which can be used as PROFILE EXEC for this service machine. </p>
<p class="code"><nowiki>M204CMS M204ONLN ( SYSOPT 155 LIBUFF 600
</nowiki></p>
<p>
<p>
Change the line to read:</p>
Then, to run SIRTUNED under the CMS interface (making it possible to write sample data to OS format minidisks), give SIRTUNED access to the M204CMS module shipped with <var class="product">Model&nbsp;204</var>. </p></li>
<p class="code"><nowiki>M204CMS SIRTUNE ( SYSOPT 155 LIBUFF 600
</nowiki></p></li>
</ol>
SIRTUNE will then invoke <var class="product">Model 204</var> collecting polling data as required.


<var class="product">SirTune</var> data collection should have no significant impact on the
<li>The SIRTUNED service machine communicates with all running Online virtual machines running <var class="product">SirTune</var>, saving their sample data to disk.
performance of the ONLINE virtual machine.
<p>
Because of this, appropriate directory statements must be added to the CP directory to allow IUCV communications between
the <var class="product">Model&nbsp;204</var> virtual machines and the SIRTUNED virtual machine. The easiest way to accomplish this is by adding the <code>IUCV ALLOW</code> directory statement for user SIRTUNED.</p></li>


If SIRTUNE is able to load <var class="product">Model 204</var> but cannot sample for some reason
<li>The sample SIRTUNED EXEC invokes the SIRTUNED MODULE as follows:
(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 204</var> will still proceed. This allows leaving SIRTUNE in place in your EXECs while a temporary problem
<p class="code"><nowiki>'SIRTUNED';
is being solved.
 
<div id="oldstdd"></div>
===Optional SIRTUNE DD names===
<!--Caution: <div> above-->
 
The SIRTUNE load module has some optional DDs.
FILEDEFs can be added for these DDs to M204FDEF EXEC or any other
EXEC invoked before SIRTUNE.
The optional DDs are:
<table class="thJustBold">
<tr><th>SIRTUNEI</th>
<td>See [[#stdd|Optional SirTune DD name]].</td></tr>
 
<tr><th>SIRTUNEO</th>
<td>This optional DD receives informational SIRTUNE messages. If this DD is not specified, SIRTUNE messages go to the virtual console. SIRTUNEO must have LRECL greater than or equal to 80.</td></tr>
</table>
 
The following is a sample FILEDEF:
<p class="code"><nowiki>FILEDEF SIRTUNEO FISK SIRTUNE LISTING A
</nowiki></p>
</nowiki></p>
<div id="stundvm"></div>
==The SIRTUNED virtual machine==
<!--Caution: <div> above-->
<p>
<p>
<var class="product">SirTune</var> requires the presence of a virtual machine running the SIRTUNED load module. It is recommended that this virtual machine be given the userid <code>SIRTUNED</code>.
To authorize users to issue commands to SIRTUNED via SMSG, list the authorized users after the <var>SIRTUNED</var> command.
The installation tape contains
a sample exec called <code>SIRTUNED EXEC</code> which can be used as PROFILE EXEC for this service machine.</p>
<p>
This service machine communicates with all running ONLINE virtual machines running <var class="product">SirTune</var>, saving their
sample data to disk.
Because of this, appropriate directory statements
must be added to the CP directory to allow IUCV communications between
the <var class="product">Model 204</var> virtual machines and the SIRTUNED virtual machine.
The easiest way to accomplish this is by adding the <code>IUCV ALLOW</code> directory statement for user SIRTUNED.</p>
<p>
The sample SIRTUNED EXEC invokes the SIRTUNED MODULE as follows:</p>
<p class="code"><nowiki>'SIRTUNED';
</nowiki></p>
To authorize users to issue commands to SIRTUNED via
SMSG, list the authorized users after the <var>SIRTUNED</var> command.
The user IDs in the list can contain wildcard characters.
The user IDs in the list can contain wildcard characters.
For example, the following command authorizes user ID <code>SYSOPER</code> and any user ID beginning with the characters
For example, the following command authorizes user ID <code>SYSOPER</code> and any user ID beginning with the characters <code>MARGE</code> to issue a command to SIRTUNED via SMSG. </p>
<code>MARGE</code> to issue a command to SIRTUNED via SMSG.
<p class="code"><nowiki>'SIRTUNED SYSOPER MARGE*';
<p class="code"><nowiki>'SIRTUNED SYSOPER MARGE*';
</nowiki></p>
</nowiki></p>
 
<p>
For more information about using wildcards in this list, see [[SirTune statement wildcards]].
For more information about using wildcards in this list, see [[SirTune statement wildcards]]. </p>
<p>
<p>
SIRTUNED will use MSGNOH for its responses if it is authorized; otherwise
SIRTUNED will use MSGNOH for its responses if it is authorized; otherwise
it will use MSG.</p>
it will use MSG.</p></li>
 
<li>It is generally not important to terminate the SIRTUNED service machine
"cleanly" if the <var class="product">Model&nbsp;204</var> virtual machines running <var class="product">SirTune</var> are themselves terminated cleanly.
<p>
<p>
It is generally not important to terminate the SIRTUNED service machine
"cleanly" if the <var class="product">Model 204</var> virtual machines running <var class="product">SirTune</var> are themselves terminated cleanly.
However, if it becomes necessary to terminate the SIRTUNED
However, if it becomes necessary to terminate the SIRTUNED
service machine while <var class="product">Model&nbsp;204</var> virtual machines are running, log onto SIRTUNED and issue any one of the following commands:</p>
service machine while <var class="product">Model&nbsp;204</var> virtual machines are running, log onto SIRTUNED and issue any one of the following commands:</p>
<ul>
<ul>
<li>QUIT
<li>QUIT </li>
<li>END
<li>END </li>
<li>STOP
<li>STOP </li>
<li>SHUTDOWN
<li>SHUTDOWN </li>
</ul>
</ul>
<p class="note"><b>Note:</b> When SIRTUNED terminates, data collection on all <var class="product">Model&nbsp;204</var> service
<p class="note"><b>Note:</b> When SIRTUNED terminates, data collection on all <var class="product">Model&nbsp;204</var> service
machines running <var class="product">SirTune</var> is immediately terminated.
machines running <var class="product">SirTune</var> is immediately terminated. They do, however, continue to run <var class="product">Model&nbsp;204</var> without interruption. </p></li>
They do, however, continue to run <var class="product">Model&nbsp;204</var> without interruption.
 
</p>
<li>Every time an Online running <var class="product">SirTune</var> is brought up, <var class="product">SirTune</var> attempts to establish an IUCV connection with SIRTUNED. If it is unable to do so, the Online is not brought up.
<p>
<p>
Every time an ONLINE running <var class="product">SirTune</var> is brought up, <var class="product">SirTune</var> attempts to establish an IUCV connection with SIRTUNED.
If a connection is established, SIRTUNED immediately invokes an EXEC called <code>SIRTUNEF</code>. This exec can then issue FILEDEFs or other commands as required. </p>
If it is unable to do so, the ONLINE is not brought up.
If a connection is established, SIRTUNED immediately invokes an EXEC called <code>SIRTUNEF</code>.
This exec can then issue FILEDEFs or other commands as required.</p>
<p>
<p>
After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the
After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the
file that will contain the <var class="product">SirTune</var> sample data.
file that will contain the <var class="product">SirTune</var> sample data.
The default DDNAME used
The default DDNAME used for the open is the user ID of the <var class="product">Model&nbsp;204</var> service machine.
for the open is the user ID of the <var class="product">Model&nbsp;204</var> service machine.
The actual DDNAME can be modified with a [[SirTune data collection statements|SirTune statement]], and it is passed to SIRTUNEF.</p>
The actual DDNAME can be modified with a [[SirTune configuration statements|SirTune statement]], and it is passed to SIRTUNEF.</p>
<p>
<p>
A sample SIRTUNEF is provided on the installation tape and
The sample SIRTUNEF that is provided which should be modified to suit installation requirements. SIRTUNEF is passed two parameters:</p>
should be modified to suit installation requirements.
SIRTUNEF is passed two parameters:</p>
<ul>
<ul>
<li>The user ID of the <var class="product">Model&nbsp;204</var> virtual machine </li>
<li>The user ID of the <var class="product">Model&nbsp;204</var> virtual machine </li>
Line 195: Line 128:
to be used on a FILEDEF command) </li>
to be used on a FILEDEF command) </li>
</ul>
</ul>
 
<p>
If SIRTUNEF sets a non-zero return code, SIRTUNED will return
If SIRTUNEF sets a non-zero return code, SIRTUNED will return
an open error to SIRTUNED and close the IUCV connection, preventing
an open error to SIRTUNED and close the IUCV connection, preventing
the ONLINE from coming up.
the Online from coming up. After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the appropriate DDNAME for output.
After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the appropriate DDNAME for output.
If this open fails, an open error is reflected to <var class="product">SirTune</var> and the IUCV connection is closed, preventing the Online from coming up. </p></li>
If this open fails, an open error is reflected to <var class="product">SirTune</var> and the IUCV connection is closed, preventing the ONLINE from coming up.
 
<p>
<li>In general, it is sufficient to allow the sample data sets to
In general, it is sufficient to allow the sample data sets to
reside on a CMS-format minidisk. Although data can be sent to tape,
reside on a CMS-format minidisk. Although data can be sent to tape,
delays in manual tape handling could result in hung <var class="product">Model&nbsp;204</var> virtual machines waiting for SIRTUNED to process a tape mount. </p>
delays in manual tape handling could result in hung <var class="product">Model&nbsp;204</var> virtual machines waiting for SIRTUNED to process a tape mount.  
<p>
<p>
Data can also be sent to OS-format minidisks.
Data can also be sent to OS-format minidisks.
Line 213: Line 145:
<p class="code"><nowiki>'M204CMS SIRTUNED';
<p class="code"><nowiki>'M204CMS SIRTUNED';
</nowiki></p>
</nowiki></p>
<p>
While it is somewhat more efficient to send sample data
While it is somewhat more efficient to send sample data
to an OS-format minidisk than to a CMS-format disk,
to an OS-format minidisk than to a CMS-format disk,
this advantage is probably outweighed in most cases
this advantage is probably outweighed in most cases
by the advantage of not having to preallocate space for each sample dataset.
by the advantage of not having to preallocate space for each sample data set. </p>
<p>
<p>
The sample data sets must be variable format and should generally have a large block size (greater than 10000). If DCB information is not explicitly specified, the defaults selected by <var class="product">SirTune</var> should be adequate for all but the most extreme cases. If a sample data set fills up or a CMS minidisk becomes full, the virtual machine(s) running <var class="product">SirTune</var> and associated with the full minidisk or data set will simply stop collecting data for the duration of the run.
The sample data sets must be variable format and should generally have a large block size (greater than 10000). If DCB information is not explicitly specified, the defaults selected by <var class="product">SirTune</var> should be adequate for all but the most extreme cases. If a sample data set fills up or a CMS minidisk becomes full, the virtual machine(s) running <var class="product">SirTune</var> and associated with the full minidisk or data set will simply stop collecting data for the duration of the run.
20 megabytes for each <var class="product">SirTune</var> sample data set
20 megabytes for each <var class="product">SirTune</var> sample data set
should be sufficient for most shops, while 50 megabytes per data set should be sufficient for almost any requirements.</p>
should be sufficient for most shops, while 50 megabytes per data set should be sufficient for almost any requirements.</p></li>
 
<li>Since the only cost of running out of space on SIRTUNED is the
loss of some data, it is not worth spending a lot of time trying to size SIRTUNED exactly. Simply allocate the SIRTUNED minidisk at 20 megabytes per <var class="product">Model 204</var> virtual machine for which data is to be collected (or less if disk space is tight), and adjust the size based on experience.
<p>
<p>
Since the only cost of running out of space on SIRTUNED is the
For more information on sizing SIRTUNED, see [[#SirTune size requirement for SIRTUNED|SirTune size requirement for SIRTUNED]].
loss of some data, it is not worth spending a lot of time trying to size SIRTUNED exactly. Simply allocate the SIRTUNED minidisk at 20 megabytes per <var class="product">Model 204</var> virtual machine for which data is to be collected (or less if disk space
The sample SIRTUNEF EXEC is an example of how samples from several runs can be kept simultaneously available. </p></li>
is tight), and adjust the size based on experience.</p>
 
<p>
<li>If <var class="product">Model&nbsp;204</var> Online service machines are brought up (by <code>AUTOLOG</code>) automatically at system initialization, and some of these virtual machines will run
For more information on sizing SIRTUNED, see [[SirTune size requirement for SIRTUNED]].
with <var class="product">SirTune</var>, the SIRTUNED service machine must complete SIRTUNED initialization before any <var class="product">SirTune</var> in a <var class="product">Model&nbsp;204</var> virtual machine attempts to establish an IUCV connection to SIRTUNED.
The sample SIRTUNEF EXEC on the installation tape is an example of how samples from several runs can be kept simultaneously available.</p>
<p>
<p>
If <var class="product">Model&nbsp;204</var> ONLINE service machines are brought up (by <code>AUTOLOG</code>) automatically at system initialization, and some of these virtual machines will run
Because SIRTUNED initialization is extremely quick, this timing can probably be guaranteed by placing an AUTOLOG command for SIRTUNED ahead of AUTOLOG commands for <var class="product">Model&nbsp;204</var> service machines in the exec(s) executing the AUTOLOG.
with <var class="product">SirTune</var>, the SIRTUNED service machine must complete SIRTUNED initialization before any <var class="product">SirTune</var> in a <var class="product">Model&nbsp;204</var> virtual machine attempts to establish an IUCV connection to SIRTUNED.
Because SIRTUNED initialization is extremely quick, this can probably be guaranteed by placing an AUTOLOG command for SIRTUNED ahead of AUTOLOG commands for <var class="product">Model 204</var> service machines in the exec(s) executing the AUTOLOG.
To be even more certain, place a <code>CP SLEEP <i>x</i> SEC</code> after
To be even more certain, place a <code>CP SLEEP <i>x</i> SEC</code> after
the AUTOLOG of SIRTUNED to give SIRTUNED time to get through initialization, where
the AUTOLOG of SIRTUNED to give SIRTUNED time to get through initialization, where <var class="term">x</var> is some small number (1 is probably sufficient). </p>
<var class="term">x</var> is some small number (1 is probably sufficient).</p>
<p>
<p>
Using <code>SIRTUNEA EXEC</code> guarantees that the <var class="product">Model&nbsp;204</var> service machines
Using <code>SIRTUNEA EXEC</code> guarantees that the <var class="product">Model&nbsp;204</var> service machines
are not logged on until SIRTUNED has completed initialization.
are not logged on until SIRTUNED has completed initialization.
SIRTUNEA EXEC is invoked by SIRTUNED after it has completed initialization.
SIRTUNEA EXEC is invoked by SIRTUNED after it has completed initialization.
If the AUTOLOG commands for the <var class="product">Model 204</var> service machines are moved into SIRTUNEA EXEC, SIRTUNED is authorized to issue the appropriate AUTOLOGs, and
If the AUTOLOG commands for the <var class="product">Model&nbsp;204</var> service machines are moved into SIRTUNEA EXEC, SIRTUNED is authorized to issue the appropriate AUTOLOGs, and
an AUTOLOG command for SIRTUNED is added to the initialization exec, then
an AUTOLOG command for SIRTUNED is added to the initialization exec, then
SIRTUNED is automatically logged on, and it will initialize and then bring up (AUTOLOG) the <var class="product">Model&nbsp;204</var> service machines.
SIRTUNED is automatically logged on, and it will initialize and then bring up (AUTOLOG) the <var class="product">Model&nbsp;204</var> service machines.
</p></li>
</ul>
==SirTune size requirement for SIRTUNED==
{{Template: SirTune size requirement for SIRTUNED}}


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

Latest revision as of 00:22, 9 August 2017

The data collection portion of SirTune is integrated with the Sirius Mods as of SirTune 7.1, and it is 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 into the Model 204 ONLINE module to make the SirTune data collector available.

The SirTune data collector also requires a load module called SIRTUNED, which runs in a separate service machine, to be made available.

Invoking SirTune

To invoke SirTune, the EXEC that invokes the Model 204 load module should do so directly:

M204CMS M204ONLN ...

This statement differs from that required for version 1.5 and earlier of SirTune (which is described in Invoking the SIRTUNE module).

SirTune also requires the presence of a virtual machine running the SIRTUNED load module (as described in The SIRTUNED virtual machine). 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 any SirTune DDs 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:

    Set the SIRTUNE parameter to 0.

    The SIRTUNE parameter, which controls whether the SirTune data collector is initialized at the start of a Model 204 run, 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:

    M204CMS M204ONLN ( SIRTUNE 0 ...

Optional SirTune DD name

SirTune has the optional DD described below, for which a FILEDEF can be added to M204FDEF EXEC or any other EXEC invoked before the ONLINE module.

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

SIRTUNEI This optional DD contains configuration statements that alter the SirTune defaults.

These statements (SirTune data collection statements) allow control over the name of the 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.

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

The following is a sample FILEDEF:

FILEDEF SIRTUNEI DISK SIRTUNE INPUT A

The SIRTUNED virtual machine

SirTune requires the presence of a virtual machine running the SIRTUNED load module. It is recommended that this virtual machine be given the user ID SIRTUNED.

Notes:

  • When you create virtual machine SIRTUNED, give it access to the appropriate load modules and execs, which must include the following:
    • PROFILE EXEC
    • SIRTUNEA EXEC
    • SIRTUNEF EXEC
    • SIRTUNED MODULE

    The SirTune code contains a sample exec called SIRTUNED EXEC which can be used as PROFILE EXEC for this service machine.

    Then, to run SIRTUNED under the CMS interface (making it possible to write sample data to OS format minidisks), give SIRTUNED access to the M204CMS module shipped with Model 204.

  • The SIRTUNED service machine communicates with all running Online virtual machines running SirTune, saving their sample data to disk.

    Because of this, appropriate directory statements must be added to the CP directory to allow IUCV communications between the Model 204 virtual machines and the SIRTUNED virtual machine. The easiest way to accomplish this is by adding the IUCV ALLOW directory statement for user SIRTUNED.

  • The sample SIRTUNED EXEC invokes the SIRTUNED MODULE as follows:

    'SIRTUNED';

    To authorize users to issue commands to SIRTUNED via SMSG, list the authorized users after the SIRTUNED command. The user IDs in the list can contain wildcard characters. For example, the following command authorizes user ID SYSOPER and any user ID beginning with the characters MARGE to issue a command to SIRTUNED via SMSG.

    'SIRTUNED SYSOPER MARGE*';

    For more information about using wildcards in this list, see SirTune statement wildcards.

    SIRTUNED will use MSGNOH for its responses if it is authorized; otherwise it will use MSG.

  • It is generally not important to terminate the SIRTUNED service machine "cleanly" if the Model 204 virtual machines running SirTune are themselves terminated cleanly.

    However, if it becomes necessary to terminate the SIRTUNED service machine while Model 204 virtual machines are running, log onto SIRTUNED and issue any one of the following commands:

    • QUIT
    • END
    • STOP
    • SHUTDOWN

    Note: When SIRTUNED terminates, data collection on all Model 204 service machines running SirTune is immediately terminated. They do, however, continue to run Model 204 without interruption.

  • Every time an Online running SirTune is brought up, SirTune attempts to establish an IUCV connection with SIRTUNED. If it is unable to do so, the Online is not brought up.

    If a connection is established, SIRTUNED immediately invokes an EXEC called SIRTUNEF. This exec can then issue FILEDEFs or other commands as required.

    After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the file that will contain the SirTune sample data. The default DDNAME used for the open is the user ID of the Model 204 service machine. The actual DDNAME can be modified with a SirTune statement, and it is passed to SIRTUNEF.

    The sample SIRTUNEF that is provided which should be modified to suit installation requirements. SIRTUNEF is passed two parameters:

    • The user ID of the Model 204 virtual machine
    • The DDNAME to be used for the open (that is, the name to be used on a FILEDEF command)

    If SIRTUNEF sets a non-zero return code, SIRTUNED will return an open error to SIRTUNED and close the IUCV connection, preventing the Online from coming up. After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the appropriate DDNAME for output. If this open fails, an open error is reflected to SirTune and the IUCV connection is closed, preventing the Online from coming up.

  • In general, it is sufficient to allow the sample data sets to reside on a CMS-format minidisk. Although data can be sent to tape, delays in manual tape handling could result in hung Model 204 virtual machines waiting for SIRTUNED to process a tape mount.

    Data can also be sent to OS-format minidisks. To do this, however, SIRTUNED must be run under the Model 204 CMS interface (M204CMS). To do this, change this line in SIRTUNED EXEC:

    'SIRTUNED';

    To:

    'M204CMS SIRTUNED';

    While it is somewhat more efficient to send sample data to an OS-format minidisk than to a CMS-format disk, this advantage is probably outweighed in most cases by the advantage of not having to preallocate space for each sample data set.

    The sample data sets must be variable format and should generally have a large block size (greater than 10000). If DCB information is not explicitly specified, the defaults selected by SirTune should be adequate for all but the most extreme cases. If a sample data set fills up or a CMS minidisk becomes full, the virtual machine(s) running SirTune and associated with the full minidisk or data set will simply stop collecting data for the duration of the run. 20 megabytes for each SirTune sample data set should be sufficient for most shops, while 50 megabytes per data set should be sufficient for almost any requirements.

  • Since the only cost of running out of space on SIRTUNED is the loss of some data, it is not worth spending a lot of time trying to size SIRTUNED exactly. Simply allocate the SIRTUNED minidisk at 20 megabytes per Model 204 virtual machine for which data is to be collected (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. The sample SIRTUNEF EXEC is an example of how samples from several runs can be kept simultaneously available.

  • If Model 204 Online service machines are brought up (by AUTOLOG) automatically at system initialization, and some of these virtual machines will run with SirTune, the SIRTUNED service machine must complete SIRTUNED initialization before any SirTune in a Model 204 virtual machine attempts to establish an IUCV connection to SIRTUNED.

    Because SIRTUNED initialization is extremely quick, this timing can probably be guaranteed by placing an AUTOLOG command for SIRTUNED ahead of AUTOLOG commands for Model 204 service machines in the exec(s) executing the AUTOLOG. To be even more certain, place a CP SLEEP x SEC after the AUTOLOG of SIRTUNED to give SIRTUNED time to get through initialization, where x is some small number (1 is probably sufficient).

    Using SIRTUNEA EXEC guarantees that the Model 204 service machines are not logged on until SIRTUNED has completed initialization. SIRTUNEA EXEC is invoked by SIRTUNED after it has completed initialization. If the AUTOLOG commands for the Model 204 service machines are moved into SIRTUNEA EXEC, SIRTUNED is authorized to issue the appropriate AUTOLOGs, and an AUTOLOG command for SIRTUNED is added to the initialization exec, then SIRTUNED is automatically logged on, and it will initialize and then bring up (AUTOLOG) the Model 204 service machines.

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