SirTune data collection under CMS - Revision history

JAL: add SIRTUNED creation comment and break up section into list

2017-08-09T00:22:26Z

add SIRTUNED creation comment and break up section into list

JAL: /* The SIRTUNED virtual machine */ remove "tape" references

2017-08-08T23:14:45Z

The SIRTUNED virtual machine: remove "tape" references

JAL: add "SirTune size requirement for SIRTUNED" section

2017-08-08T22:45:34Z

add "SirTune size requirement for SIRTUNED" section

Show changes

JAL: link repair

2017-08-08T20:53:06Z

link repair

← Older revision		Revision as of 20:53, 8 August 2017
Line 61:		Line 61:
	<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 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 184:		Line 184:
	The default DDNAME used		The default DDNAME used
	for the open is the user ID of the <var class="product">Model 204</var> service machine.		for the open is the user ID of the <var class="product">Model 204</var> service machine.
	The actual DDNAME can be modified with a [[SirTune ~~configuration~~ statements\|SirTune statement]], and it is passed to SIRTUNEF.</p>		The actual DDNAME can be modified with a [[SirTune data collection statements\|SirTune statement]], and it is passed to SIRTUNEF.</p>
	<p>		<p>
	A sample SIRTUNEF is provided on the installation tape and		A sample SIRTUNEF is provided on the installation tape and

JAL: misc cleanup

2015-11-05T19:35:09Z

misc cleanup

Show changes

JAL: more conversion cleanup

2015-07-02T23:46:58Z

more conversion cleanup

Show changes

Admin: 1 revision: SirTune doc

2015-07-02T17:47:04Z

1 revision: SirTune doc

← Older revision	Revision as of 17:47, 2 July 2015
(No difference)

JAL: /* See also */

2015-07-02T16:13:17Z

See also

New page

<p></p>
As of the integration of the <var class="product">SirTune</var> data collector with the &SIRMODS.
(in &SIRMODS. version 6.9), how you invoke <var class="product">SirTune</var> depends on its version.
==Versions of SirTune after 1.5==
<p></p>
The data collection portion of <var class="product">SirTune</var> is part of the &SIRMODS. object.
It also requires a load module called SIRTUNED, which runs in a separate
service machine.
The data collector becomes available once the &SIRMODS. is link edited into
the <var class="product">Model 204</var> ONLINE module
and once the SIRTUNED service machine is made available.

<div id="stuncms"></div>
===Invoking <var class="product">SirTune</var>===


<p></p>
<p></p>
To invoke <var class="product">SirTune</var>,
the EXEC that invokes the <var class="product">Model 204</var> load module should do so directly:
<p class="code"><nowiki>M204CMS M204ONLN ...
</nowiki></p>
<p></p>
This statement differs from that required for version 1.5 and earlier of <var class="product">SirTune</var>
(which is described in [[#istncms|Invoking the SIRTUNE module]]).
<p></p>
<var class="product">SirTune</var> also requires the presence of a virtual machine running the
SIRTUNED load module (as described in [[#stundvm|The SIRTUNED virtual machine]]).
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,
<p></p>
If you are upgrading from an earlier version of <var class="product">SirTune</var>,
no changes are necessary to any <var class="product">SirTune</var> DDs you were using.
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 204</var> ONLINE load module.
<p></p>
If you want to prevent the <var class="product">SirTune</var> data collector from being initialized,
do the following:
<ul>
<li>Set the SIRTUNE parameter to 0.
<p></p>
The SIRTUNE parameter, which
controls whether the <var class="product">SirTune</var> data collector is initialized at the
start of a <var class="product">Model 204</var> run, can be set to either of these values:
<table>
<tr><th>0</th><td>Disables initialization of the integrated <var class="product">SirTune</var> product for a particular run.</td></tr>
<tr><th>1</th><td>Enables initialization (this is the default).</td></tr>
</table>
<p></p>
<p></p>
For example:
<p class="code"><nowiki>M204CMS M204ONLN ( SIRTUNE 0 ...
</nowiki></p>
</ul>

<div id="stdd"></div>
===Optional SirTune DD name===


<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
EXEC invoked before the ONLINE module.</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>
<tr><th>SIRTUNEI</th>
<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,
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>
SIRTUNEI can have either fixed or variable format, and it can have any record length. </p>
<p>
The following is a sample FILEDEF:</p>
<p class="code">FILEDEF SIRTUNEI DISK SIRTUNE INPUT A
</p></td></tr>
</table>

==Version 1.5 or earlier of SirTune==
<p></p>
The data collection portion of <var class="product">SirTune</var> consists of a load
module called SIRTUNE that runs in the <var class="product">Model 204</var> ONLINE virtual machine
or virtual machines
and another load module called SIRTUNED which runs in a separate service
machine.

<div id="istncms"></div>
===Invoking the SIRTUNE module===


<p></p>
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>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 class="code"><nowiki>M204CMS M204ONLN ( SYSOPT 155 LIBUFF 600
</nowiki></p>
change the line to read
<p class="code"><nowiki>M204CMS SIRTUNE ( SYSOPT 155 LIBUFF 600
</nowiki></p>
</ol>
SIRTUNE will then invoke <var class="product">Model 204</var> collecting polling data as required.
<p></p>
<var class="product">SirTune</var> data collection should have no significant impact on the
performance of the ONLINE virtual machine.
<p></p>
If SIRTUNE is able to load <var class="product">Model 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 204</var> will still proceed.
This allows leaving SIRTUNE in place in your EXECs while a temporary problem
is being solved.

<div id="oldstdd"></div>
===Optional SIRTUNE DD names===


<p></p>
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>
<tr><th>SIRTUNEI</th><td>See [[#stdd|Optional <var class="product">SirTune</var> 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>
<p></p>
The following is a sample FILEDEF:
<p class="code"><nowiki>FILEDEF SIRTUNEO FISK SIRTUNE LISTING A
</nowiki></p>

<div id="stundvm"></div>
==The SIRTUNED virtual machine==


<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>.
The installation tape contains
a sample exec called SIRTUNED EXEC 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 IUCV ALLOW 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 SIRTUNED command.
The userids in the list can contain wildcard characters.
For example,
<p class="code"><nowiki>'SIRTUNED SYSOPER MARGE*';
</nowiki></p>
authorizes userid SYSOPER and any userid begining with the characters
MARGE to issue a command to SIRTUNED via SMSG.
For more information
on using wildcards in this list, see [[Sirtune statement wildcards]].
<p>
SIRTUNED will use MSGNOH for its responses if it is authorized; otherwise
it will use MSG.</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
service machine while <var class="product">Model 204</var> virtual machines are running,
log onto SIRTUNED and issue any one of the following commands:</p>
<ul>
<li>QUIT
<li>END
<li>STOP
<li>SHUTDOWN
</ul>
<p class="note"><b>Note:</b> When SIRTUNED terminates, data collection on all <var class="product">Model 204</var> service
machines running <var class="product">SirTune</var> will be immediately terminated.
They will, however, continue to run <var class="product">Model 204</var> without interruption.
</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 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.</p>
<p>
After SIRTUNEF returns to SIRTUNED, SIRTUNED attempts to open the
file that will contain the <var class="product">SirTune</var> sample data.
The default DDNAME used
for the open is the userid of the <var class="product">Model 204</var> service machine.
The actual DDNAME can be modified with a <var class="product">SirTune</var>
statement ([[SirTune configuration statements]]), and it is passed to SIRTUNEF.</p>
<p>
A sample SIRTUNEF is provided on the installation tape and
should be modified to suit installation requirements.
SIRTUNEF is passed two parameters:</p>
<ul>
<li>The userid of the <var class="product">Model 204</var> virtual machine
<li>The DDNAME to be used for the open (that is, the name
to be used on a FILEDEF command)
</ul>
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 <var class="product">SirTune</var> and the IUCV
connection is closed, preventing the ONLINE from coming up.
<p>
In general, it is sufficient to allow the sample datasets to
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 204</var>
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 <var class="product">Model 204</var> CMS interface (M204CMS). To do this, change the line in SIRTUNED EXEC that reads: </p>
<p class="code"><nowiki>'SIRTUNED';
</nowiki></p>
to read
<p class="code"><nowiki>'M204CMS SIRTUNED';
</nowiki></p>
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 dataset.
<p>
The sample datasets 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 dataset 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 dataset will simply stop collecting data for
the duration of the run.
20 megabytes for each <var class="product">SirTune</var> sample dataset
should be sufficient for most shops, while 50 megabytes per dataset should be sufficient for almost
any requirements.</p>
<p>
Since the only cost of running out of space on SIRTUNED is the
loss of some data, it's 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>
For more information on sizing SIRTUNED, see [[SirTune size requirement for 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>
If <var class="product">Model 204</var> ONLINE service machines are brought up (AUTOLOG'ed) automatically at system initialization and some of these virtual machines will run
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 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) doing the AUTOLOG'ing.
To be even more certain, a <code>CP SLEEP x SEC</code> can be placed after
the AUTOLOG of SIRTUNED to give SIRTUNED time to get through initialization, where
<i>x</i> is some small number (1 is probably sufficient).</p>
<p>
Using SIRTUNEA EXEC guarantees that the <var class="product">Model 204</var> service machines
won't be logged on until SIRTUNED 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
an AUTOLOG command for SIRTUNED is added to the initialization exec, then
SIRTUNED will automatically be logged on, and it will initialize and then bring up
(AUTOLOG) the <var class="product">Model 204</var> service machines.

==See also==
{{Template:SirTune topic list}}

[[Category: SirTune]]

← Older revision		Revision as of 23:14, 8 August 2017
Line 64:		Line 64:
	<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>.		<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>.
	The ~~installation tape~~ contains		The SirTune code contains
	a sample exec called <code>SIRTUNED EXEC</code> which can be used as PROFILE EXEC for this service machine.</p>		a sample exec called <code>SIRTUNED EXEC</code> which can be used as PROFILE EXEC for this service machine.</p>
	<p>		<p>
Line 112:		Line 112:
	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 204</var> service machine.
	for the open is the user ID of the <var class="product">Model 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 data collection 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 204</var> virtual machine </li>		<li>The user ID of the <var class="product">Model 204</var> virtual machine </li>
Line 128:		Line 125:
	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.		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>		<p>
	In general, it is sufficient to allow the sample data sets to		In general, it is sufficient to allow the sample data sets to
Line 146:		Line 143:
	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>
	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.
Line 157:		Line 154:
	<p>		<p>
	For more information on sizing SIRTUNED, see [[#SirTune size requirement for SIRTUNED\|SirTune size requirement for SIRTUNED]].		For more information on sizing SIRTUNED, see [[#SirTune size requirement for SIRTUNED\|SirTune size requirement for SIRTUNED]].
	The sample SIRTUNEF EXEC ~~on the installation tape~~ is an example of how samples from several runs can be kept simultaneously available.</p>		The sample SIRTUNEF EXEC is an example of how samples from several runs can be kept simultaneously available.</p>
	<p>		<p>
	If <var class="product">Model 204</var> Online service machines are brought up (by <code>AUTOLOG</code>) automatically at system initialization, and some of these virtual machines will run		If <var class="product">Model 204</var> Online service machines are brought up (by <code>AUTOLOG</code>) automatically at system initialization, and some of these virtual machines will run
Line 168:		Line 165:
	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 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 204</var> service machines.		SIRTUNED is automatically logged on, and it will initialize and then bring up (AUTOLOG) the <var class="product">Model 204</var> service machines.