CCL -- Console Command Language Version V9.0 CCL V9.0 may either be used as a Catchall task for MCR, or it may be installed and used as an Alternate Command Line Interpreter (CLI). When CCL is activated, it retrieves the 1-79. character command line passed to it by MCR (when acting as the catchall), and attempts to match the command "KEYWORD" against an entry in a CCL command file (consult HELP CCL FILES). Once a match is found, CCL will execute the command which normally involves reformatting the original command line into an appro- priate MCR recognizable command line and than passing the new command back to MCR. Further HELP in using CCL may be obtained using the follow- ing keywords: INTRODUCTION Introduction to how CCL works V9.0 Outlines the enhancements for V9.0 CLI Describes the use of CCL as an Alternate CLI COMMANDS List of the standard internal command set FILES Lists the command files CCL supports PARAMETERS Describes component parameters CCL assigns to an input command line SPECIALPARAMETERS Describes the special parameters defined by CCL PARSING Desription of CCL's parsing COMMAND FILE General description of the CCL command file format DELIMITERS Format for command file parameter DELIMITERS lines KEYWORD Format for command file KEYWORD lines QUERY Format for command file input QUERY lines ACTION Format for command file ACTION lines 2 CLI CCL may be installed and used as an alternate CLI to MCR. In this mode, a terminal which sets its CLI to CCL (via SET /CLI=TI:CCL) will have all unsolicited commands that would have been queued to MCR given directly to CCL. As a CLI, CCL scans a slightly different set of command files (consult "HELP CCL FILES") looking for a match: 1) Internal table 2) SY:[ggg,mmm]USERCLI.CCL 3) LB1:[ggg,5]GRPCLI.CCL 4) LB1:[1,5]SYSCCL.CCL If the command cannot be recognized, CCL passes the command line unal- tered to its catchall, which is most often (but not necessarily) MCR. Further HELP may be obtained with "HELP CCL CLI INSTALL". 3 INSTALL If CCL is to be used as an alternate CLI, it must be installed using the MCR commands: INS $CCL/TASK=...CCL/PRI=70./CLI=YES CLI /INIT=CCL/CPR="<15><12>/CCL>/"/DPR="<15><12>/>/" CLI /ENABLE=CCL NOTE: the installer may want to change the CTRL-C and default prompt strings in the /CPR and /DPR switches to avoid confusion with MCR's ">" default prompt. Once installed, each user may be directed to CCL by ei- ther the system account file or by issueing the MCR command: SET /CLI=TI:CCL 2 COMMANDS As distributed, CCL supports command lookup from an internal table which provides the appropriate entries to handle various "PIP-style" commands (using DEC convention that [...] => optional field): COP[y] from to => PIP to/FO=from CRE[ate] filespec => PIP filespec=TI: DEL[ete] filespec => PIP filespec/DE/LD DIR[ectory] [filespec] => PIP [filespec]/LI FRE[e] [ddn:] => PIP [ddn:]/FR TYP[e] filespec => PIP TI:=filespec PUR[ge] filespec => PIP filespec/PU SOR[t] [filespec][/SW] => SRD [filespec][/SW]/LI SPO[ol] filespec => PIP filespec/SP TRU[ncate] filespec => PIP filespec/TR In addition, the user can issue short form commands to display certain status information. ? [topic] => HELP [topic] ATS [TTN:] => ACT [/TERM=TTN:] BELL => Ring terminal bell. DLG => DEV /LOG Show logged on terms. ERASE => Erases VT52 screen. HEY [taskname] => Notify user when 'TASKNAME' exits IDENT => Display CCL's version #. MCR command line => Directs "command line" to MCR... NOSCROLL => Sets VT100 to jump scroll. PAGE => Erases VT100 or TEK 4014 screen. SHQ => QUE /LI Show spool queue. SCROLL => Sets VT100 to smooth scroll. UIC => SET /UIC Show current UIC. UIC ggg,mmm => SET /UIC=[ggg,mmm] UIC ggg mmm => " " " LIBUIC [ggg,mmm] => as "UIC", SET /LIBUIC NETUIC [ggg,mmm] => " " , SET /NETUIC SYSUIC [ggg,mmm] => " " , SET /SYSUIC 2 FILES CCL scans a set of internal and FCS command files in the process of decoding command lines. As the catchall task, ...CA., CCL normally scans: 1) Internal table 2) SY:[ggg,mmm]USERCCL.CCL 3) LB1:[ggg,5]GRPCCL.CCL 4) LB1:[1,5]SYSCCL.CCL NOTE: the installer may change the order and names of these files, consult the appropriate person for your configuration. As an alternate CLI, CCL normally scans: 1) Internal table 2) SY:[ggg,mmm]USERCLI.CCL 3) LB1:[ggg,5]GRPCLI.CCL 4) LB1:[1,5]SYSCCL.CCL 2 INTRODUCTION The normal user interface to an RSX11M operating system is via MCR (Monitor Console Routine). If terminal input is not specifically re- quested by a task, all data, or commands typed in at a user's terminal are sent by the terminal driver to MCR for decoding. The MCR task (and its child ...SYS) decode user commands (ACT, ABORT, RUN, DEV, etc.). Tasks installed with special names of the form ...XYZ are treated as an external MCR command. Hence if a user types: XYZ commandline The 'commandline' in its entirety (maximum of 79 characters for RSX-11M) is sent as input to the task ...XYZ. This is the conventional way of supplying most system commands and controlling the operation of the RSX11M utility programs. The limitations of this method are that each task must be installed to be treated as an external MCR command, and each extra installed task uses valuable pool space. Moreover, because in- stalled tasks use a critical system resource (pool), only privileged users are allowed to install and remove tasks from the system. The nor- mal user is restricted to starting tasks via the RUN command or using those tasks already installed. To alleviate this problem, a user tailor- able Console Command Language (CCL) has been implemented which allows each user to have a private task control language. CCL may either be used as an alternate command line interpreter (CLI) in which case all user commands are passed to it first, and/or it may be used as a catchall task which receives command lines rejected by MCR either because they are illegal MCR commands or because the command is not recognized as an external MCR command (i.e. a task installed with the name ...XYZ). If CCL is not used as the terminal's CLI, and a user types in a command line, MCR is given first crack at decoding it. If MCR does not recognize the command (first three letters) as either an internal (like SET) or external command, the command line is sent to CCL which is installed as ...CA., the catchall task. CCL in turn checks to see if it recognizes the command. The steps CCL takes in attempting to decode the command are selected during the CCLGEN process (see TASK OPTIONS). If the first catchall task (...CA.) does not recognize the command, the command line is sent to ...CA.'s catchall task installed as ...CA1. Multiple catchall's are supported by CCL based on the catchall's installed task name, e.g. if installed as ...CA5, chain to catchall installed as ...CA6. Ultimately, the last catchall in the chain will issue the mes- sage: CCL -- Syntax error, unknown or ambiguous command If CCL is installed as a CLI and a user issues a SET /CLI=TI:CCL, then all commands are sent to CCL first. This means all commands are in- tercepted before they get to MCR. CCL knows if it is a CLI, and adjusts its behavior accordingly. Once CCL receives a command, it behaves exact- ly as it would if it were a catchall task. However, CLI, and adjusts its behavior accordingly. Once CCL receives a command as an alternate CLI, it behaves exactly as it would if it were a catchall task. 2 V9.0 CCL V9.0 addresses several limitations/restrictions in CCL V8.0. Most important is a new parameter parsing scheme which allows the user to redefine command line parameter delimiters. Command delimiters may be altered using a new CCL command file line, the PARAMETER DELIMITERS LINE (consult HELP CCL DELIMITERS). This facility is coupled with the rede- finition of the command parameter designators to make parsing of more complicated command syntaxes possible (consult HELP CCL PARSING). In im- plementing these changes, however, full V8.0 compatibility has been reta- ined, and CCL command files may switch back and forth between the en- hanced V9.0 parsing and the V8.0 compatible parsing. NOTE: Under V8.0 compatible parsing, a QUERY line prompt issued when a parameter is unde- fined assigns the entire user response to that parameter. Under V9.0 parsing, ALL RESPONSES TO PROMPTS ARE PARSED AS IF THEY WERE ENTERED ON THE ORIGINAL COMMAND LINE, i.e. a response may give more information than requested, and it will be appropriately parsed (consult HELP CCL QUERY and HELP CCL PARSING). A new CCL command file has been added: a group wide command file under LBn:[ggg,5]GRPCCL.CCL. Additionally, the order CCL will open command files is under complete control of the condi- tional assembly file PRECCLASM.MAC. CCL V9.0 no longer considers the "FILE NOT FOUND" FCS error to be fatal for any CCL command files. Of lesser significance, the catchall task for CCL when its installed as an alternate CLI maybe reconfigured (using TASK BUILDER options or the ZAP utility) to bypass MCR completely. Support for the "HEY" command has been added to the standard command file "WAIT FOR TASK" action line. Also, the task name specified in a "WAIT FOR TASK" line defaults to "TTn", and may optionally attempt to connect to "XYZTn" before trying to connect to task "...XYZ". The DCL "DLY" command cannot be implemented from a standard CCL command file, requiring the inclusion of the DCL.MAC module if the delay command must be supported. 2 PARSING The basic purpose of CCL is to implement a command language that is convenient to use and/or tailored to a specific environment. CCL accom- plishes this by assigning subsections of a command line to a set of named PARAMETERS which can then be rearranged into a command line that is ac- ceptable to MCR. Version 9.0 of CCL implements a more versatile command line parser than previous releases. Users may randomly switch from V8.0 compatible parsing to V9.0 parsing as well as change the special char- acters which are recognized as parameter delimiters using the "PARAMETER DELIMITER LINE" command line (consult HELP CCL DELIMITERS). The follow- ing discussion outlines both the V8.0 parameter parsing and the V9.0 parsing. First, consider the command line: COPY/SW [2,3]FILE1,FILE2 *.* and the desired MCR command line it represents: PIP *.*=[2,3]FILE1,FILE2/SW In both schemes, CCL divides this command into parameters by first identifying a KEYWORD FIELD and a COMMAND FIELD based on a set of default or user specified delimiters. For the purpose of this discussion, only the default parameter delimiters will be considered; consult the section on PARAMETER DELIMITER LINES for details on altering delimiters. The keyword field includes everything up to the first space (or end of the command line), and in turn consists of a KEYWORD and any optional KEYWORD QUALIFIER. The keyword includes everything up to the first space OR "/", while the keyword qualifier includes everything in the keyword field starting at the first "/". In the above example the keyword field is "COPY/SW", with keyword "COPY" and keyword qualifier "/SW", while the command field is "[2,3]FILE1,FILE2 *.*". With the keyword defined, CCL will attempt to find an identical keyword entry in one of its command files/tables. Once the keyword is identified as a legitimate command, the remainder of the command line is parsed according to the current rules in effect (e.g. V8.0 compatible or V9.0). Two additional parame- ters have been defined by identifying the keyword: parameter A (refer- enced as %A% in an "ACTION LINE") includes everything that is NOT in the keyword, and parameter 0 (referenced as %0%) is defined as any keyword qualifier. NOTE This definition of parameter A is slightly different than CCL V8.0. In V8.0, if there was no keyword qualifier, parameter A would not include the space separating the keyword from command field. CCL V9.0 now defines parameter A to be literally every- thing NOT in the keyword. In the above example then: %A% => /SW [2,3]FILE1,FILE2 *.* %0% => /SW One should note that %A% is the COMMAND FIELD which is very useful in passing command lines essentially unaltered to non-installed system util- ities. Parsing the command field into its component parameters depends on whether V8.0 or V9.0 parsing is in effect. The installer selects ei- ther V8.0 or V9.0 parsing as the default, while the user may switch between parsing styles from within a CCL command file/table. The parame- ter definitions for the above example under V8 and V9 parsing are out- lined below. V8.0 PARAMETER DEFINITIONS: Under V8.0 compatible parsing, the command field is subdivided into nine parameters referenced as %1%-%9%, and two major command sections referenced as %B% and %C%. The default delimiters for the nine parame- ters are, "," "=" " " "_" "<". The default delimiter for the major com- mand sections is a space. CCL scans the command field for these delim- iters, and assigns character strings to each parameter as the delimiters are encountered. NOTE Two special sets of characters suspend normal parsing. Strings enclosed by square brackets ([...]) or double quotes ("...") are treated as literals; e.g. the comma in a UFD field is NOT tre- ated as a parameter delimiter. Using the default delimiters, CCL will assign the parameters: %1% => [2,3]FILE1 %2% => FILE2 %3% => *.* Since there are only two major command sections, the first space separ- ates %B% from %C% defining: %B% => [2,3]FILE1,FILE2 %C% => *.* CCL also keeps track of how many parameters have been defined so it can prompt for any required but undefined information. Under V8.0 rules, 3 parameters have been defined; %1%-%3%. .S2 V9.0 PARAMETER DEFINITIONS: Several shortcomings of the V8.0 parameter definitions have been ad- dressed by CCL V9.0. The standard nine parameters are still defined (%1%-%9%), but now each parameter is allowed to have up to 26 subparame- ters referenced as %Na%-%Nz% (N=1-9). The default delimiter for the nine parameters is the space. The default delimiters for the 26 subparameters is the comma. For compatibility, parameters %B% and %C% are still de- fined under V9.0 as they were under V8.0, but their use should be res- tricted. Using the default delimiters, CCL V9.0 will assign: %1% => [2,3]FILE1,FILE2 %1a% => [2,3]FILE1 %1b% => FILE2 %2% => *.* %B% => [2,3]FILE1,FILE2 %C% => *.* As with V8.0, CCL keeps track of the number of parameters defined, and, in this example, only 2 parameters have been defined; %1%-%2%. Some subtle differences between V8.0 and V9.0 parsing should now be apparent. Under these new parameter definitions, the parameters 1-9 actually repre- sent an extension of V8.0's parameters B and C. Unlike V8.0, however, only the major sections of the command field (V9.0's parameters 1-9) rather than all command sections (V8.0's parameters 1-9) are counted when determining if more information must be prompted for. NOTE The next discussion will become clearer if the reader is familiar with, or consults the documentation on CCL command file formats. V8.0 versus V9.0 : In the example given, a problem becomes apparent when trying to re- arrange the command parameters to formulate a new command for a standard RSX utility, e.g. PIP. The first string of file names may define a var- iable number of parameters and need to be formed into a string of input files while the last parameter defined, which could be any of %2%-%9% under V8.0 definitions, may specify the output file. Using only V8.0's parameters %1%-%9% would make it difficult to regenerate a valid PIP com- mand of the form "PIP outfile=infile(s)" since it is not easy to refer- ence the last parameter defined when attempting to rebuild the PIP com- mand string. Parameters %B% and %C% were defined in V8.0 to handle just this case. However, other command fields were not easily handled using parameters %0%-%9% and %A%-%C%, and required more control over parameter definitions, hence V9. An important feature of CCL is its ability to prompt for undefined parameters (consult HELP CCL QUERY). In setting up the CCL command lines that will regenerate the desired PIP equivalent for the example CCL "COPY" command, one would probably like to prompt the user for a "From ?" set of file specifications and a "To ?" file specifi- cation. It is an easy matter to tell CCL that it needs a minimum of 2 parameters, and define the "From ?" and "To ?" prompts. Under V8.0, the example command would not prompt, since it defined 3 parameters. The same holds for V9.0's handling of the example, since 2 parameters were defined. If, however, the orignal command was, COPY [2,3]FILE1,FILE2 V8.0 would find 2 parameters and go merrily on its way, while V9.0 pars- ing would only find 1 parameter and (correctly) prompt for a "To ?" file specification. Another major difference in V8.0 and V9.0 is in the han- dling of the user's response to a CCL prompt. Under V8.0, the prompt is issued when a parameter is undefined, and the entire user response is as- signed to that parameter. Under V9.0, ALL RESPONSES TO PROMPTS ARE PARSED AS IF THEY WERE ENTERED ON THE ORIGINAL COMMAND LINE. 2 COMMANDFILE CCL COMMAND FILES consist of sets of special lines controlling CCL's handling of command lines. Five different line types are distinquished by their first character: 1) PARAMETER DELIMITER LINES begin with "~" or "^" Controls parsing command lines into component parameters 2) KEYWORD LINES begin with "$" Defines the key string for recognizing a command 3) INPUT QUERY LINES begin with "?" Prompts the user for undefined but required information 4) ACTION LINES begin with "*", "+", or "-" Controls re-building an MCR command line from the original command lines component parameters 5) COMMENT LINES begin with any other character For further information on these line types, consult; HELP CCL DELIM- ITERS, HELP CCL KEYWORDS, HELP CCL QUERY, or HELP CCL ACTION. 2 DELIMITER CCL's parameter DELIMITER command line alters parsing of command lines into its component parameters. The parameter delimiter lines begin with "~" or "^" and are formatted as: xx where: xx Controls parsing style and temporary/permanent status of the change: ~ => Temporarily use V8 parsing ~~ => Permanently change to V8 parsing ^ => Temporarily use V9 parsing ^^ => Permanently change to V9 parsing < > Paired characters encompassing delimiter strings. string1 String of valid ASCII characters separating KEYWORD FIELD from COMMAND FIELD. string2 String of valid ASCII characters separating the KEYWORD from any KEYWORD QUALIFIER. string3 String of valid ASCII characters separating MAJOR PARAMETERS within COMMAND FIELD. string4 String of valid ASCII characters separating SUB-PARAMETERS within a MAJOR PARAMETER. For more HELP, type HELP CCL DELIMITERS FULL. 3 FULL CCL's parameter DELIMITER command line alters parsing of command lines into its component parameters. It selects both the parsing style, i.e. V8.0 compatible or V9.0, and the parameter delimiters that separate the command into parameters. The change in delimiters may be temporary or permanent. A temporary change remains in effect until a keyword line is encountered that DOES NOT match the command keyword. A permanent change remains in effect until another change delimiters line is encoun- tered or the CCL command file/table is closed (i.e. no keyword match). Once a keyword line is found that matches the command keyword, the param- eter delimiters are unalterable and any further parameter delimiter lines encountered are considered as comments. The parameter delimiter lines begin with "~" or "^" and are formatted as: xx where: xx Controls parsing style and temporary/permanent status of the change: ~ => Temporarily use V8 parsing ~~ => Permanently change to V8 parsing ^ => Temporarily use V9 parsing ^^ => Permanently change to V9 parsing < > Paired characters encompassing delimiter strings. string1 String of valid ASCII characters separating KEYWORD FIELD from COMMAND FIELD. string2 String of valid ASCII characters separating the KEYWORD from any KEYWORD QUALIFIER. string3 String of valid ASCII characters separating MAJOR PARAMETERS within COMMAND FIELD. string4 String of valid ASCII characters separating SUB-PARAMETERS within a MAJOR PARAMETER. default definition (equivalent CCL command line) ~~< >< ><,=< > Under CCL V8.0 parameter parsing ^^< >< ><, > Under CCL V9.0 parameter parsing There is a special restriction in definition of "string2" and "string4" under both V8.0 and V9.0 parsing; ALL CHARACTERS IN "string1" MUST AP- PEAR IN "string2" AND ALL CHARACTERS IN "string3" MUST APPEAR IN "string4". Also, the "><" pair is used as the critical combination sep- arating the 4 fields, so ">" and "<" may appear as literals in any of the 4 fields provided they do not appear as "><", e.g. <<>> would set "<>" as a delimiter string while <><> would define two null delimiter strings. When CCL V8.0 parameter parsing is enabled, command components are as- signed to parameters %0%-%9% and %A%-%C%. Using the default delimiter strings, the command KEYWORD is delimited by the first "/" or " ". The entire KEYWORD FIELD, and thus %0% (the KEYWORD QUALIFIER) is delimited by the first " ". Therefore, if the KEYWORD terminates in a " ", there is no parameter 0. The KEYWORD delimiter is included in parameter %0%, e.g. BRU/REW sets %0% to "/REW". The special parameter %A% is defined as everything not in the KEYWORD, and would include everything from the first "/" or " " to the end of the command line (also includes the "/" or " "). Parsing the COMMAND FIELD under V8.0 rules can be thought of in a two-pass fashion (it is actually a one-pass process which is why all major parameter delimiters must also appear in the sub-parameter delim- iters list). First, scan the command line for the first " " delimiting the major parameters %B% and %C%. Everything up to the first space de- fines %B%, while everything after the first space defines %C%. Finally, assign %1%-%9% in order every time a "," "=" "<" "_" or " " is encoun- tered in the command field. When V9.0 parameter parsing is enabled, the KEYWORD and parameter 0 parsing is identical with CCL V8.0 (see preceed- ing discussion). The COMMAND FIELD parsing is quite different. Major command components are assigned to the parameters %1%-%9%, and each of these parameters may have sub-sections assigned to the parameters %Na%-%Nz% (N=1,9). Again, viewing the parsing as a two-pass process, the %1%-%9% are assigned in order every time a " " is encountered in the com- mand field. Then, each parameter is scanned for the sub-parameter delim- iters "," and " ", and assigned in order to the sub-parameters, i.e. %Na%-%Nz%. NOTE Special "paired" characters suspend the command parsing and are defined in PARSE.MAC (see list @ PAIRS: label). The current list treats all characters enclosed by [] and "" as literals, e.g. the comma in [200,200] is treated literally, not as a par- ameter delimiter. 2 KEYWORD CCL's KEYWORD command line is the first line of a command set. There may be multiple keyword lines leading to the same ACTION line. The keyword line format is, $keystring where: $ Key character identifying this as a keyword line Minimum number of characters to match in keyword Maximum number of characters to match in keyword (If 0, no check for user KEYWORD > file KEYWORD is made). Minimum number of parameters required. If this number of parameters is not present then parameters will be prompted for. Maximum number of parameters to prompt for if less than parameters are given. keystring is the ASCII string that must be matched against the command's keyword The command keyword identified according to the current parsing syntax will be checked against each keyword line's "keystring". If the parameter is 0, no checking for maximum keyword length will be performed. 2 QUERY CCL's input QUERY line provides a means to prompt the user for un- supplied information and is formatted as: ?QUESTION-TEXT Where: is the parameter number to prompt for; 1-9,A-C For more HELP, type HELP CCL QUERY FULL. 3 FULL CCL's input QUERY line provides a means to prompt the user for un- supplied information and is formatted as: ?QUESTION-TEXT Where: is the parameter number to prompt for; 1-9,A-C If the correct number of parameters are supplied, i.e. have more than (consult HELP CCL KEYWORD) parameters, no questions are asked. If fewer parameters have been supplied then required, parameter is checked, and, if it is null (undefined), the question is asked with the user's response defining parameter . NOTE Prompting for parameter 0 is no longer supported since, by defin- ition, it is a subsection of the command KEYWORD FIELD. Under V8.0 parsing, the entire response line will be assinged to the parameter, and no special attention as to the order the parameters are prompted for is required. However, under V9.0 parsing, all responses are reparsed to identify all parameters entered. This means that parameter prompts MUST appear in order (e.g. prompt for 2 follows prompt for 1) since a response to one prompt may define more parameters than the one requested. Also, user's should avoid the use of parameter A-C in prompt lines under V9.0 parsing. While this is legal, they are internally con- verted to defining parameter 1 (for A and B) or parameter 2 (for C). 2 ACTION CCL's ACTION command line is specified as follows: < >...command-line<+> where: < > is one of '-', '+', or '*'. <+> is null or '+' Action lines beginning in "-" instruct CCL to wait for a given task. Action lines beginning with "+" or "*" instruct CCL to spawn a command line to MCR; "+" action lines instruct CCL to wait for the ultimate offspring task to exit, "*" action lines instruct CCL to exit immediately after the command line is queued to MCR. If the last character in the action line is a "+", the action line is continued on the next line of the command file. For more HELP, type HELP ACTION FULL. 3 FULL CCL's ACTION command line is specified as follows: < >...command-line<+> where: < > is one of '-', '+', or '*'. <+> is null or '+' Action lines beginning in "-" instruct CCL to wait for a given task. Action lines beginning with "+" or "*" instruct CCL to spawn a command line to MCR. When CCL is installed as an alternate CLI, an attempt to execute a "-" action line results in the error: CCL -- CLI's cannot support "WAIT FOR" action lines CCL V9.0 handles WAIT FOR TASK lines differently than previous releases. All parameter substitution fields, etc. are decoded as described below, with the resulting command line being used as the task name to issue a connect request for, and wait for the task to exit. If the task name is null, the user's terminal unit number is used to generate a task name, e.g. for a user on TT5: the CCL command line "-" attempts to connect to "TT5". If the task name is exactly 3 characters long, CCL first appends the standard terminal qualifier and issues the connect request, e.g. issueing "-PIP" from TT5: will attempt to connect to "PIPT5". If this connect fails, CCL will retry using the prototype task name "...XXX", e.g. "...PIP". Task names 1-2 or 4-6 characters in length are taken li- terally. Finally, 2 special parameters defined below, "%P" and "%$" take on a special significance in wait for task action lines. The %P parame- ter will display the task's exit status, and the %$ parameter will force CCL to exit after the task emits status. In combination, the %P%$ param- eters allow CCL to implement the DCL's "HEY" command with terminal quali- fied task names, e.g. "-PIP%P%$" will notify the user of their PIP's exit status. The "*" and "+" command lines differ only in that the "+" line signals that further action lines follow in the file. A "*" signals that the command is the last or only command line. The text in the ac- tion line forms a command template which will be used in constructing the command line that will ultimately be passed to MCR. Action lines consist of valid MCR commands which must not involve further calls to CCL. Any action line that is too long to be placed on a single line may be contin- ued to the next line by placing a '+' as the last character in the action line. Note: the '+' must not be in the middle of a parameter substitu- tion string (see discussion below). Though this facility is provided, it is far more likely to exceed the ultimate MCR command line length of 79 characters before running out of action line space. Three special fields in the action line suspend direct transfer of characters from the action line to the new command line: 1) Parameter substitution fields 2) Parameter test and substitute fields 3) Special parameter substitution fields The "%" character denotes a substitution field, and is normally associat- ed with a parameter number or special symbol. The 1st and 2nd sub- stitution fields are also required to terminate with the "%" character. For additional HELP, consult "HELP CCL PARAMETER SUBSTITUTION", "HELP CCL PARAMETER TEST", and "HELP CCL PARAMETER SPECIAL". 2 PARAMETERS CCL assigns command components to named PARAMETERS which may be used as objects for PARAMETER SUBSTITUTION or TEST fields in CCL command file action lines. The parameters provide the means to rearrange the original command line to a form more acceptealbe to MCR or the ultimate RSX-11M utility. By convention, parameters are usually referred to enclosed by "%'s". CCL V9.0 supports 2 sets of parameter definitions according to the current parsing rule in effect, i.e. V9.0 or V8.0. Under V8.0, com- mand components (using default delimiters) are assigned to the parameters: %0% => Leading switches, beginning with "/", ending on 1st space %A% => Entire command line, less the keyword %B% => Extends from 1st space to 2nd space (non-inclusive) %C% => Extends from 2nd space to end of command line %n% => n=1,9; %1% extends from 1st space, comma, underscore, "<", equal-sign to 2nd such delimiter (non-inclusive), %2% extends from 2nd delimiter to 3rd, etc. Under V9.0, command components (using default delimiters) are assigned to the parameters: %0% => Leading switches, beginning with "/", ending on 1st space %A% => Entire command line, less the keyword %n% => n=1,9; %1% extends from 1st space to 2nd space (non- inclusive), %2% extends from 2nd to 3rd space, etc. %n?% => ?=a,z (Sub-parameters of %1%-%9%); %1a% extends from start of %1% to 1st comma or end of %1%, %1b% extends from 1st to 2nd comma or end of %1%, etc. %B% => Extends from 1st space to 2nd space (non-inclusive) (definition retained for V8.0 compatibility => %1%) %C% => Extends from 2nd space to end of command line (definition retained for V8.0 compatibility => %2%-%9%) For additional information on using these parameters to rebuild command lines, consult HELP CCL PARAMETER SUBSTITUTION, HELP CCL PARAMETER TEST. CCL also defines various special parameters which are useful in rebuild- ing command lines; consult HELP CCL SPECIAL PARAMETERS. 3 SUBSTITUTION CCL's parameter substitution fields allow insertion of the command parameters into the new command line by using the format: %% where: is the parameter to be substituted is one of null, '=',' ', or ',' is one of null, or text-string is one of null or \text=string Under CCL V8.0 parsing, may be 0-9, A-C Under CCL V9.0 parsing, may be 0-9, Na-Nz (N=1-9), A-C (use of B and C is discouraged, retained for compatibility with V8.0) The first optional element denotes a character to be inserted before the parameter provided the parameter is not null. Only ',' , ' ', or '=' are recognized as preceeding characters. The second option denotes elements that are to be appended to the parameter if the first or test character did not appear in the parameter. Typically, the test characters are those which denote file extensions or version numbers. If the is not found in the body of the parameter, that character and the text string following it (up to '%' or '\') are appended to the par- ameter. The final option denotes a text string to be inserted directly into the command line if parameter is null (the '\' character is not included). 3 TEST CCL's parameter test and substitute field allows the user to control insertion of text strings into the new command line based on the status of a parameter (null or not null). It has the form: %?<\string2>% where: is the parameter to test ? Key character to indicate a test field is one of null or ASCII string <\string2> is one of null or ASCII string preceeded by backslash. Encountering the "%?" field in the action line causes CCL to deter- mine if parameter is null. If is null, the ASCII string pre- ceeded by "\" and ending with "%" will be inserted directly into the new command line (exclusive of the "" or "%" delimiters). If is not null, any string immediately following the "?" up to a "\" or "%" will be inserted into the new command line. If the specified parameter is unde- fined, the default substitution string is NULL (i.e. "\%") and the %Q (quit) special parameter has been encountered, CCL will exit without sending a command to MCR. This provides a convenient means to trap non- sense command lines before they are sent to MCR. 2 SPECIALPARAMETERS CCL'S defines special strings useful in rebuilding command lines or controlling CCL's activity, and are specified by a "%" followed by a sin- gle character: % The special parameters are, %$ As the last element in the command line, it signifies that CCL should SPAWN the command to MCR and exit (ESCAPE) rather than to stop itsef and wait for exit status. This must be the last element in the action line. %% Enables the second % to be accepted as a literal. %D The DEBUG switch. When encountered, the expanded command line is printed (up to the %D) at the issuing terminal rather than being sent to MCR. %G The group number of the UIC. %M The member number of the UIC. %P The PRINT switch. The action line will be printed on TI: rather than being sent to MCR (essentially %D without diagnostic message). %Q Exit without sending a command to MCR if a required parameter was defaulted to a NULL string. %R Ring the terminal bell when CCL exits (this is not supported when CCL is acting as an alternate CLI). %T The user's terminal ID (Tnn or Vnn where 'nn' is the terminal number and 'Tnn' or 'Vnn' are for real terminals and virtual terminals respectively. %U The user's UIC including '[,]'. Examples: %U -> [012,010] %G -> 012 %M -> 010 %T -> T14 if TT14:, V1 if VT01: useful for creating multi-terminal tasks (ie BAST2) using INS/TASK=nnn%T.