The ALERT routine (DMTSIG) also notifies another task
asynchronous event has taken place. In this case, DMTSIG is with an ALERT request element. GIVE/TAKE TASK-TO-TASK that an
not used While the ALERT method of
response from the alerted
for ordered enqueueing of
handled when the servicing immediate demand. task-to-task communication demands immediate
task, the GIVE/TAKE method provides a means
requests for services. These requests are
task is free to handle it, rather than upcn
Generally, request and response elements are formatted tables cf
information that reside in the storage of both the requesting task and
the task providing the service. During task-to-task communication,
these elements are passed from One task to another, containing either requests for services or responses to requests. When a task requests services of another task via GIVE/TAKE, it builds a GIVE table in its storage. The GIVE request buffer and a GIVE response
buffer. (The request and response buffers may te at the same locaticn
in storagee)
The GIVE request buffer contains a GIVE request element, which is a
table of information describing the service being requested. Once the GIVE request element is built, the requesting task clears the synch lock
in its address of the GIVE table to zero (in preparation for a call to DMTWAT) and sFecifies the address of the GIVE tatle in a call to DMTGIV. The supervisor then enqueues a supervisor GIVE element containing a
pointer to the GIVE table, so that the request can be forwarded to the
receiving task when that task is ready to accept the request. When the receiving task signals that it can process a GIVE request, the
receiving task builds a TAKE table in its own storage. The TAKE table
consists of a field to receive the task name of the requesting task and
the addresses and the lengths of a TAKE request buffer and a TARE response buffer. Functionally, these buffers complement the GIVE request and response buffers and, like the GIVE buffers, may be at tbe
same location in storage. Introduction 3-25
Once the TAKE table is built, the receiving
address of the TAKE table in a call to DftTAKE. moves the GIVE request buffer (containing the GIVE the receiving task's TAKE request buffer.
task specifies the
The supervisor then
request element) to
The receiving task performs the service and updates the GIVE request element and places it 1n its TAKE response buffer. This
modified GIVE request element contains information on results of request
processing to be returned to the requesting task. When all request processing is complete, the receiving task again
calls DMTAKE, specifying the address of the TAKE table. The superv1ser
respcnds by i.mediately moving the contents of the receiving task's TARE reponse buffer to the requesting task's GIVE response buffer, and
posting the synch lock in the requesting task's GIVE table.
If another GIVE request addressed to the receiving task has been
enqueued, it 1S given to the receiving task as described above, and
dispatched task execution is resumed. On each call to it, DftTAKE first
responds tc a previously accepted GIVE request (if one exists) and then
gives another modified GIVE request element back to the calling task (if
one exists).
The requesting task waits for request
address of the synch leck in its GIVE routine (DMTWAT). completion by specifying the
table in a call to the WAIT The receiving task waits for request availability by calling DftTWIT and specifying the address of its "task request synch lock," which is
located in its Task Save Area. The task request synch lock is cleared
to zero by DMTAKE when no GIVE request address to the calling task
remains enqueued. It is posted by DMTGIV when such a request is
enqueued as a result of DMTGIV processing for another task.
Figure 9 shows the movement of data during a GIVE/TAKE transaction.
3-26 IBM VM/370: System Logic and Problem Determination--Volu.e 3
Previous Page Next Page