&IF &INDEX = 0 &GOTO -HELP &IF &INDEX = 1 &IF &1 = ? &GOTO -TELL &EXIT -HELP &BEGTYPE &END &EXIT CORRECT FORM IS • COpy OLDFN OLDFT NEWFN • TYPE • COpy ? • FOR MORE INFO -TELL &BEGTYPE &END &EXIT CORRECT FORM IS • COPY OLDFN OLDFT NEWFN • USES COPYFILE COMMAND TO CHANGE ONLY THE FILENAME This type of annotating is especially useful if you share your disks or
your EXECs with other users.
Error Situations
It is good practice, when writing EXECs, to anticipate error situations
and to provide meaningful error or information messages to describe the
error when it occurs. The following error situations, and suggestions
for handling them, have already been discussed: • Errors in invoking the EXEC, either
arguments, or with invalid arguments.
14. Building EXEC procedures.")
with an improper number of (See "Arguments" in "Section • Errors in CMS command processing that can be detected with an &ERROR control statement or with the &RETCODE special variable. (See "Handling Error Returns from CMS Commands" in "Section 15. Using EXECs With CMS Commands.") Many different kinds of errors may also occur, in the processing of
your EXEC control statements. EXEC processing errors, such as an attempt
to branch to a nonexistent label or an invalid syntax, are
"unrecoverable" errors. These errors always terminate EXEC processing
and return your virtual machine to the CMS environment or to the calling EXEC procedure or program. The error messages produced by EXEC, and the
associated return codes, are described in the WRITING ERROR MESSAGES One way to make your EXECs more readable, especially if they are long EXECs, is to group all of your error messages in one place, probably at
the end of the EXEC file. You may also wish to number your messages and
associate the message number with a label number and a return code. For
example: 306 IBM VM/310 eMS User's Guide

SIF SCT > 100 SGOTO -ERR100 SIF SCT < 0 SGOTO -ERR200 SIF SRETCODE EQ 28 SGOTO -ERR300 -ERR100 STIPE COUNT TOO HIGH SEIIT 100 -ERR200 STIPE COUNT TOO LOW SEIIT 200 -ERR300 STYPE S1 S2 BOT ON DISK 'ct. SEIIT 300 There is a facility, available in the EIEC processor, which allows you
to write error messages that use the standard VM/370 message format, with an identification code and message number, as well as message text. When you use the SEMSG or SBEGEMSG control statement, the EXEC interpreter scans the first token and checks to see if the seventh (and
last character) is an I, E, or W, representing information, error, or
warning messages, respectively. If so, then the message is displayed according to the CP EMSG setting (ON, OFF, CODE, or TEXT). For example,
if you have the statement: SEMSG ERROR1E BAD ARGUMENT ' S1 '
the ERROR1E is considered the code portion of the message and BAD ARGUMENT is the text. If you have issued the CP command:
cp set emsg text
when this SEMSG statement is executed it may display:
BAD ARGUMENT ' PRNIT '
where PRNIT is the argument that is invalid. When you use SEMSG (or SBEGEMSG, which allows you to display error messages of unscanned data), the code portion of the message is prefixed
with the characters DMS, when displayed. For example: SBEGEMSG ERROR2E INCOMPATIBLE ARGUMENTS &END
displays when the EMSG setting is ON: DKSERROR2E INCOMPATIBLE ARGUMENTS Iou should use the &BEGEMSG control statement when you want to display
lines that have tokens longer than characters; however, no
variable substitution is performed.
section 16. Refining Your EXEC Procedures 307