6. DATA SOURCES › 6.12 Multisystem Enclaves Overview
6.12 Multisystem Enclaves Overview
Multisystem enclaves support multiple address spaces spanning
multiple systems within a parallel sysplex. Work is reported
on and managed as a single unit.
CONCEPTS AND TERMINOLOGY
Multisystem enclave support allows an address space to be
split across multiple systems as the workload manager (WLM)
sees fit.
Large transactions split across multiple systems in a
parallel sysplex can improve the transactions response time.
Multisystem enclaves provide consistent management and
reporting for these types of transactions.
Benefits of using multisystem enclaves include the following:
o The same service class is used for all parts of a
split transaction. CPU usage of the whole
transaction is used to switch periods if the
service class has multiple periods.
o The owner of the enclave SMF type 30 record records
CPU time accumulated by all of the multisystem
enclave it owns, for all systems on which they
executed. Each remote system service is recorded
by individual system in the SMF type 30 record.
Each segment of multisystem enclave activity
contains information for each system.
When a multisystem enclave begins on a single system,
it begins as the 'original' enclave. The work manager can
'export' the enclave to other systems in a parallel sysplex
if the WLM sees a need due to heavy workload.
The WLM in the supporting address spaces on other systems
can 'import' the enclave onto its system. The export token
is passed and a special enclave token is received that is
valid for its system only. The new supporting enclave is
called a 'foreign' or 'remote' enclave. So, the original
enclave and foreign enclaves become one unit called a
multisystem enclave.
When work has been completed in the foreign enclave, the
supporting work manager 'unimports' the enclave, and the
original work manager receives a signal that work has been
completed. When all the supporting work managers have
unimported their enclave, the original enclave is
'unexported' by the original work manager. The original
work manager that created the original enclave deletes it
after all work has been completed.
Each work manager must first connect to WLM to enable
importing and exporting of enclave tokens. All importing,
exporting, unimporting, and unexporting, must all be invoked
from the connecting address space.
WLM will automatically undo a work manager's import/export
requests when:
o Work manager disconnects from WLM
o Work manager's connecting task or address space
ends
o Work manager's system fails
If there is an incomplete export caused by the original work
manager's request, or WLM recovery action, before all work
has been completed, outstanding imports are handled as
follows:
o Any outstanding imports on the same system of the
original enclave is automatically undone. When
the original work manager attempts to import the
original enclave, the original enclave is
received, meaning there is no export. A warning is
issued when the work manager attempts to unimport
the enclave.
o All outstanding imports on foreign will be
effective. No notification is provided by the WLM
to supporting work managers that exports have
ended. Supporting work managers must terminate
work on their own.
o New import requests are rejected.
An enclave can be exported multiple times either by the
original work manager or other work managers.
When a work manager on the original system attempts to
import the original enclave, the token of the original
enclave is received.
An enclave can be imported multiple times by more supporting
work managers.
Foreign enclaves cannot be exported. Once an enclave has
been imported to a foreign system, it cannot be exported
again from that system.
The following sections describe various aspects of
Multisystem Enclaves:
1 - Independent vs Dependent Enclaves
2 - Enabling Multisystem Enclaves
3 - Accounting for Multisystem Enclaves
