DFSMStvs can be used within an application that uses multitasking. That is, the application can consist of a mother task with multiple daughter tasks to which work is allotted. For example, Figure 1 shows a mother task and three subtasks.

One use for multitasking might be for an application that functions as a transaction dispatcher. The following rules apply; if they are not followed, unpredictable results can occur. The application must follow these rules because DFSMStvs has no way to detect violations or to enforce these rules.

1. When DFSMStvs is invoked, it uses the current context. Normally, this is the RRS native context that is associated with a dispatchable unit of work. A context is a representation of a work request, and a unit of recovery is the work done by or on behalf of the context between one point of consistency and another. Therefore, all work within a single unit of recovery (transaction) must come under a single context. When using native contexts, a single unit of recovery cannot cross task boundaries. In this example, subtask 1 and subtask 2 cannot do work on behalf of the same unit of recovery.
2. If an application wishes to share work for a single unit of recovery across task boundaries, it must create one or more privately managed contexts. The application is responsible for managing those contexts and ensuring that the correct context is associated with a dispatchable unit when DFSMStvs is invoked. This ensures that the work being done is associated with the correct unit of recovery. Because privately managed contexts take precedence over native contexts, associating a privately managed context with a dispatchable unit causes it to become the current context.
3. Applications must ensure that the same context is used for operations that are part of the same unit of recovery. If an application issued a GET UPD request then switched contexts before issuing the corresponding PUT UPD request unpredictable results could occur.
4. DFSMStvs allows context switching provided that your application completes all asynchronous I/O. You can use the CHECK macro to wait for I/O associated with an RPL to complete.