PROCESS COMMANDS: DMTCMX DMTCMX receives commands by means of either GIVE request elements passed
ty line driver tasks or in the form.of a console input line resulting
from a console read by DMTREX. The commands DEFINEr COERY, and START (for inactive
links) are executed by DMTCMX. Execution of these commands generally
involves referencing and modification of system status tables (SVECTCRS, TTAGQ, TLINKS, etc.).
If the command is not one that DMTCMX executes within its own cede,
the command line is examined for syntax errors and then passed to the
appropriate task for execution. To do this, DMTCMX generates a
formatted table called a command element to be passed to another active
task for execution via an ALERT asynchronous exit.
The commands CHANGE, ORDER, and PURGE are executed by DMTAXS; the
commands BACKSPAC, CMD, DRAIN, FLUSH, FREE, FWDSPACE, HOLD, MSG, TRACE and START (for active links) are executed by the line driver task fer
the specified link. PROCESS MESSAGES: DMTMGX DMTMGX manages distribution of all RSCS messages, which may be generated by REX or by any other RSCS task. Each message to te issued is
presented to DMTMGX (via GIVE/TAKE for tasks other than REX) along with
an internal routing code and an internal severity code.
Messages may be addressed to the local RSCS operator console, to the local VM/370 operator, to a local VM/310 user console, to a remote
station oFerator, or to any combination of these destinations, by means
of the routing code. The severity code is defined for each message, and
is an indication of the importance of the message. Messages for the RSCS local operator console are enqueued for output
on the RSCS virtual machine console. Messages for the local VM/370 system operator and for local virtual machine consoles are issued by means of execution of a VM/310 MESSAGE command (through the DI1GNCSE interface). Messages for remote RSCS operators are presented to the
line drivers for the associated links by means of the RSCS MSG command
element interface. This method of message handling simplifies RSCS message routing, tracing, and recording.
TERMINATE SYS7EM TASKS AND HANDLE PROGRAM CHECKS: DMTREX When a line driver task requests termination, a TAKE request is passed
to DMTREX specifying that function. DMTREX marks the task as
terminated, then searches for active I/O associated with the taskw If
active I/O is found, it is terminated. To ensure that system integrity
is maintained during the termination of the I/O, a mechanism (at label QUIESB) is set up to handle situations in which an HIO (Halt T/C
instruction) does not take effect immediately.
All RSCS program checks are handled by a routine in DMTREX. program
check diagnostic information is dumped, a message to the operator is
issued, and the RSCS system status is modified, depending on the nature
of the program check.
3-12 IBM VMj370: System Logic and Problem Determination--Volume 3

WITH THE V"/370 SPOOL FILE SYSTEM: D"TAXS D"TAIS is responsible for the maintenance of the total RSCS interface to
the VM/370 sFcol system. When a spool file arrives at the RSCS virtual
machine, AIS receives the associated asynchronous reads and
interprets the file's VM/370 spool file block (SIELOK) and TAG, enqueues
the file fer transmission as appropriate, and notifies the appropriate
line driver of the new file's availability. AXS provides a GIVE/TAKE request interface to line driver tasks for spool file data input and
output, and defines and detaches virtual spool I/O devices as necessary.
Also, AIS Frovides an interface to DMTCMX for second-level command
execution support. lIS maintains a queue of a fixed number of virtual storage elements
(called tag slots) that describe files currently owned by the RSCS virtual machine. To maintain RSCS integrity in a simple way when a very large number of files is enqueued on the RSCS virtual machine, the
virtual storage tag queue is not extended during execution. When a new file arrives at the RSCS virtual machine, its destinaticn
locid is examined, and it is accepted only if there is a matching linkid
for which there is a free tag slot available. If the file's destination
locid is not defined as a linkid, the file is purged and the originating
user is notified of the action. If there is no free tag slot available
for a defined linkid, the file is left "pending", and is accepted when a TAG slot becomes free. While a file is pending, it is not recognized hi the RSCS co •• and processors, and cannot be referenced through RSCS functions.
To prevent links from being totally locked out by an exhausted (and
stagnant) virtual storage tag queue, a minimum number of tag slots is
reserved for each link. This guarantees that a minimum number of files
is accepted for each associated link. The number of reserved slots is
defined during system generation or in the rEFINE command for each link
to be defined in RSCS. The appropriate number of slots to be reserved
for each link may depend on the expected file traffic, the link's line
speed, the expected time the link is to be active, and the desired level
of service to be provided to the link. This numter for each link may be
arrived at through actual operational experience in each location. MANAGE TELECOMMUNICATION LINE ALLOCATION: DMTLAX DMTLAX is responsible for line port resource allocation to line driver
tasks. DMTLAX allocates available switched ports (when a link is
activated without a specified line address) through an ALERT request
interface. When a line port is specifically requested (by virtual
address), DKTLAX checks the device for validity as a line port.
LINE DRIVER TASKS: DMTNPT AND DMTSML As part of the link activation process, REI (module tKTCRE) loads and
starts a line driver task to service the remote location.
The general functions of line driver tasks are: • "anage I/O on the BSC line RSCS Introduction 3-13