Debugging EXEC Procedures
If you have difficulty getting an EXEC procedure to execute properly, or
if you are modifying an existing EXEC and wish to test it, there are a
couple of simple techniques that you can use that may save you time. One is to place the &CONTROL ALL control statement at the top of your EXEC file. When &CONTROL ALL is in effect, all the EXEC control
statements are displayed before they execute, as well as the CMS command
lines. One of the advantages of using this method is that the line is
displayed after it is scanned, so that you can see the results of symbol
and variable substitution.
"Stacking EXEC Files" in "Section 14. Building EXEC Procedures"
described a PREFIX EXEC, which changes the prefixes of groups of files.
If the EXEC had an &CONTROL ALL statement, it might execute as follows:
prefix pt ag &CONTROL ALL &LNAME = &CONCAT PT *
LISTFILE PT* SCRIPT * ( EXEC EXEC CMS &STACK &LOOP -END &READFLA EQ CONSOLE LOOP UNTIL: STAC K EQ CONS &READ VARS &NAME &TYPE &MOD &SUFFIX = &SUBSTR PTA 3 6 &NEWNAM = &CONCAT AG A
RENAME PTA SCRIPT 11 IGI SCRIPT 11 &IF 0 EQ 0 &SKIP &SKIP LOOP UNTIL: STAC K EQ CONS &READ VARS &HAME &TYPE &MOD &SUFFIX = &SUBSTR PTB 3 6 &NEWNAM = &CONCAT AG B RENAME PTB SCRIPT A1 AGB SCRIPT 11 &IF 0 EQ 0 &SKIP &SKIP LOOP UNTIL: CONS OLE EQ CONS R; You can see from this execution summary that the files named PTA SCRIPT and PTB SCRIPT are renamed to AGI SCRIPT and AGB SCRIPT. Notice that
the &LOOP statement results in a special LOOP UNTIL statement in the
execution summary, which indicates the condition under which the loop
executes. USING CMS SUBSET When you are using the CMS editor to create or modify an EXEC procedure,
you can test the EXEC in the CMS subset environment, as long as the EXEC does not issue any CMS commands that are invalid in CMS subset.
Before entering CMS subset with the CMS subcommand, you must issue
the SAVE subcommand to write the current version of the EXEC onto disk;
then, in CMS subset, execute the EXEC. For example: 308 IBM VM/370 CMS User's Guide

edit new exec NEW FILE:
EDIT:
input INPUT: &a = &1 + &2 + &3
&type answer is &a
EDIT:
save
EDIT:
cms CMS SUBSET new 34 56 899 ANSWER IS 989
R;
return
EDIT:
quit
R;
If the EXEC does not execute properly, you can return to the edit
environment using the RETURN command, modify the EXEC, reissue the SAVE and CMS subcommands, and attempt to execute the EXEC again. SUMMARY OF EXEC INTERPRETER LOGIC The following information is provided for those who have an interest in
how the EXEC interpreter works. It may help you in debugging your EXEC procedures if you have some idea of how processing is done by EXEC. When an EXEC file is invoked for execution, the EXEC interpreter
examines each statement and analyzes it, according to the following
sequence:
1. If the first nonblank character of the line is an *, the line is
counted and ignored.
2. Null lines, except as a reponse to an statement, are also
counted and ignored.
3. The line is scanned, and nonblank character strings are placed in
tokens.
4. All EXEC special variables, and then all user variables, except for
those that appear as the target of an assignment statement, are
substituted.
6. All blank tokens (resulting from the substitution of undefined
symbols) are discarded.
7. If the first nonblank character is a hYFhen (-), indicating a
label, the next token is considered the first token.
8. If the first logical token does not begin with an ampersand (&),
the line is passed to CMS for execution. return code from CMS is placed in the special variable &RETCODE.
9. If the first logical token begins with an ampersand (&) EXEC interprets the statement.
10. If a statement is syntactically invalid and can be made valid by
adding a token of blanks at the end, EXEC adds blanks, for example:
Section 16. Refining Your EXEC Procedures 309