File Management RSCS uses the VM/370 spool file system to interface with VM/370 users.
A user who generates a file intended for transmission to a remote
location must spool the file to the RSCS virtual machine via the CP SPOOL command. In addition
r he must also enter the identification cf
the remote location into the spool file tag area via the CP TAG command.
A remote station submitting a file to RSCS for transmission to
another remote location must meet the same requirements as a VM/370 user. The ID card that precedes the input card file being transmitted
to RSCS must include the userid of the RSCS virtual machine and a tag
field containing the location identifier of the remote station that is
to receive the file.
A remote station submitting a file destined for a VM/370 user need
only specify that user's use rid on the ID card. When the RSCS virtual machine is initially logged on, one of the
first tasks that is started is the Spool File Access task, DMTAXS. Two main functions of DMTAXS are: to provide access to the VM/370 spool file
system, and to manage the queues of tag slots used by RSCS to control
the status and flow of files throughout the system.
TAG SLOT QUEUES The DMTAXS task in RSCS manages a file tag storage area pointed to by
TTAGQ in DMTVEC. This area is made up of a fixed numter of tag slots,
each containing 108 bytes. The total number of slots is determined, at
the time RSCS is generated
r by the value specified in the GENTAGQ macrc.
The number of slots reserved for each link is part of the link
definition stored in the RSCS link table. The contents of each file tag include file attributes from the file's SFELOK and transmissicn
destination and priority from the associated spool file tag.
File tags are chained on one of four types of queues: • The active input queue
r pointed to by TAGACIN in contains
the tags for those files that are currently being processed for
transmissicn to remote locations. • The active outfut queue, pointed to by TAGACCUT in contains
the tags for those files that are currently being received from
remote locations. • An inactive file queue exists for each
files waiting to be transmitted. Each pointed to by the LPOINTER field in entry.
link that has one or more link's file tag queue is
corresponding link table • The free slot queue, pointed to by TAGAFREE in TAGAPEA, is made up af all the slots not currently cn any of the other taJ slot queues.
336 IBM System Programmer's Guide

SPOOL FILE ACCESS The Spool File Access task, DMTAXS, uses the "retrieve subsequent file
descriptor" option of the CPDIAGNOSE X'n14'command to access the spocl
file block (SFBLOK) and spool file tag for each of the files enqueued cn
the RSCS virtual reader. Using the location identifier in the spool file tag. DMTAXS interrogates the link table entry for the specified link to determine if
a tag slot is available. If it is, a tag is built, using information in
the SFBLOK and spool file tag, and then enqueued on the link's chain cf
inactive files pOinted to by LPOINTER in the link table entry_ If a tag
slot is not available, the file is placed in a pending status and the
link table entry count of pending files (LPENDING) is incremented by
one. Pending files are added to the inactive file queues as slots
become available. When a line driver task is started for a link via the RSCS START command, the highest priority file on that link's inactive queue (LPOINTER) is degueued and placed in the system's active input queue
(TAGACIN). The file's tag and first spool buffer are then passed to the
line driver task for transmission. Any additional spool buffers for
that file are directly obtained by the line driver task.
Task-to-Task Communication RSCS provides two methods of task-to-task communications: GIVE/TAKE requests, and ALERT requests.
GIVE/TAKE requests are issued by lower-priority tasks, such as line
drivers, to request a service from a higher-priority task, such as a
supervisor service routine. The requesting task builds a request table
containing the name of the task that is to perform the service, along
with pointers to a request buffer containing the data required for the
service. If appropriate, a pointer to a response buffer is also
supplied. This information is passed to the DMTGIV module. DMTGIV builds a GIVE element that points to the requestor's request table and
chains it on the GIVE element queue for execution. Service tasks pass control to DMTAKE whenever they complete the
execution of a particular service a DMTAKE locates the GIVE element for
the service that was just completed, passes any response data back to
the requestor via the response buffer, locates the next GIVE element for
that service task, and passes the corresponding request table data to
the service task for execution.
ALERT requests are issued by high-priority tasks for services to be
performed by a lower-priority task. These requests are not queued; the
lower-priority task is executed as soon as it is received. ALERT
requests are handled by the DMTSIG module. RSCS Command Processing
The primary command processor in RSCS is the DMTCMX module of the system
centrol task. DMTCMX receives commands either as a result of a console
read started by the DMTREX module in response to attention interruption
from the RSCS operator console, or through a GIVE request pointer to a
command element, provided by an active line driver task.
Part 4. Remote Spooling Communications Subsystem (RSCS) 337