Sharing MSNAME definitions and SYSIDs in an IMSplex

In an IMSplex with shared queues, when you start an IMS system that includes MSNAME statements, the IMSplex shares the MSNAME statements and the local SYSIDs of the joining IMS system with the other IMS systems already in the IMSplex.

For each MSNAME statement in the joining IMS system, the IMSplex creates a duplicate dynamic MSNAME statement in each of the other IMS systems in the IMSplex, unless one already exists.

For each local SYSID owned by the joining IMS system, the IMSplex adds a duplicate local SYSID to the SYSID table in each of the other IMS systems in the IMSplex. This effectively makes the SYSID of the joining IMS system local to the IMSplex as a whole. The IMSplex updates the SYSID table of each IMS system in the IMSplex whenever an IMS system that has an MSNAME statement joins or rejoins the IMSplex.

The generation of dynamic MSNAME statements and the sharing of local SYSIDs throughout the IMSplex allow the IMSplex to function as a single IMS system on the MSC network. It also allows transactions defined to run in an MSC network to take advantage of the distributed processing of the IMSplex with shared queues.

To illustrate dynamic MSNAMEs and shared SYSIDs, The following figure shows a simple MSC network prior to introducing an IMSplex with share queues. Figure 2then shows the same MSC network after an IMSplex with shared queues has been created between two of the IMS systems.

Figure 1. MSC network without an IMSplex
Begin figure description: This figure is described in the surrounding text. End description.

In the previous figure, IMS1, IMS2, and IMS3 are each members of the MSC network. Each of their local SYSIDs are unique and their MSNAME statements only define the links that are defined locally in each IMS system.

Figure 2. MSC network coexisting with an IMSplex with shared queues
Begin figure description: This figure is described in the surrounding text. End description.

In the preceding figure, IMS1 and IMS2 are now part of an IMSplex with shared queues. Because of this, SYSID 1 becomes local to IMS2 and SYSID 2 becomes local to IMS1. Similarly, dynamic MSNAME MSN31 appears in IMS2, and dynamic MSNAME MSN32 appears in IMS1. IMS1 and IMS2 also remain connected to the MSC network and IMS3, although IMS1 and IMS2 now function as a single IMS system, or node, within the MSC network.

The following table represents the SYSID tables of the IMS systems shown in Figure 1 prior to introducing the IMSplex:
Table 1. SYSID ownership in an MSC network without an IMSplex
SYSID IMS1 IMS2 IMS3
1 Local RMT/MSN12 RMT/MSN13
2 RMT/MSN21 Local RMT/MSN23
3 RMT/MSN31 RMT/MSN32 Local
The following table represents the resulting SYSID tables in each IMS after the IMSplex is introduced into the MSC network, as shown in Figure 2:
Table 2. SYSID ownership in an MSC network that coexists with an IMSplex
SYSID IMS1 IMS2 IMS3
1 Local Local RMT/MSN13
2 Local Local RMT/MSN23
3 RMT/MSN31 Dynamic MSN32 RMT/MSN32 Dynamic MSN31 Local

When an IMS system leaves the IMSplex, the IMSplex does not change the SYSID tables or delete any dynamic MSNAME statements in the remaining IMS systems. This ensures that if there are any messages on the shared queues that use the MSNAME definitions of the departed IMS, the IMSplex can still process them. When an IMS system rejoins the IMSplex, the IMSplex always exchanges MSNAME statements again and revalidates the rejoining SYSID on all SYSID tables in the IMSplex.

Whenever an IMS system successfully joins or leaves an IMSplex with shared queues, the IMSplex issues message DFS0778I to the master terminal of each IMS system in the IMSplex.