Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Example of Designing and Implementing a Multisystem Application z/OS MVS Programming: Sysplex Services Guide SA23-1400-00 |
|
Note: This example illustrates only mainline paths, and does not cover
error conditions, serialization, or synchronization. The intent of
this example is to illustrate, at a high level, the way members of
a group interact, the way the members use the XCF macros, and the
way the various user routines interact. Examples of macro invocations
are provided where appropriate. See z/OS MVS Programming: Sysplex Services Reference for
an explanation of the parameters used on each macro.
In this example, an installation has three MVS™ systems in an XCF sysplex. Users on each of the three systems can obtain phone numbers from a database, and can add, change, and delete phone numbers. The multisystem application that handles maintaining the database, and providing information to users, consists of a group (called PHONBOOK) with one member on each of the MVS systems. The members consist of identical routines. All three members have identical message, status, and group user routines. All three group members can accept requests for work, but only the member designated as PRIMARY can perform the work. When the PRIMARY member fails, the BACKUP member takes over the work. This is an example of using XCF to achieve high availability. Figure 1 illustrates the relationship between the members of the group. Member 1 and member 2 have access to the DASD device that contains the PHONBOOK database. Member 3 does not have access to the database. In the figure, member 1 is shown as the PRIMARY member and member 2 is shown as the BACKUP member. It is also possible for member 2 to be the PRIMARY member and for member 1 to be the BACKUP member. Member 3 is shown as NO-BACKUP because member 3 cannot access the database. Member 3 cannot be PRIMARY or BACKUP. The PRIMARY, BACKUP, and NO-BACKUP designations are made by the operator when the tasks are started. The designations are maintained in the member's user state field. These designations can change dynamically if something happens to the PRIMARY member, causing the BACKUP member to take over. See What is Another Method for Designating Members? for an alternate way to designate the members. Figure 1. PHONBOOK
Multisystem Application
|
Copyright IBM Corporation 1990, 2014
|