You can request that particular timing information be
during an EXEC's execution. If you want to display the time
which each command executes, you can specify: SCONTROL TIME displayed
of day at
Then, as each co.mand line is displayed, it is prefaced with the time;
for exallple: SCONTROL eMS TIME QUERY BLIP executes as follows:
10:34:16 QUERY BLIP BLIP = *
If you wish to see, following the execution of each CMS cOllmand, specific CPU timing information, such as the long form of the ready
message, you can use the STIME control statement. For example: STIME ON QUERY BLIP QUERY FILEDEF
might execute as: QUERY BLIP BLIP = OFF T=0.01/0.04 10:44:21 QUERY FILEDEF NO USER DEFINED FILEDEF'S IN EFFECT T=0.01/0.04 10:45:26
Handling Error Returns from CMS Commands
In many cases, you want to execute a command only if previous commands
were successful. For example, you would not want to execute a PRINT command to print a file if you had been unable to access the disk on
which the file resided. There are two methods, using EXEC procedures,
that allow you to monitor and control what happens following the
execution of CMS commands. One method uses the EXEC control statement SERROR to transfer control when an error occurs; the other tests the
special variable SRETCODE upon completion of a CMS command to determine
whether that particular command completed successfully. USING THE SERROR CONTROL STATEMENT When a CMS command is executed within an EXEC, a return code is passed
to the EXEC interpreter, indicating whether or not the command completed
successfully. If the return code is nonzero, EXEC then activates the SERBOR control statement currently in effect. For example, if the
following statement is included at the beginning of an EXEC file: SERROR SEXIT then, whenever a CMS command (or user program) completes with a nonzero
return code, the SHXIT statement in the SERROR statement is executed,
and the EXEC terminates processing. You might use a similar statement 300 IBM VM/370 CMS User's Guide

in your EXECs to ensure that they do not attempt to continue processing
in the event of an error.
An &ERROR control statement can specify any executable statement. It may transfer control to another portion of the EXEC, or it many be a
single statement that executes before control is returned to the next
statement in the EXEC. For example: &ERROR &GOTO -EXIT transfers control to the label -EXIT, in case of any CMS error. The
statement: &ERROR &TIPE eMS ERROR results in the display of the message "CMS ERROR" before returning
control to the statement following the command that caused the error.
If you de not have an &ERROR control statement in an EXEC, or if you
specify &ERROR with no operands, EXEC takes no special action when a CMS command returns with an error return code. Specifying &ERROR with no
operands is the same as specifying: &ERROR &CONTINUE Since an SERROR control statement remains in effect for the remainder
of the EXEC execution, or until another &ERROR control statement is
encountered, you may use &ERROR &CONTINUE to restore default processing. USING THE &RETCODE SPECIAL VARIABLE
An error return from a CMS command, in addition to calling an &ERRCR control statement, also places the return code value in the EXEC special
variable &RETCODE. Following the execution of any CMS command in an EXEC procedure, you can test whether or not the command completed
without error. For example: TYPE ALPHA FILE A &IF &RETCODE 0 &EXIT TYPE BETA FILE A SIP &RETCODE 0 &EXIT Note that the value of &RETCODE is modified after the execution of each CMS command.
The value of &RETCODE is affected by your own programs. If you
execute a program in your EXEC using the LOAD and START (or FETCH and
START) commands, or if you execute a MODULE file, then the &RETCODE special variable contains whatever value was in general register 15 when
the program exited. If you are nesting EXEC procedures, then &RETCODE contains the value passed from the &EXIT statement of the nested EXEC. You can use the value of the return code, .as well, to analyze the
extent or the cause of the error and to set up an error analysis routine
accordingly. For example, suppose you want to set up an analysis
routine to identify return codes 1 through 11 and to exit from the EXEC when the return code is greater than 11. When a return code is
identified, control is passed to a corresponding routine that attempts
to correct the error. You could set up such an analysis routine as
follows:
Section 15. Using EXECs with CMS Commands 301