which RSCS knows the task), the address of the line which is used by the link, and se on. The link table (a chain of LINKTAEL DSECTs) is built
during system generation and may be updated ty the DEFINE, DELETE, START, and DRAIN commands.
TAG: RSCS FILE DESCRIPTOR The TAG DSECT defines the attributes and status of a file being processed by RSCS. The TAG is built from information passed via the CF
TAG command (or its counterpart for remote stations) and from the CF SFool File Bleck (SFBLOK) that describes the file. RSCS REQUEST ELEMENTS Request elements are data tables built by task programs when a service is to be requested by the task.
For example, when a command is processed by tMTCMX, the command line may be formatted into ao command element, which gives the following types
of information: Length of the command element The unique code identifying the command element The linkid to which command response is to be returned Modifiers that specify options for a given command A variable length buffer field containing the command line
This command element is then passed (via D81SIG) to another task fer
processing. Other types of request elements are built to process individual
commands and messages, to create and terminate tasks, to process console I/O, and so on.
In many cases, elements are contained in a generalized control area
used when processing a system function, for example, monitoring requests
for DMTAXS module to open or close a V8/370 spool file. VM/370 DATA AREAS REFERENCED BY RSCS There are two V8/370 CP data areas referenced by RSCS when V8/370 spocl
files are processed: SFBLOK The VM/370 spool file block that contains control information
and describes attributes of a VM/370 spool file. SPLINK The data block that links pages of a VM/37C spool file buffer. RSCS Storage Requirements
Figure 7 shews the storage used by the BSCS control program and how the parts of the system (the Supervisor, the tasks, and the data areas) fit
together in storage. 3-20 IBM VM/370: System Logic and Problem Determination--Volume 3
0 DMTVEC 270 DMTMAP DMTEXT DMTSVC DMTIOM DMTQRQ DMTDSP DMTiAT DMTPST DMTASK DMTSTO DMTASY DMTSIG DMTGIV DMTAKE 1000 Supervisor Queue Extension 20001 1 I Free Storage (alloca table)
r I DMTREX 1--------------------------- I DMTCMX 1--------------------------- I DlITEGX 1------------------------- I DHTCRE 1--------------------------- 1 DMTCOM 1--------------------------- I 1 1 I , tMTMSG DHTSYS DMTINll Free Storage 700001-----------------------­ , Third Line Driver 740001 Second Line Driver I 780001-----------------------­ First Line Driver i 7COOOI-----------------------­ I 7DOOOI DMTLAX DMTAXS I 1 IDMTINI begins at the first page boundary following DMTSYS. ,
After I I I initialization its storage becomes part of free storage. L Figure 7. RSCS Storage Allocation
Synchronizing and Dispatching Tasks
The means by which RSCS synchronizes and dispatches tasks are the WAIT/POST routines (DMTWAT and DMTPST), synchronization locks,
asynchronous requests and exits, and the dispatcher routine (DMTDSP). The WAIT/POST method of task synchronization (Supervisor modules DMTWAT and DMTPST) is used when an executing task requires the services
of another task. When this situation occurs, the requesting task must
suspend its execution while it waits for the requested service to be
performed. In conjunction with the dispatcher, WAIT/POST allows tasks
to temporarily suspend execution until they receive a signal (via the
synch lock) that they can resume execution. RSCS Introduction 3-21
Previous Page Next Page