
                       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<string1><string2><string3><string4>
   
  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<string1><string2><string3><string4>
   
  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,
   
  	$<m1><m2><mp><ap>keystring
   
  where:
   
  	$	Key character identifying this as a keyword line
  	<m1>	Minimum number of characters to match in keyword
  	<m2>	Maximum number of characters to match in keyword
  		(If 0, no check for user KEYWORD > file KEYWORD is made).
  	<mp>	Minimum number of parameters required.  If this
  		number of parameters is not present then
  		parameters will be prompted for.
  	<ap>	Maximum number of parameters to prompt for if 
  		less than <mp> 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 <m2>
  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:
   
  	?<n>QUESTION-TEXT
   
  Where:
   
  	<n> 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:
   
  	?<n>QUESTION-TEXT
   
  Where:
   
  	<n> is the parameter number to prompt for; 1-9,A-C
   
  If the correct number of parameters are supplied, i.e.   have  more  than
  <mp>  (consult  HELP CCL KEYWORD) parameters, no questions are asked.  If
  fewer parameters have been  supplied  then  required,  parameter  <n>  is
  checked,  and,  if it is null (undefined), the question is asked with the
  user's response defining parameter <n>.


                                    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  <n>
  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 <pn> 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:
   
  	%<pn><option1><option2><option3>%
   
  where:
   
  	<pn>		is the parameter to be substituted
  	<option1>	is one of null, '=',' ', or ','
  	<option2>	is one of null, or <test-char>text-string
  	<option3>	is one of null or \text=string
   
  	Under CCL V8.0 parsing, <pn> may be 0-9, A-C
  	Under CCL V9.0 parsing, <pn> 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
  <test-char> 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 <pn> 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:
   
  	%<pn>?<string1><\string2>%
   
  where:
   
  	<pn>		is the parameter to test
  	?		Key character to indicate a test field
  	<string1>	is one of null or ASCII string
  	<\string2>	is one of null or ASCII string preceeded by 
  			backslash.
   
  Encountering the "%<pn>?" field in the action line causes CCL  to  deter-
  mine  if  parameter <pn> is null.  If <pn> 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 <pn> 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:        
   
  	%<spec-char>
   
  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.
