GROUP FILE (X);

If X is an input file, records are skipped until a group-delimiter is encountered. The file is then posi-tioned immediately following the group-delimiter.

2. GROUP;

Since no file is specified, the GROUP sta1:ement positions the current file. If the current file is an output file a group-delimiter is placed on the file, where i t is cur-ren"tly positioned, and the group is released from the program. If the current file is an input file, records are spaced until a group mark is encountered.

The IF S·tatemen-t::

Function:

The IF statE~ment causes program flow to depend on the value of an expression.

General format:

IF .scalar-expression THEN unit-1 [ELSE uni t-2]

Syntax rules::

1. Each "unit" is either a group or a begin block, either of which would be terminated by a semicolon.

2. The IF statement is not itself termi-nated by a semicolon.

General rules:

1. When the ELSE clause -- ELSE, and its following unit is not specified, the scalar expression is evaluated and, if necessary, converted to a bit string. If any bit in the resulting string has the value 1, the unit is executed, and control passes to the statement following the IF statement.

If all bits have the value 0, the unit is not executed, and control passes to the next statement. When the ELSE clause is specified, the expression is similarly evaluated. If any bit is 1, unit-1 is executed, and control passes to the statement following the IF statement. If all bits have the value 0, unit-2 is executed, and control

pass~s to the next statement. The units may contain statements that specify ^transf~r of control (see

"Sequence of Control"), and so over-ride these normal sequencing rules.

2. IF statements may be nested, that is, either unit-1 or unit-2, or both, may themselves bE. IF statements. Since each ELSE clause is always associated with the innermost preceding IF, an ELSE with a null statement may be required to specify the desired effect.

1.

2.

Examples:

IF QUEUE EMPTY THEN CALL COMPILE;

ELSE GO TO MULTIPROCESS;

A: IF X > Y THEN IF Z W THEN

IF W < P THEN Y 1 ; ELSE P Q;

ELSE;

ELSE X

=

J: Z

=

The LAYOUT Statement Function:

The LAYOUT statement specifies the hori-zontal layout of data on input and output.

General format:

LAYOUT

[FILE (file-name [,file-name] ••• )]

[MARGIN (expression-1, expression-2)]

[TAB (expression [,expression] ••• )];

Syntax rules:

1. The options may appear in any order.

2. The "expressions" are scalaz expres-sions.

General rules:

1. The FILE option specifies the files to be operated upon. In the absence of a FILE option, the current file is used, or if there is no current file, the standard output file is assumed.

2. The MARGIN option specifies left and right margins. The values of both expressions are converted to integers when the LAYOUT statement is executed.

These values are interpreted as the positions of the left and right mar-gins of the record and line, respec-tively, relative to the beginning of the record or line. On input, data before the left margin or after the right margin is ignored. On output, the first data item of a record or line is aligned on the left margin, with blanks before it; data is not placed beyond the right margin. If the left margin is specified to the right of, or equal to the right mar-gin, or if either margin is negative, the ERROR condition is raised.

3. ThE. TAB option specifies tabbing. The expressions are converted to integers when the LAYOUT statement is executed.

The values are used to indicate char-acter pOSitions from the left end of the line or record. These values need

not be in ascending order. Column 1 is the leftmost column. During list-directed and data-directed output, successive items are aligned on suc-cessive free tabs. There is a default tabbing for list- and data-directed output which is implementation defined. There is no automatic tab-bing on input. During format-directed transmission, alignment on a tab can be achieved by use of the TAB format item. In other cases, alignment on a tab can be achieved by using the TAB statement.

4. In the absence of a LAYOUT statement, system standards apply.

5. Execution of a LAYOUT statement des-troys all options established by a previously executed LAYOUT statement for the same file.

The Null Statement Function:

The null statement causes no action and does not modify sequential operation.

General format:

[label:]

...

Example:

ON OVERFLOW;

The on-unit (see liThe ON Statement") is a null statement.

'Ihe ON Statement Function:

The ON statement specifies the action to be taken when an interrupt occurs for the named condition. For a discussion of

"enable" and "interrupt," see "Interrupt

"Operations" in Chapter 6.

General format:

Option 1

ON condition [SNAP] on-unit

Option 2

ON condition SYSTEM;

Syntax rules:

1. The ^II condition" may be anyone of those described in Appendix 3.

2. The "on-unit" is an action specifi-cation and i t is either an unlabeled single simple statement (other than BEGIN, DO, END, RETURN, or DECLARE) or an unlabeled begin block. Since the on-unit itself requires a semi-colon, no semi-colon appears in Option 1.

3. The on-unit may not be a RETURN state-ment, nor may a RETURN statement appear within the begin block.

General rules:

1. The standard action to be taken for all ON-conditions is established by the language. When an interrupt takes place before an ON statement for that condition has been executed, standard system action is taken. This standard system action is described in Appendix 3. The ON statement in Option 2 specifies that standard system action is to be taken when an interrupt results from the occurrence of the specified condition.

2. The ON statement in Option is a means for the programmer to specify a special action, that is, execution of the on-unit, to take place when an interrupt occurs for the specified condition.

3. In Option 1, if SNAP is specified, then when the given condition occurs, a calling trace is listed.

4. Control can reach an on-unit only when an interrupt occurs for the condition associated with this on-unit in an ON statement.

5. If an action specification is esta-blished by an ON statement in a given block, i t remains in effect throughout this block and throughout all dynamic descendants of this block (see

"Activation and Termination of Blocks," in Chapter 6, for a discus-sion of blocks and generations of blocks) •

If an action is specified more than once in a given block, the effect of the old (or prior) ON statement is either temporarily suspended or com-pletely nullified by the new (or later) ON statement, as follows:

a. If the new (or later) ON statement is in a block dynamically descend-ed from the block containing the old (or prior) ON statement, the

effec1: of the old ON statement is temporarily suspended or stacked.

The effect of the old ON statement is restored upon termination of the block containing the new ON statement.

b. If thE! new (or later) ON statement~

and the old (or prior) ON state-ment are internal to the same block, the effect of the old ON statement is completely nullified.

6. If an action is specified by an ON statement in a particular task, the effect of this ON statement is inher-i tE~d by each attached task and by each task atta.ched by the attached task, etc. (see QAsynchronous Operations and Tasks," in Chapter 6 , for a discussion of attached and attaching tasks) •

7. A condition raised during execution results in an interrupt if and only if the condition is enabled at the point where i t is raised.

a. The conditions OVERFLOW, UNDER-FLOW, ZERODIVIDE, CONVERSION, the input output conditions, and the conditions CONDITION, FINISH, and ERROR are enabled by default.

b. The conditions SIZE, SUBSCRIP-TRANGE, and CHECK are disabled by default.

c. The enabling status of OVERFLOW, UNDERFLOW, ZERODIVIDE, CONVERSION, SIZE, SUBSCRIPTRANGE, and CHECK are controlled by the condition prefix (see "Prefixes" in Chapter