Using Dependent Enclaves

When a unit of work is processed in multiple address spaces, you can use dependent enclaves to tie the work done in a supporting (server) address space back to the originating client address space. The dependent enclave represents the continuation of an existing address space transaction under a new set of dispatchable units in another address space.

Figure 9 shows how this works.

Figure 9. Using Dependent Enclaves

• Request subsystem function

  The originating address space, address space A, sends a work request to subsystem address space B, for example, by issuing a space-switching PC.¹ Address space A could be a TSO, batch job, or started task. The address space's performance goal is used to manage the transaction while running in address space A and also when running in the dependent enclave.

• Determine if an enclave exists

  Subsystem address space B uses IWMESQRY to determine whether the caller is already in an enclave. If it is in an enclave, it would use that enclave and schedule SRBs to the enclave, or join tasks to the enclave.

• Create dependent enclave Y

  If the caller is not in an enclave, the subsystem creates a dependent enclave using IWM4ECRE with the TYPE=DEPENDENT parameter. The home space when IWM4ECRE is issued, in this example address space A, is the owner of the dependent enclave. No classification information is required on IWM4ECRE for a dependent enclave. The service class or performance group of the owning address space A is used to manage the work in the enclave. The subsystem does not need to connect to workload management (using IWM4CON) to create a dependent enclave.

• Pass enclave token

  The subsystem posts Task 1 in the supporting address space, address space C, to join the enclave, passing it the enclave token tokenY passed back by IWM4ECRE. The subsystem can also schedule SRBs into the same enclave. The work running in the dependent enclave executes in address space C but is managed to the goal of the owning address space A.

• Join enclave Y

  Task 1 joins enclave Y using the enclave token passed from the subsystem. The work running under Task 1 is now managed to the goal of address space A.

  For further information, see Performance Management of Address Spaces with Enclaves.

• Attach subtask; detach subtask

  Task 1 may attach one or more subtasks while it is joined to enclave Y. These subtasks are automatically joined to enclave Y and also managed to address space A's goal.

• Leave enclave Y

  When Task 1 completes the work request, it leaves the enclave. It reverts back to being managed to address space C's goal.

• Delete the enclave

  The subsystem waits for the tasks, and any SRBs, to complete the request, then deletes the enclave (if it created it) and returns to the caller.