Planning for MSC in a shared-queues environment

IMS systems in a multiple systems coupling (MSC) network can be part of a shared-queues environment, connected to IMS systems outside the shared-queues environment.

Each IMS within the IMSplex can act as any of the following:

A front end, receiving messages from terminals or across MSC links
A back end, processing messages received from a front end
An intermediate subsystem, receiving messages and passing them on to other IMS systems across MSC links

Although two IMS systems can have MSC links defined, messages are placed on the shared queues from one of these IMS systems and picked up for processing by another IMS within the IMSplex—these messages are not sent over the MSC links.

Exception: If one of these IMS systems is running without shared queues enabled, the MSC links are used. This situation might occur when migrating to a shared-queues environment.

To plan for using MSC in a shared-queues environment, take each of the following actions:

Specify all remote IMS systems on the MSNAME macro (SYSID and NAME) or the type-2 CREATE MSNAME command, and assign a unique SYSID within the local IMS. These remote MSNAMEs remain stopped and are used only to route messages from any IMS within the IMSplex to a remote IMS.
Define MSC remote system identifiers (SYSIDs), using the MSNAME macro or the type-2 CREATE MSNAME command, for each IMS within the IMSplex.
Within the local IMS, make all SYSIDs be unique across all IMS systems in the IMSplex and in the MSC network.
Define remote transactions and LTERMs to the IMS that has the MSC link (the back-end IMS). Also define them to the front-end IMS. If you do not define them, IMS calls the Destination Creation exit routine (DFSINSX0) to determine whether the destination is local or remote, and to determine whether it is a transaction or an LTERM.

When an MSC link exists on the front-end IMS, you can use MSC for APPC and OTMA transactions in a shared-queues environment. The conversation is maintained with the local IMS but is not carried to the remote IMS. Therefore, the remote application program cannot issue the SETO DL/I call, or the CPI-C verbs SEND_ERROR and DEALLOCATE_ABEND. Also, if the remote IMS allocates another APPC conversation, it receives the default user ID that is associated with the MPP region, and it does not use the original APPC user ID in order to verify security.