z/OS MVS Programming: Sysplex Services Guide
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
PHONBOOK Multisystem Application

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014