An asynchronous job executed with an associated Terminal Monitor is
defined as a normal asynchronous job. An asynchronous job initiated
without an associated Terminal Monitor is an ASYNC-PROCESS job. This
section describes in detail the characteristics of the two types of
asynchronous jobs.
A proc may be submitted for normal asynchronous execution. Such a job
has the following characteristics:
- The job executes immediately, but in parallel with the interactive
session. Following submission, the interactive user may continue with
other commands. In addition the functions $ASFI (Section 3.3.5.6) and $ASKEY (Section 3.3.5.7) return the current value
of an executing asynchronous jabs $SFI and $SKEY.
- The SLOGON proc is executed as part of the job initialization. When
the proc terminates, the SLOGOFF proc is executed.
- The job runs with a scheduling priority equal to the user's
interactive priority.
- The standard output is, by default, a "LOG" type file with the same
name as the proc. (The asynchronous proc invocation line may override
this default with the STDOUT qualifier.)
- The ENABLE-LOG and ENABLE-SCRIPT commands are ignored in
asynchronous jobs.
- The EMIT command may be used anywhere in an ASYNC procedure to
transmit the status values of $SFI and $SKEY to the parent TM. The
interactive user may then monitor the execution of the procedure by
using the SHOW-ASYNC command.
- The value of the $RUNTYPE variable is global "ASYNC".
- The initial environment of the asynchronous job is a copy of the
level zero variables of the invoking job. Thus, when an asynchronous job
is invoked from an interactive session, the current values of all global
variables and all locals defined on the interactive level are copied
into the asynchronous job.
The two jobs continue executing asynchronously, and the values of the
level zero variables may diverge; TAE only guarantees that the initial
values in the asynchronous job are a snapshot of the values in the
invoking job at the time of invocation.
- An asynchronous job may not change variables in the invoking job.
When an asynchronous job terminates, all of its global variables and all
of its level zero local variables are deleted.
Following job submission (with the RUNTYPE=ASYNC qualifier), the $SKEY
status variable is set to the job name. $SKEY is described in Section 3.3.2.7.1. In addition, the
functions $ASFI (Section 3.3.5.6)
and $ASKEY (Section 3.3.5.7)
return the current value of an executing asynchronous job's $SFI and
$SKEY.
A normal asynchronous job may request dynamic parameters using GETPAR
from a procedure or by calling the XQDYNP or q_dynp subroutine from a
process. The request is held until the interactive user executes a REPLY
command for the asynchronous job. Dynamic requests are only valid from
normal asynchronous jobs that are submitted from interactive
sessions.
An asynchronous job may not directly supply output variables into the
context of the invoking job. An asynchronous job may, however, create
disk files of TCL variables using the TCL SAVE command, the XQWRTB or
q_wrtb subroutines; these variable values may be copied into the context
of the invoking job with the TCL RESTORE command.
An ASYNC-PROCESS job is similar to a normal ASYNC job in many of the
characteristics mentioned in the previous section. For example to submit
an ASYNC-PROCESS job:
-
PROC-NAME RUNTYPE = (ASYNC-PROCESS, MYJOB)
where PROC-NAME is the name of the proc and MYJOB (default is the proc
name) is the job name specified by the user.
An ASYNC-PROCESS job is different from a normal asynchronous job in the
following ways:
- There is no associated Terminal Monitor, and the overhead of
initiating an ASYNC-PROCESS job is several times less than the overhead
of initiating a normal ASYNC job.
- The proc initiated with ASYNC-PROCESS must be a PROCESS PDF.
(PROCESS PDFs may also be initiated as normal ASYNC jobs, with the
associated overhead of a Terminal Monitor.)
- ASYNC-PROCESS jobs are not allowed to execute dynamic tutor
requests.
- ASYNC-PROCESS jobs are not allowed to supply outputs to TCL global
variables and NAME type parameters.
- ASYNC-PROCESS jobs are not allowed to call the XMPUT subroutine from
FORTRAN or the m_msg function from C.
- By default, the standard output of an ASYNC-PROCESS job is assigned
to the null device (i.e., the "NL:" device in VMS and the "/dev/null"
file in UNIX). If a real standard output file is desired, the STDOUT
qualifier must be specified.
The purpose of the ASYNC-PROCESS feature is to provide efficient
asynchronous execution for those applications willing to comply with the
above restrictions.
Using SENDVAR and RECVAR a form of interprocess communication may be
established among concurrent jobs. They may send and receive messages
with each message being a TAE V-block containing TCL variables. The
intent of SENDVAR/RECVAR is to support the "server" model:
- A server job is initiated using |RUNTYPE=ASYNC-PROCESS|,
|RUNTYPE=ASYNC|,or some host-dependent facility.
- The server creates a widely-known input queue (a mailbox under VMS
or a socket under UNIX) to receive requests. If the server is written in
TCL, then the ENABLE-RECVAR command is used to create the queue; if the
server is written in C, then the c_crepath function is used.
- Jobs may request service from the server by sending a request to the
server's queue. If the requesting job is written in TCL, then the
SENDVAR command is used to transmit the request; if the requesting job
is written in C, then the c_pmwcd function is used.
- The server executes sequentially, pulling a request from its input
queue, processing the request, and returning a message to the requesting
task. The server receives requests via RECVAR in TCL or c_getmsg in C.
The server returns data to the requesting process using SENDVAR in TCL
or c_pmwcd in C.
Note that two queues are involved in a server transaction: the queue
used for the request (the server's queue) and the queue used for the
response (the requestor's queue).
The SENDVAR/RECVAR capability described here is considered a basic
capability because (a) the RECVAR command is blocking (synchronous) and
(b) only one input queue is allowed per TCL job. The T_SENDVAR PDF in
the demonstration directory ($TAEDEMOCLASSIC) illustrates the
SENDVAR/RECVAR functionality.
Sections 3.4.2.20, and 3.4.2.23 describe these commands in
detail.