CMS EXEC

CMS EXEC, or EXEC, is an interpreted, command procedure control, computer scripting language used by the CMS EXEC Processor supplied with the IBM Virtual Machine/Conversational Monitor System (VM/CMS) operating system.

EXEC was written in 1966 by Stuart Madnick at MIT on the model of CTSS RUNCOM. He originally called this processor COMMAND, and it was later renamed EXEC.[1]

CMS EXEC has been superseded by EXEC 2 and REXX. All three — CMS EXEC, EXEC 2 and REXX — continue to be supported by the IBM CMS product.

The EXEC language

[edit]
  • EXEC processes lines up to 130 characters long when entered from a terminal, or 72 characters when read from a file.
  • A label consisting of a dash followed by up to seven alphanumeric characters can prefix a CMS command or an EXEC control statement.
  • The interpreter parses commands into blank-delimited tokens of up to eight characters each.
  • Variables consist of an ampersand followed by up to seven alphanumeric characters. Variables can be either user-defined variables or pre-defined ("special") EXEC variables.
  • As each line is read the tokens are scanned. If they contain EXEC variables the variables are replaced by their value.
  • Comments. Comments in EXEC files begin with an asterisk in column one. All other statements are executable statements.
  • Null statements. A null statement contains no data items.
  • CMS commands. If the first data item on a line is not an asterisk or ampersand the EXEC processor considers the line to be a CMS command and passes it to CMS for immediate execution.
  • Assignment statements. An assignment statement assigns a value to an EXEC variable. It has the form &variable = <arithmetic-expression>
  • Control statements. A statement where the first data item is an EXEC control word and the second is not an equals sign is assumed to be a control statement.
  • EXEC control words:
    • &ARGS - allows the user to redefine command arguments.
    • &BEGPUNCH - heads a series of lines to be spooled to the user's virtual punch.
    • &BEGSTACK - heads a series of lines to be placed in the user's console input stack.
    • &BEGTYPE - heads a series of lines to be typed on the user's terminal.
    • &END - marks the end of the lines processed by &BEGPUNCH, &BEGSTACK, or &BEGTYPE.
    • &CONTINUE - tells the interpreter to process the next line in the file.
    • &CONTROL - controls the format in which messages are displayed.
    • &ERROR - tells the interpreter what to do if an error is detected.
    • &EXIT - exits the current EXEC file, and optionally sets a return code.
    • &GOTO - branches to another location in the current EXEC file. The location can be TOP for the beginning of the file, a label, or a line number.
    • &IF allows for conditional execution of statements.
    • &LOOP - heads a group of statements to be executed multiple times, or until a specified condition is true.
    • &PUNCH - sends a string of tokens to the user's virtual punch. Each &PUNCH statement generates one card-image, padded or truncated if necessary.
    • &READ - reads one or more lines from the user's terminal.
    • &SKIP - skips (ignores) a specified number of lines.
    • &SPACE - types a specified number of blank lines on the user's terminal.
    • &STACK - places one line in the user's input stack. The line is constructed from tokens as for &PUNCH.
    • &TIME - specifies what timing information is to be typed on the user's terminal following the execution of each CMS command.
    • &TYPE types a line on the user's terminal. The line is constructed from tokens as for &PUNCH.
  • Built-in functions. The EXEC interpreter provides a few "built-in" or predefined functions:
    • &CONCAT concatenates a string of tokens.
    • &DATATYPE examines a token and determines whether it is numeric or alphabetic.
    • &LENGTH returns the length of a token.
    • &LITERAL prevents variable substitution within a token.
    • &SUBSTR extract selected characters from a token.

Sample code

[edit]

PROFILE EXEC is an EXEC that is automatically executed when a user logs on to tailor their environment. A simple PROFILE EXEC might look like the following:

* The following code issues CMS commands to set * the "blip" character to asterisk and request * the "short" format for system ready messages. &CONTROL OFF SET BLIP * SET RDYMSG SMSG 
[edit]

References

[edit]
  1. ^ Varian, Melinda. "VM AND THE VM COMMUNITY: Past, Present, and Future" (PDF). Retrieved Mar 9, 2012.
[edit]