SirTune data collection statements - Revision history

Admin: Admin moved page SirTune configuration statements to SirTune data collection statements without leaving a redirect: page name was ambiguous

2017-08-08T21:03:42Z

Admin moved page SirTune configuration statements to SirTune data collection statements without leaving a redirect: page name was ambiguous

← Older revision	Revision as of 21:03, 8 August 2017
(No difference)

JAL: add word

2017-08-08T20:49:46Z

add word

← Older revision		Revision as of 20:49, 8 August 2017
Line 6:		Line 6:
	with an asterisk character (<tt>*</tt>) is treated as a comment and ignored.		with an asterisk character (<tt>*</tt>) is treated as a comment and ignored.

	Available <var class="product">SirTune</var> configuration statements are described in the subsections that follow.		Available <var class="product">SirTune</var> data collection configuration statements are described in the subsections that follow.
	The minimum abbreviation allowed for each statement is indicated with		The minimum abbreviation allowed for each statement is indicated with
	uppercase characters, while optional characters are indicated with lowercase.		uppercase characters, while optional characters are indicated with lowercase.

JAL: misc formatting

2017-08-08T20:43:08Z

misc formatting

← Older revision		Revision as of 20:43, 8 August 2017
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 configuration statements for the Data Collector -->~~

	An optional DD card (or FILEDEF under CMS) called <code>SIRTUNEI</code> allows users to specify characteristics of the reporting run and to customize which reports are requested and how they are ordered.		An optional DD card (or FILEDEF under CMS) called <code>SIRTUNEI</code> allows users to specify characteristics of the reporting run and to customize which reports are requested and how they are ordered.

Line 11:		Line 6:
	with an asterisk character (<tt>*</tt>) is treated as a comment and ignored.		with an asterisk character (<tt>*</tt>) is treated as a comment and ignored.

	Available <var class="product">SirTune</var> configuration statements are described in the		Available <var class="product">SirTune</var> configuration statements are described in the subsections that follow.
	subsections that follow.
	The minimum abbreviation allowed for each statement is indicated with		The minimum abbreviation allowed for each statement is indicated with
	uppercase characters, while optional characters are indicated with lowercase.		uppercase characters, while optional characters are indicated with lowercase.
	Optional statement parameters are enclosed in brackets		Optional statement parameters are enclosed in brackets (<tt>[</tt><tt>]</tt>).
	(<tt>[</tt><tt>]</tt>).
	Alternatives are separated with a vertical bar (<tt>\|</tt>).		Alternatives are separated with a vertical bar (<tt>\|</tt>).

	<~~div~~ id="allcomp"></~~div~~>		==<b id="allcomp"></b>ALLComp==
	==ALLComp==
	~~<!--Caution: <div> above-->~~

	This statement specifies that <var class="product">SirTune</var> should collect compilation data for all procedures; it is the inverse of the <code>[[#precomp\|PRECOMP]]</code> statement.		This statement specifies that <var class="product">SirTune</var> should collect compilation data for all procedures; it is the inverse of the <code>[[#precomp\|PRECOMP]]</code> statement.

Line 93:		Line 83:
	however, because of the extra overhead of running multiple virtual machines.		however, because of the extra overhead of running multiple virtual machines.

	<~~div~~ id="colstat"></~~div~~>		==<b id="colstat"></b>COLLect state [extra_data]==
	==COLLect state [extra_data]==
	~~<!--Caution: <div> above-->~~

	This statement makes it possible to increase the quantity of		This statement makes it possible to increase the quantity of
	data collected by <var class="product">SirTune</var>.		data collected by <var class="product">SirTune</var>.
Line 542:		Line 529:
	Thus, if SIRTUNE is to collect data for a job that should be		Thus, if SIRTUNE is to collect data for a job that should be
	run with BATCH204, put the following statement into SIRTUNEI:		run with BATCH204, put the following statement into SIRTUNEI:
	~~====~~get non-BATCH204 example~~====~~		<!-- get non-BATCH204 example -->
	<p class="code"><nowiki>PGM BATCH204		<p class="code"><nowiki>PGM BATCH204
	</nowiki></p>		</nowiki></p>
Line 550:		Line 537:
	</p>		</p>

	<~~div~~ id="precomp"></~~div~~>		==<b id="precomp"></b>PREComp==
	==PREComp==
	~~<!--Caution: <div> above-->~~

	This statement specifies that <var class="product">SirTune</var> should only collect compilation data for precompiled APSY procedures;		This statement specifies that <var class="product">SirTune</var> should only collect compilation data for precompiled APSY procedures;
	it is the inverse of the <code>[[#allcomp\|ALLComp]]</code> statement.		it is the inverse of the <code>[[#allcomp\|ALLComp]]</code> statement.

JAL: add ID

2015-11-12T22:11:14Z

add ID

← Older revision		Revision as of 22:11, 12 November 2015
Line 47:		Line 47:
	</p>		</p>

	==AUTHorize userid1 [userid2] ...==		==<b id="authorize"></b>AUTHorize userid1 [userid2] ...==
	This statement specifies the user IDs from whom <var class="product">SirTune</var> should accept		This statement specifies the user IDs from whom <var class="product">SirTune</var> should accept
	<code>MODIFY</code> commands (under MVS) or <code>SMSG</code> commands (under CMS).		<code>MODIFY</code> commands (under MVS) or <code>SMSG</code> commands (under CMS).

JAL at 21:25, 6 November 2015

2015-11-06T21:25:02Z

← Older revision		Revision as of 21:25, 6 November 2015
Line 153:		Line 153:

	The CFR data allows the reporting module		The CFR data allows the reporting module
	to produce the <code>CFRROOT</code>, <code>STATE CFRH~~???~~</code>, and <code>STATE CFRB~~???~~</code> reports.		to produce the <code>CFRROOT</code>, <code>STATE CFRH<i>xxx</i></code>, and <code>STATE CFRB<i>xxx</i></code> reports.
	These reports allow breakdowns of:		These reports allow breakdowns of:
	<ul>		<ul>

JAL: misc cleanup

2015-11-05T01:09:08Z

misc cleanup

Show changes

JAL: more conversion cleanup

2015-07-03T00:03:12Z

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:35Z

See also

New page

An optional DD card (or FILEDEF under CMS) called SIRTUNEI allows
users to specify
characteristics of the reporting run and to customize which reports
are requested and how they are ordered.

The configuration statements take the form of control cards.
There can be only one <var class="product">SirTune</var> configuration statement
per line, there are no line continuations, and a line beginning
with an asterisk character (<code>*</code>) is treated as a comment and
ignored.

Available <var class="product">SirTune</var> configuration statements are described in the
subsections that follow.
The minimum abbreviation allowed for each statement is indicated with
uppercase characters, while optional characters are indicated with lowercase.
Optional statement parameters are enclosed in brackets
(<code>[</code><code>]</code>).
Alternatives are separated with a vertical bar (<code>|</code>).

<div id="allcomp"></div>
==ALLComp==



This statement specifies that <var class="product">SirTune</var> should collect compilation
data for all procedures; it is the inverse of the PRECOMP statement
([[#allcomp|ALLComp]]).

The default for a single user run (NUSERS = 1) is that <var class="product">SirTune</var> collects
compilation data for all procedures.
The default for a multi-user run (NUSERS > 1)
is that <var class="product">SirTune</var> collects compilation data only for pre-compiled procedures.
It is unnecessary to specify ALLCOMP in a single-user run since it is the default.

If ALLCOMP is not used explicitly in a multi-user run, or if it is overridden
by the PRECOMP statement in a single-user run,
the report generator can produce line-by-line breakdowns
for pre-compiled APSY procedures only.
Using the ALLCOMP statement makes it possible for the
reporting module to provide line-by-line breakdowns for all
User Language procedures executed in the job.

Specifying the ALLCOMP statement can significantly increase the
size of the sample dataset, and in extreme cases, it can adversely
affect the performance of an ONLINE.
Because of this, it is
generally recommended that you use only the ALLCOMP option
when running <var class="product">SirTune</var> against a single-user batch job, or when running
multi-user jobs that do a lot of processing in non-APSY or
non-pre-compiled procedures.
<blockquote class="note">Note: <var class="product">SirTune</var> cannot provide line-by-line breakdowns
for User Language programs not contained in procedures, including
in-line procedures in CCAIN, IODEV3, or BATCH2 input streams, or those
entered at a terminal without use of the editor.
</blockquote>
==AUTHorize userid1 [userid2] ...==

This statement specifies the userids from whom <var class="product">SirTune</var> should accept
MODIFY commands (under MVS) or SMSG commands (under CMS).
The default is that MODIFY or SMSG commands to <var class="product">SirTune</var> are
not accepted from any userid.


Since MVS provides no information about the user issuing a MODIFY
statement, the only AUTHORIZE statement that makes any sense under MVS
is:
<nowiki>AUTHORIZE *
</nowiki>
This indicates that <var class="product">SirTune</var> will accept MODIFY commands from any user
that has the privilege
to issue a MODIFY command (either an operator at a console or
a user in SDSF).


Under CMS, an arbitrary number of userids can be specified, and
the userids can contain wildcard characters.
For example:
<nowiki>AUTHORIZE BART HOMER*
</nowiki>
The statement above indicates that <var class="product">SirTune</var> should accept SMSG commands from
userid <code>BART</code> and from any userid that starts with the characters
<code>H O M E R</code>.
For more information on wildcards, see [[Sirtune statement wildcards]].

SIRTUNEI can contain an arbitrary number of AUTHORIZE statements.
The AUTHORIZE statements are cumulative, so the userids specified
on an AUTHORIZE statement are added to the list of userids specified
by all previous AUTHORIZE statements.

For more information on the commands that can be issued via MODIFY
or SMSG by authorized users, see [[SirTune MODIFY and SMSG commands]].

==CMSout vmid [ddname]==

This statement has meaning only under CMS.
It specifies the userid
of the virtual machine (vmid) running the SIRTUNED load module, and
it specifies the DD name (ddname) that virtual machine is to
use for the sample dataset.
The default for vmid is <code>SIRTUNED</code>, and the default
for ddname is the userid of the virtual machine running <var class="product">SirTune</var>.

For example, this statement
indicates that there is a SIRTUNED service machine with userid
<code>HOHO</code> that should use DD name <code>MARGE</code> for the sample dataset:
<nowiki>CMSOUT HOHO MARGE
</nowiki>

The CMSOUT statement makes it possible to run multiple SIRTUNED
service machines, because it allows <var class="product">SirTune</var> in each <var class="product">Model 204</var>
service machine to indicate the userid of its SIRTUNED service
machine.
This is not a generally recommended mode of operation,
however, because of the extra overhead of running multiple virtual machines.

<div id="colstat"></div>
==COLLect state [extra_data]==



This statement makes it possible to increase the quantity of
data collected by <var class="product">SirTune</var>.
While collecting extra data
increases the size of the sample dataset, it also makes it
possible to produce extended reports.

The default for COLLECT in multi-user runs is <code>COLLECT RUNG</code>,
which means that
data is only collecting for running users (users consuming CPU),
and no extra data is collected.
The default for COLLECT in single-user runs is <code>COLLECT ALLN BLKU DISKIO</code>,
which means that the only user for which data is not collected is
waiting PSTs.
Data is always collected for
running users, regardless of the COLLECT statements in SIRTUNEI.

state is a list of one or more blank-delimited user states.
<var class="product">SirTune</var> will collect sample data for a user
in any of the states indicated by COLLECT statements at the
moment a sample is collected.


For example, if the following
is specified, <var class="product">SirTune</var> will collect sample data for any user
that is swapping into or out of a server at the instant a
sample is collected:
<nowiki>COLLECT SWPG
</nowiki>


To be able to produce a report for a particular state, data must
be collected for that state with <var class="product">SirTune</var>.
For example, if you want to
produce a report for STATE SWPG, you can ensure
the appropriate data will be collected by <var class="product">SirTune</var> by placing
this statement in SIRTUNEI:
<nowiki>COLLECT SWPG
</nowiki>
For a discussion of available states and their
meanings, see [[SirTune user states]].

In addition to requesting that sample data be collected for users
in specific states, it is also possible to request extra data to
isolate the cause of certain wait types.
The only valid values for extra_data are <code>DISKIO</code>
and/or <code>CFR</code>.

Specifying <code>DISKIO</code> as a parameter on a COLLECT statement
indicates that <var class="product">SirTune</var> should collect data for every wait on <var class="product">Model 204</var> disk I/O.
This data allows the reporting module to produce the DISKIO reports.
These reports allow breakdowns
of waits on <var class="product">Model 204</var> disk I/O by file, table, and groups of pages within tables.


Specifying <code>DISKIO</code> on a collect statement implies the BLKIN parameter.
That is, this statement:
<nowiki>COLLECT DISKIO BLKIN
</nowiki>
is functionally equivalent to this:
<nowiki>COLLECT DISKIO
</nowiki>

Specifying
<code>CFR</code> as a parameter on a COLLECT statement indicates that <var class="product">SirTune</var>
should collect data for users with "Critical File Resource" activity.
Critical file resources are used to provide concurrency control among
updating and retrieving operations on the same file.
Contention on critical file resources can exacerbate performance
problems, sometimes dramatically.

The CFR data allows the reporting module
to produce the CFRROOT, STATE CFRH???, and STATE CFRB??? reports.
These reports allow breakdowns of:
<ul>
<li>The root causes of critical file resource waits
<li>Activities that result in the holding of critical file resources
</ul>

Since critical file resources are
used to provide multi-user concurrency control, the CFR parameter is
meaningless in a single-user run.


COLLECT statements are cumulative.
That is, this sequence:
<nowiki>COLLECT SWPGI
COLLECT BLKIN
COLLECT BLKON
</nowiki>
is functionally equivalent to this:
<nowiki>COLLECT SWPGI BLKIN BLKON
</nowiki>
and it results in data being collected for all users in state SWPGI, BLKIN, or
BLKON.
There is no limit to the number of COLLECT statements in SIRTUNEI.


The first COLLECT statement in SIRTUNEI for a single-user run is treated
as an override to the single-user default.
That is, if the following is the first COLLECT statement
in SIRTUNEI for a single-user run:
<nowiki>COLLECT RUNG
</nowiki>
it would turn off data collection for
all other user states in the single-dser default and for DISKIO data.
==EXClude [start_time end_time] [days_of_week]==

This statement makes it possible to limit the times
in which sample data is collected.
Note that compilation data is
always collected, whether or not sample data is being collected.

start_time and end_time can have the format
HH, HH:MM, or HH:MM:SS, where HH represents an hour of the day, MM
represents minutes, and SS represents seconds.
The maximum allowable
time is 24 or 24:00 or 24:00:00, which corresponds to midnight.


For example, the following
indicates that no sample data should be collected from midnight through
8 AM every day of the week:
<nowiki>EXCLUDE 0 8
</nowiki>


The following
indicates that no sample data should be collected from 11:30 AM
through 1:30 PM every day of the week:
<nowiki>EXCLUDE 11:30 13:30
</nowiki>


The following
indicates that no sample data should be collected from 30 seconds
before 12 noon through 50 seconds after 1 PM every day of the week:
<nowiki>EXCLUDE 11:59:30 13:00:50
</nowiki>


If start_time is greater than end_time,
the times are assumed to wrap.
For example, the following
means that no sample data should be collected between 11 PM and 1 AM:
<nowiki>EXCLUDE 23:00 1:00
</nowiki>


days_of_week is a blank-delimited list of days of the week.
The following are valid days of the week, with the
minimum abbreviations in uppercase:
<ul>
<li>SUNday
<li>MONday
<li>TUEsday
<li>WEDnesday
<li>THUrsday
<li>FRIday
<li>SATurday
</ul>


For example, the following
indicates that no sample data should be collected all day Sundays and Saturdays:
<nowiki>EXCLUDE SUNDAY SAT
</nowiki>


The following
indicates that no sample data should be collected from 6:30 PM through
midnight on Mondays through Fridays:
<nowiki>EXCLUDE 18:30 24:00 MOND TUES WEDN THU FRIDAY
</nowiki>

In addition to the days of the week, the following groupings are
also available in a days_of_week list:
<ul>
<li>WEEKDay = Monday, Tuesday, Wednesday, Thursday, Friday
<li>WEEKEnd = Saturday, Sunday
<li>ALL = Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday
</ul>


For example, the following
indicates that no sample data should be collected all day Saturday through
Sunday:
<nowiki>EXCLUDE WEEKE
</nowiki>


The following
indicates that no sample data should be collected on any day of
the week:
<nowiki>EXCLUDE ALL
</nowiki>


The following
indicates that no sample data should be collected between 10 AM and 12 noon
on Sunday, Saturday, and Monday:
<nowiki>EXCLUDE 10 12 WEEKEND MONDAY
</nowiki>


The following
indicates that no sample data should be collected between 11 PM and midnight
on all days of the week:
<nowiki>EXCLUDE 23:00 24:00 ALL
</nowiki>


Note that the statement above is identical to this:
<nowiki>EXCLUDE 23:00 24:00
</nowiki>

If no INCLUDE or EXCLUDE statements occur in SIRTUNEI, sample data is
collected as if INCLUDE ALL had been specified.

The order of INCLUDE
and EXCLUDE statements in SIRTUNEI is important:
If the first INCLUDE
or EXCLUDE statement in SIRTUNEI is <code>EXCLUDE</code>, it is treated as if it
were preceded by an <code>INCLUDE ALL</code>.
That is, data will only not be collected over
intervals explicitly indicated by EXCLUDE statements.


For example,
if this is the only INCLUDE or EXCLUDE statement in SIRTUNEI:
<nowiki>EXCLUDE 0 9
</nowiki>
sample data will be collected between 9 AM and midnight every day of
the week.
No data will be collected at other times.
If SIRTUNEI contains the following sequence,
data should be collected on Monday, Tuesday, Wednesday, Thursday, Friday, and
Saturday:
<nowiki>EXCLUDE WEEKEND
INCLUDE SATURDAY
</nowiki>


If SIRTUNEI contains the following sequence,
data should be collected on every weekday from 8 AM to 5 PM and on Fridays
from 10 PM to midnight:
<nowiki>EXCLUDE WEEKEND
EXCLUDE 0 8
EXCLUDE 17 24
INCLUDE 22 24 FRIDAY
</nowiki>


Note that there is no harm in EXCLUDE'ing a range
that has already been excluded.
For example, the following
<nowiki>EXCLUDE 0:00 7:00
EXCLUDE 4:00 10:00
</nowiki>
is the same as
<nowiki>INCLUDE 0:00 10:00
</nowiki>

The INCLUDE/EXCLUDE statements are only honored if sampling is set
to AUTO (automatic) mode, either by default or via a SAMPLE statement or
a MODIFY or SMSG SAMPLE command.
When sampling is in manual mode, INCLUDE/EXCLUDE statements have no effect.

Generally, you should use the INCLUDE/EXCLUDE statements to avoid
collecting data for time intervals in which there is nothing interesting
likely to be happening, that is, periods of low activity.
The only
real cost of this is the disk space and the minor amount of CPU
consumed collecting this sample data.


If you are only interested in collecting data at peak hours, say
10 AM to 11:30 AM and 1:30 PM to 4 PM on weekdays, simply put
the following in SIRTUNEI:
<nowiki>INCLUDE 10 5 WEEKDAY
EXCLUDE 11:30 13:30
</nowiki>
==INClude [start_time end_time] [days_of_week]==

This statement makes it possible to limit the times
in which sample data is collected.
Note that compilation data is
always collected, whether or not sample data is being collected.

start_time and end_time can have the format
HH, HH:MM, or HH:MM:SS where HH represents an hour of the day, MM
represents minutes, and SS represents seconds.


The maximum allowable
time is 24 or 24:00 or 24:00:00, which corresponds to midnight.
For example, the following
indicates that sample data should be collected from 8 AM through
6 PM every day of the week:
<nowiki>INCLUDE 8 18
</nowiki>


The following
indicates that sample data should be collected from 8:30 AM
through 5:30 PM every day of the week:
<nowiki>INCLUDE 8:30 17:30
</nowiki>


The following
indicates that sample data should be collected from 10 seconds
before 9 AM through 10 seconds after 5 PM every day of the week:
<nowiki>INCLUDE 8:59:50 17:00:10
</nowiki>


If start_time is greater than end_time,
the times are assumed to wrap.
For example, the following
means that sample data should be collected between 11 PM and
1 AM:
<nowiki>INCLUDE 23:00 1:00
</nowiki>

days_of_week is a blank-delimited list of days of
the week.
The following are valid days of the week, with the
minimum abbreviations in uppercase:
<ul>
<li>SUNday
<li>MONday
<li>TUEsday
<li>WEDnesday
<li>THUrsday
<li>FRIday
<li>SATurday
</ul>


For example,
indicates that sample data should be collected all day Mondays and Tuesdays:
<nowiki>INCLUDE MONDAY TUE
</nowiki>


The following
indicates that sample data should be collected from 8:45 AM through
5:45 PM on Mondays through Fridays:
<nowiki>INCLUDE 8:45 17:45 MOND TUES WEDN THU FRIDAY
</nowiki>


In addition to the days of the week, the following groupings are
also available in a days_of_week list:
<ul>
<li>WEEKDay = Monday, Tuesday, Wednesday, Thursday, Friday
<li>WEEKEnd = Saturday, Sunday
<li>ALL = Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday
</ul>


For example, the following
indicates that sample data should be collected all day Monday through
Friday:
<nowiki>INCLUDE WEEKD
</nowiki>


The following
indicates that sample data should be collected all day on every day of
the week:
<nowiki>INCLUDE ALL
</nowiki>


The following
indicates that sample data should be collected between 10 AM and 12 noon
on Sunday, Saturday, and Monday:
<nowiki>INCLUDE 10 12 WEEKEND MONDAY
</nowiki>


The following
indicates that sample data should be collected between 11 PM and midnight
on all days of the week:
<nowiki>INCLUDE 23:00 24:00 ALL
</nowiki>


Note that the above statement is identical to this:
<nowiki>INCLUDE 23:00 24:00
</nowiki>

If no INCLUDE or EXCLUDE statements occur in SIRTUNEI, sample data is
collected as if INCLUDE ALL had been specified.

The order of INCLUDE
and EXCLUDE statements in SIRTUNEI is important:
If the first INCLUDE
or EXCLUDE statement in SIRTUNEI is <code>INCLUDE</code>, it is treated as if it
were preceded by an <code>EXCLUDE ALL</code> (that is, data will only be
collected over intervals explicitly indicated by INCLUDE statements).


For example,
if this is the only INCLUDE or EXCLUDE statement in SIRTUNEI:
<nowiki>INCLUDE 9 17
</nowiki>
sample data should be collected between 9 AM and 5 PM every day of
the week.
No data should be collected at other times.
If SIRTUNEI
contains the following sequence:
<nowiki>INCLUDE WEEKDAY
EXCLUDE TUESDAY THURSDAY
</nowiki>
data should be collected on Monday, Wednesday, and Friday.
If SIRTUNEI contains the following sequence:
<nowiki>INCLUDE 8 17 TUESDAY
EXCLUDE 11 14
INCLUDE 12 13 TUESDAY
</nowiki>
data should be collected on Tuesdays from 8 AM to 11 AM, 12 noon to 1 PM,
and 2 PM to 5 PM.
<blockquote class="note">Note: There is no harm in INCLUDE'ing a range that has already been included.
For example, the following range
<nowiki>INCLUDE 9:00 13:00
INCLUDE 12:00 17:00
</nowiki>
is the same as
<nowiki>INCLUDE 9:00 17:00
</nowiki>
</blockquote>

The INCLUDE/EXCLUDE statements are only honored if sampling is set
to AUTO (automatic) mode, either by default, or via a SAMPLE statement or
a MODIFY or SMSG SAMPLE command.
When sampling is in manual mode,
INCLUDE/EXCLUDE statements have no effect.

Generally, you should use the INCLUDE/EXCLUDE statements to avoid
collecting data for time intervals in which there is nothing interesting
likely to be happening, that is, periods of low activity.
The only real cost of collecting data in periods of low activity
is wasted disk space and a minor amount of CPU
consumed collecting the sample data.


If you are only interested in collecting data at peak hours, say
10 AM to 11:30 AM and 1:30 PM to 4 PM on weekdays, simply
put the following statements into SIRTUNEI:
<nowiki>INCLUDE 10 11:30 WEEKDAY
INCLUDE 1:30 4 WEEKDAY
</nowiki>
==INTerval num_sec==

This statement is used to set the sampling rate,
thus making it possible to limit the amount of sample data
collected.
The default for num_sec is 1, which
means that sample data is collected at one-second intervals.


The values specified for num_sec have a maximum
resolution of 1/100 of a second so that
<nowiki>INTERVAL 3.1415929
</nowiki>


is identical to
<nowiki>INTERVAL 3.14
</nowiki>
This also means that the lowest legal value for num_sec
is 0.01.

The objective in setting the sampling interval should be to
collect sufficient data to produce statistically significant
results, without collecting unnecessarily huge amounts of data.
Setting the sampling interval extremely low can also produce
biased results.
Generally, sampling intervals greater than 0.1
seconds should avoid any biasing problems.


A reasonable rule of thumb is that 10,000 samples are
sufficient to produce accurate reports.
Thus to collect
data on a batch job that generally takes half an hour to
complete, samples should be collected every 1800/10000 seconds.
To accomplish this,
place the following statement into SIRTUNEI:
<nowiki>INTERVAL 0.18
</nowiki>


If data is to be collected over 8 hours of a production
ONLINE run, the default sampling interval of 1 second
would result in 8*3600 or 28,800 samples
being collected.
In this case, it would not be unreasonable to place
the following statement
into SIRTUNEI to reduce the number of samples collected to 14,400:
<nowiki>INTERVAL 2
</nowiki>
==MIXed==

Status: This parameter is deprecated as of Version 7.2.
If it is specified as an input parameter, it is ignored.

This statement indicates that <var class="product">SirTune</var> should issue all messages
in mixed-case.
The default is to issue messages in mixed-case except on Japanese
operating systems.
On these systems,
the default is to issue all messages in uppercase only.
This option should be used on Japanese operating systems when
mixed-case messages are desired.
==NOSeq==

This statement indicates that <var class="product">SirTune</var> should not consider
characters in columns 73 through 80 of SIRTUNEI as part of
its input.
If SIRTUNEI has RECFM=F and LRECL=80, <var class="product">SirTune</var>
ordinarily assumes that characters in columns 73 through 80 are
sequence numbers, and therefore it ignores them.
If SIRTUNEI has any
other format, <var class="product">SirTune</var> considers all characters in the input record
as part of the <var class="product">SirTune</var> statements.
==PGM pgm_name==

Effective in version 1.5 of <var class="product">SirTune</var> and lower, this statement is ignored
in versions after 1.5.

The PGM statement makes it possible to specify the name
of the <var class="product">Model 204</var> ONLINE load module to be loaded by the SIRTUNE module.
The default for pgm_name is <code>ONLINE</code>
under MVS, and it is <code>M204ONLN</code> under CMS.


Thus, if SIRTUNE is to collect data for a job that should be
run with BATCH204, put the following statement into SIRTUNEI:
get non-BATCH204 example 
<nowiki>PGM BATCH204
</nowiki>


If the name of the load
module for which SIRTUNE is to collect data is ONLINE22,
put the following statement into SIRTUNEI:
<nowiki>PGM ONLINE22
</nowiki>

<div id="precomp"></div>
==PREComp==



This statement specifies that <var class="product">SirTune</var> should only collect compilation
data for pre-compiled APSY procedures;
it is the inverse of the ALLCOMP command ([[#allcomp|ALLComp]]).

The default for a single-user run (NUSERS = 1) is that <var class="product">SirTune</var> collects
compilation data for all procedures.
The default for a multi-user run (NUSERS > 1)
is that <var class="product">SirTune</var> collects compilation data only for pre-compiled procedures.
It is unnecessary to specify PRECOMP in a multi-user run, since it is the default.

When PRECOMP is in effect, either because of an explicit PRECOMP statement
or as the result of multi-user run defaults, the reporting module
can produce line-by-line breakdowns
for pre-compiled APSY procedures only.
==SAMPle ON | OFF | AUTO==

This statement places <var class="product">SirTune</var> in manual sampling mode.
In this mode, <var class="product">SirTune</var> ignores INCLUDE and EXCLUDE statements
until a <code>SAMPLE AUTO</code> command is issued via a MODIFY
or SMSG command issued by an authorized user.
The default for this statement is SAMPLE AUTO, which places
<var class="product">SirTune</var> under the control of INCLUDE and EXCLUDE statements.


For example, to have <var class="product">SirTune</var> come up so that no sample data
is collected until a user issues a (MODIFY or SMSG) SAMPLE command to
turn sampling off or to put sampling in AUTO mode, simply
place the following statement into SIRTUNEI:
<nowiki>SAMPLE OFF
</nowiki>


To have <var class="product">SirTune</var> come up so that sample data
is collected until a user issues a MODIFY or SMSG SAMPLE command,
place the following statement into SIRTUNEI:
<nowiki>SAMPLE ON
</nowiki>
<blockquote class="note">Note: If SAMPLE OFF is specified in SIRTUNEI and there are no
AUTHORIZE statements in SIRTUNEI, it will be impossible to
collect any sample data for the course of the run, because no
user will have the authority to issue the MODIFY or SMSG SAMPLE
command to set sampling to ON or to AUTO.
</blockquote>
==UPper==

This statement indicates that <var class="product">SirTune</var> should issue all messages
in uppercase only.
The default is to issue messages in mixed-case, except on Japanese
operating systems.
On these systems the default is to issue all messages in
uppercase only.

This option should be used on systems where mixed-case messages
might not be displayed correctly on terminals or printers.

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

[[Category: SirTune]]