This KD describes sharing databases among MUF regions via Sysplex Coupler Facility for workload balancing.
Release: Datacom
For the z/OS Sysplex user, since release 10.0, Datacom provides support for full data-sharing within the Sysplex. This feature has been nicknamed the "MUFPLEX". In a Sysplex that has multiple z/OS images that have access to a shared Sysplex Coupler Facility, clients are able to run up to seven different physical Multi-User regions that can process database requests as a single logical Datacom environment (the MUFPLEX).
In the MUFPLEX, the user databases are available for full update processing from any one of the "member" Multi-Users (MUFs) at any time. This gives the client the flexibility of adding/removing MUFs as needed to support a wide variety of processing requirements. Items such as re-cycling of z/OS images and making changes to the individual MUFs can be accomplished while still providing access to the user databases through the remaining active MUFs.
Within the MUFPLEX, member MUFs all share the same CXX,LXX and FXX datasets but each MUF must have its own PXX dataset. CBS index and SQL TTM database should be defined as virtual, to avoid unnecessary overheads.
All shared locking and buffering requirements are provided through the z/OS Sysplex Coupling Facility. Each member MUF communicates the status of its active tasks, locks, buffers etc. via the Coupler "List" and "Lock" structures.
Utilizing multiple z/OS images provides the client with a way to scale processing requirements as well as support z/OS workload balancing. A CICS region connected to the MUFPLEX will remain able to process as long as one of the member MUFs of the MUFPLEX remains active.
MUFPLEX support is a selectable MUF startup option. For clients who do not have a need for the MUFPLEX support, there is no additional overhead when this feature is not selected. For clients who select the MUFPLEX feature but only have one active member MUF the overhead is minimal. This will allow clients to run in a single member mode with very little cost until a need arises for a second member MUF.
For example, presume that an IPL of the production MUF machine is required. At that time, a second member MUF is started and the Sysplex Coupler Facility is utilized to manage the databases that are now shared. Once the second MUF is up, the workload can be shifted to the second MUF, the primary MUF can be stopped, and the z/OS image can be IPL'ed. Starting from release 11.0, this scenario can be managed defining a Shadow MUF.
Detailed information about MUFPLEX and Shadow MUF can be found on Database and System Administrator Guide manual.