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
Manage transmission of spool file data via a GIVE/TAKE request to the AXS task Provide GIVE/TAKE requests to the REX task co.mand module (DftTC!X) The precise functional requirements vary froa line driver to line
driver, depending on the type of reaote station the line driver
supports.
Each line driver is responsible for maintenance of its _ link status
and line activity (TRACE) records in the RSCS system status tables. TWO line drivers are provided, one to support remote 2770, 2780, 3770 (in 2770 mode), and 3780 terminals, and another to interface to remote BASP- and ASP-type systems or work stations.
The SML Line Driver Program
The SML line driver program is composed of four general types cf
routines: Processors, which are routines that execute the functions required by
the HOST and RJE Frocessing modes. An input/output routine that accepts and transmits data on the BSC line. A function selector routine that dispatches one of the processors
when a request for services is received. Buffer blocking and deblocking routines.
The SML line driver supports programmable remote HOST and RJE modes) for HASP- and ASP-type systems.
processing mode in which a remote station may·submit receive print and punch output froa VM/370. RJE mode mode in which VM/370 may send jobs to a remote
processing and receive print and punch output from
system.
stations (in both HOST mode is that
jobs to Vft/370 and
is that processing
batch system for
the remote batch
Figure 5 shows the types of data flowing to and from RSCS via the S!L line driver Frogram. 3-1q IBM VM/370: system Logic and Problem Determination--Volu.e 3
Previous Page Next Page