SirTune MODIFY and SMSG commands

Users outside the Model 204 or SIRTUNE/Model 204 address space can be authorized to issue certain commands to SirTune while the ONLINE job is running. Users can be authorized to do this with SirTune's AUTHORIZE command. For more information on the AUTHORIZE command, see SirTune data collection statements.

Under MVS, these commands can be issued via the MODIFY operator command. This command can be issued at an operator console or under SDSF or an equivalent virtual console system. For example, to issue the STATUS command to SirTune running under job PRODONLN under SDSF's LOG screen, you can simply enter:

/MODIFY PRODONLN,STATUS

or:

/F PRODONLN,STATUS

Responses to MODIFY commands go to the system log and should be viewable under SDSF.

Under CMS, these commands can be issued via the SMSG CP command. For example, to issue the STATUS command to SirTune running on a virtual machine named PRODONLN, you can enter:

SMSG PRODONLN STATUS

or:

CP SMSG PRODONLN STATUS

Responses to SMSG commands are sent via MSGNOH, if the SirTune/Model 204 service machine is authorized to use MSGNOH, and they are sent via MSG otherwise.

Available MODIFY/SMSG commands are listed here. Optional statement parameters are enclosed in brackets ([]). Alternatives are separated with a vertical line (|).

BUMP user_num

This command requests that SirTune issue the equivalent of the Model 204 BUMP command against the indicated user number. This command is useful if a high priority user is looping in an ONLINE, making it impossible for anyone else to do anything. To "bump" user number 18, issue this command:

BUMP 18

Unlike the Model 204 BUMP command, the SirTune BUMP command accepts only a single user number, and it does not accept user IDs or file names. To determine the user number of the running user, issue SirTune's MONITOR command. It is recommended that the MONITOR command be issued several times to ensure that a single user is indeed looping and that a performance problem is not simply the result of excess demand.

If a loop situation is caused by a Model 204 bug, it is possible that a BUMP command will fail to force the looping user off the system. In this case, it might be necessary to issue the RESTART command to break the loop.

CLOSE

This command requests that SirTune close the sample data set. This makes it possible to run the report generator against a sample data set that is still being updated by SirTune.

This command has no effect on sampling activity in the Model 204 address space.

MONITOR

This command requests that SirTune return information about what is currently happening in Model 204. This command is especially useful if Model 204 appears to be hung or looping and, hence, it is impossible to log on to Model 204 to determine the cause of the problem.

Information is returned for the main Model 204 task and any subtasks (if the MP/204 feature is being used). The information returned indicates whether each task is running or waiting (corresponding to looping and hung situations respectively), and where in the Model 204 load module the task is running or waiting. This latter piece of information is most useful to Model 204 internals experts.

If any Model 204 task is indicated as running, information is also provided on the user number and user ID of the running user, the current activity (evaluating, compiling, etc.), and the name of the procedure that is currently running. This information can be used to determine whether a BUMP or RESTART command should be issued.

RESTART abend_code USER user_num | TASK task_num

This command requests that SirTune issue the equivalent of a user abend in Model 204 for the indicated user or task.

RESTART should be used only as a last resort when a Model 204 ONLINE is looping or hung, and all efforts to clear up the situation have failed (see the BUMP command). In this situation, the only options left are to cancel (FORCE under CMS) the run or to issue SirTune's RESTART command.

The RESTART command is preferable because:

• The ONLINE might intercept the abend, possibly take a snap dump, and then continue running.
• Even if the ONLINE does not continue, it might at least intercept the abend and terminate "cleanly," preventing files from being broken and eliminating the need to run recovery. Cancelling or forcing the ONLINE ensures that:
  • Any files with active updating transactions will be left broken.
  • Recovery will have to be run before the ONLINE can be used again.
• The RESTART command will generally result in a CCASNAP being taken rather than (or in addition to) a SYSMDUMP, SYSUDUMP, or VMDUMP. CCASNAPs are generally easier to deal with than other types of dumps.

The abend_code value must be a 1- to 3-digit hexadecimal code that indicates the abend code to be used for the artificially generated abend. Under CMS the abend code must be between 0C1 and 0CF. Any dumps will indicate the specified abend code. It is important to inform support personnel examining the dump that the abend code was artificially generated by SirTune and that the situation was actually a hung or looping ONLINE.

To prevent accidentally terminating a user or an ONLINE, a user number can be specified on the restart command. When a user number is specified on the RESTART command, no simulated abend will occur if the indicated user is not running in the ONLINE. For example, the following RESTART simulates a 0C4 abend if user 23 is running. If user 23 is not running, no abend will be simulated.

RESTART 0C4 USER 23

If no user is running (a hung ONLINE), it might be necessary to issue the RESTART command with a task number instead. Unless running MP/204, the task number must be specified as 0. If MP/204 is running, the task number must be 0 (for the maintask) or the subtask number (from 1 to NMPSUBS) to be restarted. For example, the following RESTART simulates a 0A9 abend on the Model 204 maintask:

RESTART 0A9 TASK 0

Note: It is almost always preferable to specify a user number on the RESTART command rather than a task number.

SAMPLE ON | OFF | AUTO

This command does one of the following:

• Places sampling back into automatic mode (SAMPLE AUTO), where sampling is controlled by INCLUDE/EXCLUDE statements in SIRTUNEI.
• Initiates (SAMPLE ON) or terminates (SAMPLE OFF) collection of sample data.

This command has no effect on the collection of compilation data: Compilation data is collected regardless of the sampling state.

For example, to immediately start collecting data, issue the following command:

SAMPLE ON

To immediately stop collecting data, issue:

SAMPLE OFF

After a SAMPLE ON or SAMPLE OFF command is issued, SirTune is in "manual" sampling mode.

STATUS

This command requests the current sampling status of SirTune.

SirTune's response to this command indicates the current sampling mode (AUTO or MANUAL), the current sampling state (ON or OFF), and the number of samples collected to this point.

STOP

This command requests that SirTune do both of these:

• Stop collecting both sampling and compilation data.
• Close the sample data set.

After STOP is issued, sampling cannot be restarted for the run. Since the sample data set is closed by a STOP command, it is possible to use this data set to generate reports after a STOP command, even while the ONLINE job continues to run.

See also

• SirTune introduction
• SirTune data collection under MVS
• SirTune data collection under CMS
• SirTune data collection statements
• SirTune MODIFY and SMSG commands
• SirTune report generation
• SirTune reports
• SirTune user states
• SirTune and Model 204 quad types
• SirTune statement wildcards
• SirTune date processing