Before discussing how to write a wait routine, however, let's look at how
the synchronization point manager (SPM) handles asynchronous processing, so
we can understand how to take advantage of CRR's tolerance for multitasking.
When the SPM receives an asynchronous request, it starts the asynchronous
process and then calls DMSCWAIT to wait for the request to complete. While
the SPM—and consequently the virtual machine on which it is running—waits,
the request is processed. Once the request has been completed, the interrupt
handler for the module that processed it calls the DMSMARK CSL routine to
allow the SPM to resume processing. (DMSMARK is described in the z/VM: CMS Callable Services Reference.) The SPM
then checks the results of the asynchronous request and continues its processing. Figure 1 outlines this sequence.
Figure 1. Asynchronous Processing Sequence in CRR
SPM receives an asynchronous request
SPM starts the asynchronous process ----->
SPM calls DMSCWAIT (to wait)
Request is processed.
When the request
completes, interrupt
handler calls DMSMARK,
which changes the
SPM's state.
<------------------------------------------
SPM looks at result of asynchronous
request and continues its own
processing.
Requests to the SPM are identified by a special integer value, called a
request ID, that is associated with the work unit originating the request.
The SPM calls DMSCWAIT with this request ID.
Tolerance for multitasking during asynchronous communications can be achieved
by exploiting the following CRR operating characteristics:
Whenever CRR must wait on an asynchronous event, it uses a replaceable
system function, the DMSCWAIT CSL routine, to wait for the request to complete.
For example, a resource adapter may be processing a coordination exit asynchronously.
By specifying the ASYNC option on the DMSSSPTO (Set Synchronization Point
Options) CSL routine, you can indicate that CMS is to perform SPM processing
asynchronously and call DMSCWAIT whenever it waits.