5.1 VICAR Libraries 5.2 Processing Modes 5.2.1 Interactive or Synchronous Processing Mode 220.127.116.11 VICAR DCL Mode - VMS Systems 18.104.22.168 VICAR USH Mode - UNIX Systems 5.2.2 Asynchronous Processing 22.214.171.124 Asynchronous Processing - VMS Systems 126.96.36.199 "Background" Processing - UNIX Systems 5.2.3 Batch Processing Mode 188.8.131.52 Batch Processing - VMS Systems 184.108.40.206 Batch Processing - UNIX Systems 5.3 VICAR Use of Subprocesses 5.4 Session Customizing Procedures 5.4.1 Logon Procedures 5.4.2 Logoff Procedures 5.5 Aborting a VICAR CommandWithin the following section, different aspects of the VICAR environment will be covered. The user will be introduced to the VICAR Library, processing modes, and subprocesses. The user will learn how to customize a VICAR session and abort a VICAR command. The novice user should note that several concepts presented in this section are explained in more detail later on in this document.
5.1 VICAR Libraries
Seven libraries contain the executive, applications and system
routines within VICAR. Each library is known by its system-wide
logical name or environment variable (pointing to a system
LIBRARY CONTENTS VMS UNIX V2$LIB $V2LIB VICAR executive routines VIDS$LIB $VIDSLIB VICAR system routines TAE$UTIL $TAEBIN/TAEPLAT Various system utilities R1LIB $R1LIB Application procs R2LIB $R2LIB Application procs R3LIB $R3LIB Application procs M2LIB $TAEMENU Menus
Three libraries are available for application procs so that a facility may segregate its procs as it chooses.
VICAR establishes a default search hierarchy containing these seven
libraries, as well as the user's current default directory. A change
of the current default directory after entry into VICAR is not
reflected in the search hierarchy. The user may bypass all such
searches by explicitly prefixing the proc name with the library name
and a colon (e.g.,
The user may display the currently established search hierarchy at any
time with the command
show (Appendix 10.4). The default hierarchy is
listed below with the search being from top to bottom.
Example: Show user's library hierarchy.
VMS: Note the location of the user's current default
directory is UD:[USERID].
VICAR>SHOW User Library ($USERLIB): UD:[USERID] Application Libraries ($APLIB): liblst:-cpd liblst:-pdf r3lib:-cpd r3lib:-pdf System Library ($SYSLIB): TAEPDF UNIX: VICAR>show User Library ($USERLIB): . Application Libraries ($APLIB): $V2LIB $VIDSLIB $R1LIB $R2LIB $TAEBIN/$TAEPLAT $R3LIB System Library ($SYSLIB): $TAEPDFOn VMS systems,
liblstis a logical name which points to all the VICAR libraries.
Example: Show user's library hierarchy. VICAR>DCL SHOW LOGICAL LIBLST "LIBLST" = "V2$LIB" (LNM$PROCESS_TABLE) = "VIDS$LIB" = "R1LIB" = "R2LIB" = "$TAEUTIL"
Within each library, compiled PDFs (file type
are given preference over slower, uncompiled PDFs (file type
.cpd and a
This default hierarchy is easily altered either with the use of the
setlib (Appendix 10.4), or within the user's ULOGON
procedure (Section 5.4.1).
starlib: in front of the current
library list and display.
VICAR>setlib (starlib:,*) VICAR>show User Library ($USERLIB): . Application Libraries ($APLIB): starlib: $V2LIB $VIDSLIB $R1LIB $R2LIB $TAEBIN/$TAEPLAT $R3LIB System Library ($SYSLIB): TAEPDFExample: Delete
starlib:from the current library list and display.
VICAR>setlib-delete starlib: VICAR>show User Library ($USERLIB): . Application Libraries ($APLIB): $V2LIB $VIDSLIB $R1LIB $R2LIB $TAEBIN/$TAEPLAT $R3LIB System Library ($SYSLIB): TAEPDF
When a user communicates directly with VICAR by means of a terminal, and VICAR immediately acknowledges and executes the user's requests, the user is in the "interactive processing mode". Within the interactive session the user might use:
220.127.116.11 VICAR DCL Mode - VMS Systems
On VMS systems, the user has the ability to execute DCL commands
without leaving the VICAR environment. The user can execute a single
DCL command, or actually enter the DCL mode while still within
In the first case, the user is able to execute a one line DCL command
DCL and the command.
Example: Execute a DCL command from VICAR.
VICAR>DCL SHOW DEV MTA0If the user wanted to do something in DCL that requires more than a single command line, a second method is available. If, for example, the user wanted to send a mail message or edit a file,
DCLwould be typed at the VICAR prompt. The user would then receive a new prompt,
_$, indicating that the DCL mode of VICAR had been entered.
Syntax: Enter VICAR's DCL mode.
Within this mode the user is able to do almost everything that could
be done in the normal DCL mode. Some DCL programs may not work in
VICAR's DCL mode.
The normal VICAR mode can be re-entered by typing
Within this mode the user is able to do almost everything that could be done in the normal DCL mode. Some DCL programs may not work in VICAR's DCL mode.
The normal VICAR mode can be re-entered by typing
_$ EXIT VICAR>
18.104.22.168 VICAR USH Mode - UNIX Systems
Similarly, on UNIX systems, the user has the ability to execute UNIX
shell commands without leaving the VICAR environment by typing
ush at the command line. (USH stands for User SHell.)
ush should be used much less frequently than
dcl is, because in a windowing environment it makes more
sense to open another window than to suspend VICAR in order to execute
shell commands. The
ush command should be used primarily
in procs rather than interactively.
Example: Execute a USH command from VICAR.
VICAR>ush dfSyntax: Enter VICAR's USH mode.
The 'shell' that is invoked is the command interpreter 'sh' or 'csh'
as defined by the symbol
SHELL when you logged in. You
may redefine the value of
SHELL from 'sh' to 'csh' or
vice versa before invoking TAE.
The normal VICAR mode can be re-entered by typing
exit at the shell prompt.
Syntax: Return to VICAR from USH mode.
% exit VICAR>
BEWARE Changing the default device/directory via
the shell command
cd while in USH mode or terminating a
USH command with a backslash (
\) will cause TAE to
5.2.2 Asynchronous Processing
EXPERT The Asynchronous processing mode allows a user
to execute a proc in a separate subprocess without interfering with
the user's current interactive session. This mode may sometimes be
preferable to the Batch mode because the separate subprocess runs
simultaneously with, and at the same priority as, the interactive
session. The user's interactive environment is duplicated in the
asynchronous subprocess, thus relieving the user from having to
redefine commands and globals. More than one asynchronous job may run
at the same time. Once submitted, the job is executed
EXPERT Because asynchronous jobs are executing in a separate subprocess, they cannot directly communicate with the user's terminal. However, they may communicate indirectly by requesting additional parameter inputs. See the TAE Command Language User's Manual and Section 7.2.5 for further information on these "dynamic parameters".
22.214.171.124 Asynchronous Processing - VMS Systems
EXPERT For asynchronous jobs run on a VMS system, the
VICAR runstream information is written into a log file named
TESTGEN.PDF as an asynchronous
VICAR>TESTGEN|RUNTYPE=ASYNC| [TAE-ASYNCJOB]Asynchronous job 'TESTGEN' initiated.
The user may check on the status of the job with the intrinsic command
Example: Monitor the progress of
VICAR>SHOW-ASYNC NAME PROC STATE SFI SKEY TESTGEN TESTGEN ACTIVE 0 TESTGEN
BEWAREThe user should not exit a VICAR interactive session while asynchronous jobs are executing. If this happens, all asynchronous jobs will be aborted.
BEWARE The user is also advised to avoid using tape operations within the Asynchronous mode until a known bug can be corrected. Tape drives can be successfully allocated, mounted, written or read. However, the tapes cannot be successfully dismounted and/or remounted within the Asynchronous mode.
126.96.36.199 "Background" Processing - UNIX Systems
VICAR running on UNIX systems does not have an "asynchronous mode";
given that a user can have several windows open at the same time, it
is usually unnecessary. However, processing jobs in the "background"
is similar in concept.
To do this, your proc will need to be submitted from the shell prompt.
Example: Submitting a VICAR proc from the shell prompt. (Note: this only works on SunOS, not Sun Solaris systems.)
% cat test.pdf Procedure !test Body slogon gen out.img 10 10 label-list out.img ush ps End-proc % taetm test > test.log &  9147The
slogonstatement in the proc after the
Bodycommand is necessary if the proc is going to be run from the UNIX shell prompt. However, it may not be present when running the proc from the VICAR command line. The > sign redirects the output from the proc to the file
test.log, rather than to your screen. (There is currently a bug in VICAR, such that the output is not written to the output file in the correct order. This should be fixed in future versions.) The ampersand (&) forces the job into the background. Typing
fgat the prompt will bring the job back into the foreground.
5.2.3 Batch Processing Mode
The user may wish to execute a proc in batch. Batch processing is
achieved by means of submitting a file, commonly referred to as a job,
to a batch queue which will create the proper environment to execute a
proc. Upon submitting the file, the user relinquishes control of the
job to the operating system, thus freeing the terminal and allowing
the user to continue with other tasks. The user may check on the
status of the job with the intrinsic command
BEWARE The default directory for a batch job is the directory from which the submittal occurred. If submitted from a subdirectory, all file names should be fully qualified because this subdirectory may not exist on all disks referred to in the job.
188.8.131.52 Batch Processing - VMS Systems
EXPERT There are several ways to invoke batch
processing in VICAR on VMS systems. This section will address the
VAX/VMS default batch queue,
SYS$BATCH. If this queue is
not on the user's system, consult the local system manager for
information on what is available.
EXPERT One way to create a batch process is to use
the intrinsic command
BATCH-SUBMIT (Appendix 10.4). After Tutoring on a
desired proc and performing a Tutor
SAVE (Appendix 10.8) on the parameter values
selected, the user can submit a job with the
command. This can be done in a Tutor session on
BATCH-SUBMIT or interactively.
VICAR>BATCH-SUBMIT PROC=proc_name + VICAR>+ SAVEFILE=savefile_name QUEUE=queue_name + VICAR>+ STDOUT=output_fileExample: After specifying parameters in Tutor on proc
GEN, submit to batch queue.
VICAR> BATCH-SUBMIT PROC=GEN.PDF SAVE=GEN.PAR Job 2038 submitted to queue SYS$BATCHlater:
Job GEN (queue SYS$BATCH, entry 2038) completed
EXPERT Another method for submittim a job is to use
the command qualifier
RUNTYPE (Section 184.108.40.206). Specifying a valid
NORUN will produce two different
submitting techniques. Specifying
SYS$BATCH as the
queue_name causes the job to be automatically placed in
that queue and executed.
Example: Submit proc
TESTGEN to batch queue
VICAR>TESTGEN |RUNTYPE=(BATCH, SYS$BATCH)| Job 2039 submitted to queue SYS$BATCH VICAR>SHOW-BATCH SYS$BATCH Batch queue MIPL1_SYS$BATCH, on MIPL1:: Jobname Username Entry Status TESTGEN USERID 2039 Executinglater:
Job TESTGEN (queue SYS$BATCH, entry 2039) completedEXPERT Specifying
NORUNas the queue name disables the act of job submittal. Instead, a job file is created containing all commands needed to execute the proc in batch. This method allows the user to issue the
DCL SUBMITcommand with any or all of its associated qualifiers, rather than accepting the VICAR defaults.
Example: Create the job file for
before submitting it.
VICAR> TESTGEN|RUNTYPE=(BATCH,NORUN)| Created batch job file 'TESTGEN.JOB'.EXPERT The
TESTGEN.JOBfor this example) would then be submitted using the
DCL SUBMITcommand, unless other provisions have been made by the system manager.
VICAR>DCL SUBMIT/NOPRINT/NOTIFY TESTGEN.JOB Job TESTGEN (queue SYS$BATCH, entry 2041) started on SYS$BATCHlater:
Job TESTGEN (queue SYS$BATCH, entry 2041) completedEXPERT Upon completion of a batch job, the user can access a file containing all of the processing information collected during the batch job execution. The log file is located in the directory from which the job was submitted, and it is called PROCNAME.LOG (
TESTGEN.LOGfor the above example).
EXPERT The user may also delete a batch job at any time.
VICAR>BATCH-DELETE QUEUE=queue_name JOBID=xxx
atcommand. (The UNIX
croncommand could also be used.)
Example: Use of the
at command on a SunOS
system. (Batch processing doesn't work on Solaris systems currently,
but when it does, be aware that the
at command has a
slightly different syntax on those systems.)
% cat submit_test.sh #!/bin/sh taetm test % at 23:00 submit_test.sh job 11719 at Tue Aug 9 23:00:00 1994(Remember to turn the execution permission for your shell script on using the UNIX command
chmod u+x submit_test.sh). You will receive a mail message containing the output from your job when it is completed. As stated above in Section 220.127.116.11, there is currently a bug in the output files from these batch jobs.
5.3 VICAR Use of Subprocesses
This section is relevant for VMS systems only.
WIZARD The VICAR executive makes use of VMS subprocesses to establish environments and isolate functions. This discussion is intended to clarify how a user's session is being supported under the VMS operating system.
WIZARD A user logged in under VMS has a process
associated with the session, e.g., process name
Entering the command VICAR starts a VMS subprocess with a process name
PRCNM1. This subprocess is the environment under which
all VICAR operations are handled. The VICAR
returns the user to the parent VMS process and deletes the subprocess
and all its descendent subprocesses.
WIZARD In the case of a batch job submittal (Section 5.2.3) from VICAR, a separate VMS process is
initiated. The name of the submitted procedure PDF is taken as the
process name of the batch job, e.g.,
MYPDF. When the job
begins to execute, a subprocess (
MYPDF1) is created as
the environment from which the VICAR commands are executed. Both
process and subprocess, of course, go away at job termination.
WIZARD Asynchronous processes (Section 5.2.2) are handled similarly. They differ
from batch jobs in that a subprocess is initiated under which a second
subprocess is created for the VICAR environment. The process name of
the first subprocess is created by concatenating the eight character
Process ID number of the VMS process with the first four characters of
the PDF being run and appending a character zero. Therefore, the
first subprocess may have a process name like
22058225IMAG0. The second subprocess gets that name with
1" appended to it.
WIZARD The following diagram illustrates the relationships of the VMS processes and subprocesses utilized by VICAR.
WIZARD Because of this interesting relationship of processes and subprocesses, a user must realize that observing the progress of a process with a DCL SHOW SYSTEM command, for instance, may be meaningless because most of the action is occurring within one or more subprocesses.
WIZARD Normally, actions performed in DCL mode of VICAR will take place in the subprocess. It is possible, however, to affect the parent process as well (see Section 18.104.22.168 for more discussion in this area). DCL commands which allow the /JOB qualifier affect both the parent and the subprocess when the qualifier is present.
Example: Define and use a logical name for a parent and subprocess.
VICAR>DCL DEFINE/JOB A UD:[USERID] VICAR>ENABLE-SCRIPT A:GEOMIT.SCR
5.4.1 Logon Procedures
When the user enters VICAR, the system logon procedure,
slogon, is invoked.
slogon is a
facility-dependent logon procedure which is normally invisible to the
interactive user and is typically created and maintained by the system
manager. Once VICAR has been invoked, the operating system executes
this logon procedure and a series of steps are executed in order to
set up the VICAR environment. One of the last steps in the startup
procedure is to examine the user's present directory for a
ulogon.pdf and to execute that procedure if it
ulogon is a procedure typically written and
maintained by the user in order to customize the initialization of the
ulogon is not a required procedure but most
users find it very useful. For example, the
be used to define the user's VICAR commands, specify the location of
the directories where the user's application software resides or to
configure the user's VICAR session.
Example: ulogon.pdf (A detailed, line-by-line, description can be found in Appendix 10.11).
Procedure Refgbl $PROMPT Refgbl $BECHO Refgbl $ECHO Body ENABLE-LOG DEFCMD SCR "Enable-script" DEFCMD CHK "Syntax check" DEFCMD NOCHK "Syntax nocheck" DEFCMD QUE "ush lpq" LET $ECHO= "YES" LET $BECHO= ("YES","YES") LET $PROMPT="GoGetum" End-procThe user may define a VMS logical name to point to a
ulogon. Doing this causes the same
ulogonto be executed regardless of the default directory. At the current time, this cannot be done on UNIX systems, and a user must have a copy of their
ulogon.pdfin each directory from which they wish to run VICAR.
Example: Define a VMS logical name, in user's LOGIN.COM,
pointing to user's
$DEFINE ULOGON MGN4:[USERID]ULOGON.PDFAlternatively, the user could have a custom
ulogonin each directory by not defining the logical name and maintaining separate
5.4.2 Logoff Procedures
slogoff is a facility-dependent logoff procedure
which is activated when the user exits from VICAR. One of the steps
in the procedure is to examine the user's current directory for a
ulogoff.pdf and to execute that procedure if it
ulogoff is typically written and maintained by the
user in order to customize the exiting from the VICAR session. The
ulogoff is not a required procedure but some users find
it to be very useful for directory maintenance. For example, the
ulogoff can be used to delete unnecessary files from the
user's directories or to automatically print out the latest version of
Example: ulogoff.pdf (A detailed, line-by-line, description can be found in Appendix 10.11)
Procedure Body DISABLE-LOG ush /bin/rm last.par ush /bin/rm session.tsl ush lpr session.log End-procAs with the
ulogonthe user should define a VMS logical name to point to a
ulogoff. Doing this causes the same
ulogoffto be executed regardless of the default directory. (Again, this is not currently possible on UNIX systems.)
Example: Define a VMS logical name, in user's LOGIN.COM,
pointing to user's
$DEFINE ULOGOFF SYS$LOGIN:ULOGOFF.PDFAlternatively, the user could have a custom
ulogoffin each directory by not defining the logical name and maintaining separate
5.5 Aborting a VICAR Command
VICAR provides the user with the ability to interrupt a VICAR
operation once execution has started. VICAR has defined the key
Control-C to activate "proc interrupt mode".
Control-C, the operation is suspended and
the user is prompted by the "interrupt prompt" for appropriate
VICAR-INTERRUPT>commandThe user may enter one of the following commands:
[TAE-NOSYNC] Synchronous procs not available in proc interrupt mode.While a proc is interrupted, it is valuable to be able to perform Intrinsic commands and then resume the proc. The commands will take effect immediately.
Example: Specify an Intrinsic command and resume a proc.
VICAR-INTERRUPT>let $echo="yes" VICAR-INTERRUPT>continueBEWARE
Control-Cis the only sequence defined for "Proc interrupt mode". Other control characters will have very different results. (See Section 22.214.171.124 for more information.)
If you wish to return to the Contents page, click here.