1 05/20/81 Changes to the exec_com command and absentee facility
2
3 A number of changes and additions have been made to the exec_com
4 command, the exec_com language, and the absentee facility.
5
6 The changes described in this file apply to the default, improved
7 but essentially compatible "version 1" exec_com language. A
8 completely incompatible "version 2" language can also be used,
9 which described in v2_exec_com.info and v2_exec_com.differences.info.
10
11
12 List of changes:
13 1) Exec_com active function
14 2) &return statement
15 3) Changes to &attach
16 4) Recursion check
17 5) Changes to &if statement syntax
18 6) Nested &if statements
19 7) Predicates: &is_af, &is_absin, &is_attached, &is_input_line
20 8) Redefinition of &0
21 9) Redefinition of &f
22 10) New expansion: &ec_switch
23
24
25 11) Implicit quoting of expansions
26 12) Redefinition of white space
27 13) New tracing statements: &control_line, &comment_line, &ready_proc
28 14) Changes to tracing statements
29 15) &version statement
30 16) Changed syntax of labels
31 17) New error message format
32 18) Absouts can become MSF's, and have strange bit counts.
33 19) Tracing statements can select the I/O stream for trace output.
34
35
36 Exec_com active function:
37 The exec_com command can be called as an active function. All
38 previously valid exec_com segments will return a null result.
39 Exec_com's which return a value will print it on the terminal when
40 invoked as commands.
41 Usage: ec path optional_args
42
43
44 &return statement:
45 A new statement is added to the exec_com language. It is equivalent to
46 the &quit statement, except that the expansion of the rest of the line
47 is the value of the exec_com. When exec_com is invoked as an active
48 function, the expansion will be substituted into the command line that
49 invoked it; when exec_com is invoked as a command, the expansion will
50 be printed on the terminal, with a trailing newline supplied. Unlike
51 the &print statement, the expansion will not be used as an ioa_ control
52 string see "ioa_.info". All leading whitespace will be removed from
53 the value returned.
54
55
56 Changes to &attach:
57 The &attach feature of exec_com has been changed to use
58 iox_$move_attach. This will cause information about the user_input
59 attachment to be preserved by exec_com. All methods of normal
60 termination of an exec_com &quit &return or running off the end
61 will now be treated as if an &detach statement had preceded the end.
62
63
64 Recursion check:
65 When the &attach mode is in effect, recursive calls for input such as
66 an attempt to read input from the active function expression of the &if
67 statement will be passed on to the I/O switch that would be used if
68 &attach were not in effect. When &attach mode is not in effect,
69 recursive invocations will result in the io_error condition being
70 raised; this should never happen in normal operation of the exec_com
71 command. In the .absin segment of an absentee process, such recursive
72 calls will result in immediate termination of the absentee process
73 there is no switch from which to obtain the input. The usual cause
74 of this is an active function in an &if test which asks a question of
75 the user.
76
77
78 Nested &if:
79 Nested &if statements are now defined to work. Any statement except
80 &label and &then may appear as the statement of an &then or &else
81 clause. They may be nested to any desired depth. &else statements
82 will be matched up to &if statements in a manner similar to PL/I
83 syntax: the closest unmatched &if preceding the &else will be used.
84 &then and &else statements remain the only exec_com statements which
85 need not begin at the beginning of a line; however, now only one
86 statement comprises a &then or &else clause, and no intervening
87 statements other than the &then clause are allowed between the &if
88 statement and the matching &else statement. Comments are allowed to
89 intervene between the &then and &else statements, but comments and
90 &label statements are forbidden as &then and &else clauses.
91
92
93 Changes to &if:
94 The &then and &else keywords are now required to be followed by white
95 space, and preceded by white space if they occur in the middle of a
96 line. Although this change is incompatible, users were probably
97 unaware that &then and &else keywords occurring in the middle of a line
98 did not need to be delimited by white space. Active functions are no
99 longer required in an &if statement. If the expanded string following
100 the &if is "true", then the &then clause will be executed; if it is
101 "false", the &else clause will be executed. This is intended for use
102 with parameters and predicates.
103
104
105 Predicates:
106 Three predicates have been added to the exec_com language. Each tests
107 a state Four the exec_com being executed, and is replaced by the string
108 "true" or the string "false" depending on the state.
109
110 &is_active_function, &is_af
111 is used to determine whether or not the exec_com was invoked as an
112 active function. Different behavior may be desired, although the
113 &return statement allows the programmer to disregard this when
114 writing the exec_com.
115 &is_absin
116 is used to determine whether this exec_com is the controling segment
117 of an absentee process. This is not the same as the result of the
118 user active function, since the segment may have been invoked as an
119 exec_com, and just happens to be in an absentee process.
120
121
122 &is_attached
123 is used to determine whether the &attach keyword is in effect at a
124 particular time in the execution of an exec_com. This relieves the
125 programmer from always having to know the &attach state merely by
126 the position within the exec_com. Note that this state is mutually
127 exclusive with &is_absin, since &attach is meaningless for the absin
128 segment.
129 &is_input_line
130 is used to determine if the line currently being read will be a
131 command line or an input line. All lines which are returned i.e.
132 non control lines are either command lines or input lines. This
133 applies, then, to the next non control line. For the moment, this
134 is exclusive with &is_absin.
135
136
137 Redefinition of &0:
138 &0 is now defined to be the expanded pathname that was used to find the
139 ".ec" or ".absin" segment. It is an absolute pathname with the
140 appropriate suffix appended. However, only lexical processing has been
141 done to it; links have not been chased.
142
143
144 Redefinition of &f:
145 &fN is defined to return a list of all the optional_args to the
146 exec_com command from the Nth through the last. However, &f0 does not
147 return &0; it starts with &1. This was done so that &f&n, which is
148 replaced by the last argument will be replaced by nothing when &n is
149 zero ie. when no optional_args were supplied.
150
151
152 New expansion:
153 A new expansion, &ec_switch, expands to the name of the I/O switch that
154 abs_io_ is currently using. In absentee processes, this will be
155 user_i/o, but in other applications it may be harder to predict. For
156 example, exec_com incorporates a 19 character unique string in the name
157 of the switch it uses. The construct is not expected to be terribly
158 useful in the exec_com or absentee environments although it could be
159 used to send control orders to abs_io_ in exec_com, but is intended
160 for use with abs_io_ in new applications.
161
162
163 Quoting of expansions:
164 The three expansions, &ec_dir, &ec_name and &ec_switch, have been
165 changed to perform substitution in the same way that &q1 substitutes
166 arguments. Normally, this will be completely transparent, but if you
167 use them in quoted strings and their expansions contain quotes, the
168 quotes in the expansions will be doubled, preventing an unbalanced
169 quotes error.
170
171
172 Redefinition of whitespace:
173 The definition of whitespace, which is required to delimit statement
174 keywords from their arguments, is now the same definition the
175 command_processor_ and abbrev use. Any of the characters SPACE,
176 HORIZONTAL TAB, VERTICAL TAB and FORMFEED are considered
177 interchangeable for use in exec_com statments. Newlines which occur in
178 the input segment are used to delimit lines and statements; however,
179 newlines which occur in expansions are treated as whitespace when
180 delimiting keywords. Newlines which occur in expansions on command or
181 input lines are passed back to the caller as part of a the line. No
182 special action is taken. This is similar in treatment to \012, which
183 causes the teletype dim to return a newline within a line.
184
185
186 New tracing statements:
187 Three new tracing statements were added to the exec_com language. Each
188 keyword takes a single argument, which may be one of "on", "off",
189 "true", and "false". There are two states; one is entered by either of
190 the keywords "on" or "true", the other is entered by "off" or "false".
191 If the keyword is unrecognized or absent, a warning message will be
192 printed and "on" will be assumed.
193
194 &control_line STATE
195 causes each exec_com statement executed to be printed on the
196 user_output switch before it is executed. The lines are printed in
197 expanded form; only those statements actually executed are traced
198 ie. in an &if statement only one clause will be traced. All
199 ampersand substitution will have been done before the lines are
200 printed; the active function of an &if statement will not have been
201 evaluated. By default, this mode is "off".
202
203
204 &comment_line STATE
205 causes each comment line passed in the normal flow of execution to
206 be traced. Each comment line will be printed in unexpanded form.
207 No tracing will be performed during &label search. By default, this
208 mode is "off".
209 &ready_proc STATE
210 causes the user's ready procedure to be invoked after each command
211 line is executed from the exec_com. Whether the ready procedure
212 prints anything or not is determined by the &ready statement. The
213 states of &ready_proc and &ready are completely independent. When
214 exec_com is invoked as a command, this mode is initially "on"; when
215 invoked as an active function, this mode is initially "off".
216 Neither of the keywords &ready_proc and &ready have any effect in an
217 absin segment.
218
219
220 Changes to tracing statements:
221 The three tracing statements &command_line, &input_line and &ready have
222 been extended to accept the keywords "true" and "false" as synonyms for
223 "on" and "off" respectively.
224
225 When exec_com is invoked as a command, &command_line and &input_line
226 are initially "on"; when it is invoked as an active function, they are
227 initially "off". &ready is always initially "off".
228
229
230 &version statement:
231 A statement has been added to the exec_com language to allow for future
232 incompatible changes in the syntax of the language. The statement is
233 only permitted on the very first line of the exec_com, and may have no
234 leading white space. It takes one argument, which for the current
235 version of exec_com must be "1". White space must be delimit &version
236 and its argument. Only white space may follow the version number on
237 the line. If a &version statement is present and the version number is
238 not implemented, the exec_com will not be executed.
239
240
241 Syntax of labels:
242 The syntax of labels in &label and &goto statements have changed.
243 Previously, they were terminated by the first white space, now they are
244 terminated by the end of the line. Trailing whitespace is ignored.
245 This change was made so that no non-blank characters on a &label or
246 &goto line would be ignored. Labels may now be of any length, from
247 zero characters to slightly less than a segment. Previously, they were
248 limited to 32 characters and silently truncated if they exceeded this
249 limit.
250
251
252 Error message format:
253 Error messages from exec_com and the absentee facility have been
254 greatly improved. They span from two to four lines, depending on how
255 much error message there is, and whether the source line can be
256 printed. In all cases the line number on which the error occurred and
257 the full pathname of the offending exec_com are printed. The source
258 line will always be printed, except for syntax errors occurring in
259 &else clauses which follow on the same line &then clauses which were
260 taken and which returned a command or input line.
261
262
263 Changes to absentee output file:
264 The absentee output file may become a multi-segment file using the new
265 abs_io_. Also, while the job is running or if the absentee process
266 terminates abnormally, there may be spurious nulls at the end of the
267 segment. These are present because of changes made in order to make
268 absentee processes cheaper. If they are present, just use the
269 adjust_bit_count abc command to remove them. The bit count will
270 always be set at or beyond the logical end of file, so no valid data
271 will ever be invisible.
272
273
274 New options in tracing statements:
275 The tracing statements, &command_line, &control_line, &comment_line and
276 &input_line accept the keyword "output_switch" or "osw". An optional
277 I/O switch name follows this keyword. If there is no switch name
278 specified, trace output of the selected type is reverted to the default
279 switch user_output; if a switch name is specified, trace output will
280 subsequently be done to that switch. The switch name may contain
281 embedded white characters, but leading or trailing white characters
282 will be removed. If stream output is not possible on the specified
283 switch, the io_error condition will be raised to allow the attachments
284 to be manually repaired before restarting the exec_com. Note that this
285 option may not be combined with turning tracing on or off, and has no
286 effect on whether tracing is actually done.