An OAMplex consists of one or more instances of OAM running on systems that are part of a Parallel Sysplex. An OAMplex has a one-to-one correlation to an XCF group in a Parallel Sysplex. The XCF group associated with an OAMplex is joined by instances of OAM address spaces, running on separate systems in a Parallel Sysplex, sharing a common OAM database in a DB2 sharing group. Each instance of OAM is a member of the same XCF group. Also, the DB2 subsystems connected to these instances of OAM belong to the same DB2 data sharing group. The instances of OAM belonging to the same XCF group are able to communicate with each other through the XCF services. The DB2 data sharing group shares the DB2 database information (OCDB, OAMADMIN, and object databases) among OAMs belonging to the OAMplex. When different OAMs sharing a common database on DB2 join an XCF group to become an OAMplex, all object data and configuration information is known to all instances of OAM in the OAMplex. Any object, regardless of which OAM stored the object, can be retrieved by any instance of OAM in the OAMplex.
Requirement: In a Parallel Sysplex, only one OAM XCF group (OAMplex) can share a single common DB2 database. All instances of OAM running in XCF mode in a Parallel Sysplex sharing a common DB2 database must join the same XCF group. Also, all instances of OAM in an OAMplex must share a common catalog where the OAM collection names are defined. Multiple OAMplexes can exist within the Parallel Sysplex, but each OAMplex must use a different shared DB2 database. No two OAMplexes can share the same DB2 database. Additionally, OAMs that are not in XCF mode cannot share the DB2 database.
Recommendation: It is strongly recommended that object and object backup storage groups defined as enabled to one system in an OAMplex be enabled to all systems in the OAMplex. Additionally, it is recommended that the rules associated with an object or object backup storage group (with statements in the CBROAMxx parmlib member) be identical for each system in an OAMplex.
Refer to Defining storage groups and relating the libraries to the storage groups for more information on enabling an object or object backup storage group. Refer to 5 Changing system libraries and see the step to "Create or Update CBROAMxx PARMLIB members" for more information on CBROAMxx Parmlib statements.
OAM uses the XCF messaging facilities to communicate between systems, synchronize resource information, and coordinate where transactions should be processed.
OAM can be running in XCF mode (in an OAMplex), or non-XCF mode (not in an OAMplex). When OAM is running as part of an OAMplex on a system in a Parallel Sysplex, you must initialize that instance of OAM with a CBROAMxx PARMLIB member using the OAMXCF statement, which specifies an XCF member name and an XCF group name.
If all instances of OAM involved with the transaction belong to the same OAMplex, you can retrieve any OAM object from any z/OS system in a Parallel Sysplex. This is allowed regardless of which OAM in the sysplex stored the object or on which medium (DB2 sublevel, file system sublevel, optical, tape sublevel 1, or tape sublevel 2) the object resides. See Shipping request limitations for larger data objects.
The system uses transaction shipping to send and receive requests between OAMs within the OAMplex. If each instance of OAM in an OAMplex shares the same configuration, transaction shipping allows any OAM in a Parallel Sysplex to write objects to, retrieve objects from, or delete objects from any 3995 optical volume in the Parallel Sysplex. Requests to read data from or write data to 3995 optical volumes that reside in a 3995 optical library being managed by a different OAM on a separate z/OS system in the same Parallel Sysplex are serviced by sending the request (using XCF) to the OAM running on the z/OS system that controls the 3995 optical library dataserver. This configuration is possible only as long as both the requesting and responding OAMs are members of the same OAMplex. 3995 optical library dataservers are still controlled and managed by a single OAM running on a single z/OS system. If a system failure occurs, you can switch control of a 3995 optical library dataserver to another OAM running on another z/OS system in the same OAMplex.
Requirement: When multiple OAMplexes exist within a Parallel Sysplex, each OAMplex must have a unique set of OAM resources (optical devices and media for object storage) defined in its configuration.
The object tape environment also uses the basic concept of transaction shipping. However, MVS dynamic allocation handles the required tape resource allocation, because OAM does not control tape resources. Tape resources are allocated as needed and only for the time required for their use.
For object tape processing, tape drives must be available to any OAM in an OAMplex where a tape request may need to be processed. Tape transactions are shipped across systems only when the requested tape volume for a retrieve request is allocated and mounted on a tape drive that is in use by another OAM in the OAMplex, or when the OAMplex has different support levels (full support versus coexistence support). For example, if a retrieve request originated on a coexistence-support system and another system in the OAMplex is available and has full support for the request, the retrieve request can be shipped to the full-support system. There are no eligible tape drives on the system where the request originated to satisfy the request. Tape write requests are not sent across systems for processing.