[NEWSGC.TXT]

     IMPLEMENTING GCL IN DECUS-C UNDER RSX


In the programming environment in this Office our
default human interface is a "GCL command line"
processor in each task. This article describes
task command line processing facilities available
under RSX and describes how functions for invoking
these were developed for use in a DECUS-C
programming environment. 


1.0	"GCL" COMMAND LINE PROCESSING UNDER RSX 

For those not familiar with the term "GCL", this
term refers to a set of subroutines which handle
the getting and passing to a task of a command
line. RSX provides these as part of the system
libraries. 

A request in a task for a GCL command line will,
among other things, display an appropriate prompt
on the terminal (if desired), accept a command
line on the user's terminal, or alternatively
process a command file containing a list of the
desired commands. The command file may itself
include indirection to a further command file up
to a predetermined degree of "nesting". 

If all this sound suspiciously familiar to users
of the Independent Command Processor, it is
because AT. itself gets its command lines using
the GCL functions. So do PIP, TKB, VFY, BRU, DMP,
etc... 

The difference between a normal command entered at
a terminal and a GCL command line is that the
former is first processed by MCR or DCL, and only
if an MCR command line invokes an installed task
which commences with a GCL module is the command
line also passed to the task. However a command
entered in response to a GCL prompt from a task is
passed directly to the task. 
 
For example:

	>pip @fred

will invoke pip, which in turn will process the
PIP command lines in fred.cmd. The following will
have the same end result: 

	>run $pip
	PIP> @fred

The difference is that in the first case the
command is intercepted by MCR, which invokes PIP.
The GCL modules in PIP then get the contents of
the MCR command line. In the second case the
running task itself prompts for and directly
accepts the command. 

The task itself must interpret the meaning of the
command line sent to it. 


2.0	IMPLEMENTATION OF COMMAND LINE PROCESSING 

RSX provides a number of modules in the system
library to enable processing of command lines.
These are described in detail in Chapter 6 of the
IO Reference Manual. In a simple implementation of
these suitable for calling from a high level
language, a GCL work area is established (which
defines the maximum characters per command line,
the number of levels of nesting permissable, and
the LUN on which the command is input), parameters
are set up and a system macro GCML1 invoked. 

A considerable amount of program development has
been carried out in this office in Basic Plus 2.
To implement GCL in this language a module
GCLGCL.MAC was written which was itself called by
a higher level "basic programmer interface" in
BP2. The LUN was hard wired to 16 which did not
cause any problems as all our IO was conducted on
LUNs 20 to 32 under a stripped down in-house IO
system using FCS which was developed to enable us
to throw out RMS. 


3.0	COMMAND LINE PROCESSING IN DECUS-C 

In our early days of development in DECUS-C we
attempted to set up a quick hack solution using
the same macro modules used from BP2 called from a
C function. This was found to bomb under certain
conditions and it was soon found necessary to do
the job properly. 

DECUS-C, in fopen(), dynamically allocates LUNS
from a LUN table, the size of this table being
normally set by IOV.MAC at 20. With the size and
complexity of many of our IO operations it is
almost certain that a hard wired LUN would result
in problems. 
 
One solution could have been to use one of the
standard channels opened by C (for example
'stdin'). However this would have resulted in
other potential problems. 

The solution adopted was to look closely at
fopen() and associated modules in the DECUS-C
libraries to find how the LUN table was used. This
information is then used to allocate a LUN from
the LUN table for GCL, on the first request for
GCL. 

In our present implementation this LUN cannot be
closed once open, and GCL will work on only the
one unit, i.e. it cannot be used on several LUNs
to get a input from several different devices.
This will be cured in the next incarnation. 

It was then found that when GCL was used in an
installed task, the GCL would not get the
initiating command line. 

The problem was that $$INIT (a C module) was itslf
doing a GCML (or somthing similar), and grabbing
the command input, so that it could parse the
first line, open stderr, stdin, stdout, and create
argc and argv. It was thus not possible to give a
command such as: 

	MCR>lsr @fred

as "@fred" was grabbed and placed in the normal
"C" argument list. 

It was realised that one could not have the best
of both worlds at the same time; either a standard
C command line interpretation or a GCL capability
was possible in the initial command line but not
both. As our goal was to enable the use of a GCL
command line with an installed task it was decided
to hard wire and open stdin, stdout, stderr on the
terminal device TI:. This was achieved by removing
the GCML code from $$INIT, and including $$INIT in
the GCL module. 

Normal "C" functionality can still be provided by
scanning the command line for redirection symbols
etc. at the time of the normal parsing by the
task. 

This can be set up to allow redirection of stdin
and stdout during the execution of the task, by
closing and re-opening the relevant channels. 


Bruce Cook (Wittenoom and Associates)