IMS TM Network Overview

IMS TM provides the necessary support for an advanced telecommunications network. Planning for an IMS network requires an understanding of each component and of its relationship to the others.

IMS TM interacts with:

• The IBM Systems Network Architecture (SNA), which brings together multiple products in a unified design. SNA formally defines the functional responsibilities of the network components.

  IMS TM supports SNA as currently implemented by the Communication Server for z/OS, which includes the functions of Virtual Telecommunications Access Method (VTAM). VTAM controls the physical transmission of data in the network, directing data to IMS from various logical units and from IMS to the appropriate logical units. IMS TM interacts directly with VTAM.

• Applications that use the z/OS APPC protocol.

• Networks that use TCP/IP. Access using TCP/IP is achieved by way of an additional address space, which is the IMS Connect function of IMS TM. IMS Connect must be configured to use the Open Transaction Manager Access (OTMA) protocol of IMS TM.

Related Reading: For more information about:

- OTMA, see "Open Transaction Manager Access" on page 179, or the IMS Version 9: Open Transaction Manager Access Guide and Reference.

- IMS Connect, see "IMS Connect" on page 187, or IMS Version 9: IMS Connect Guide and Reference.

- The options available for accessing IMS using TCP/IP, see Chapter 27, "Introduction to Parallel Sysplex," on page 467.

A network consisting of IMS and programmable logical units enables users to distribute functions throughout network components. This distribution of function can:

• Reduce processing requirements that are placed on the central processor (also referred to as the host).

• Reduce the impact on the rest of the network when one component encounters a problem.

Definitions:

• When a logical unit wants to communicate with IMS, the logical unit requests a connection with IMS. When IMS accepts the request, a logical connection is established between the logical unit and IMS. This logical connection is called a session.

• A programmable logical unit (LU) is an input or output device that is in session with IMS. Application programs in remote logical units can be designed to control more than one terminal.

Figure 12-4 illustrates the components of a sample communications network system. The arrows in Figure 12-4 indicate communications that occur between components. Figure 12-4 shows the following components:

Figure 12-4. Components of a Network

• IMS and its application programs

• VTAM

• Tivoli NetView® for z/OS

• z/OS operating system (including APPC/MVS, if APPC/IMS is used)

• IBM 37x5 Communications Controller and Network Control Program (NCP)

• Terminal (or logical unit)

The following lists summarize how each of the components in Figure 12-4 participates in the network:

IMS

• Checks transaction security.

• Schedules the proper application program.

• Directs output to the proper terminal or logical unit.

• Provides checkpoint and recovery capabilities.

Application program

• Reads data sent from the terminal or logical unit.

• Reads data from the database.

• Manipulates the data.

• Writes data to the database.

• Writes data to the message queue for the terminal or logical unit.

VTAM

• Connects and disconnects the terminal or logical unit from the network.

• Sends data from the terminal or logical unit to IMS.

• Permits both monitoring and modifying of the network.

• Sends data from IMS to the terminal or logical unit.

• Manages the physical network, with Tivoli Net View for z/OS.

VTAM controls the allocation of network resources, and enables these resources to be shared among VTAM users. To VTAM, IMS is a single VTAM user; VTAM is unaware of the IMS application programs.

IMS application programs use the DL/I callable interface to request IMS services; IMS uses VTAM macros to activate VTAM facilities.

If APPC/IMS is active, VTAM regards it as a separate user.

Related Reading: For more information about VTAM and its use, see z/OS V1R4.0 z/OS Communications Server: SNA Network Implementation Guide.

Communications Controller and NCP

VTAM uses the facilities of NCP, which runs in the 37x5 Communications Controllers. VTAM uses NCP to:

• Control lines and devices that are attached to the controllers.

• Transmit data between the logical unit and the host central processor complex (CPC).

• Perform error recovery.

• Collect statistics about the network.

The Communications Controller:

• Adds line control characters.

• Transmits data.

• Receives data.

• Removes line control characters.

• Checks for transmission errors.

• Controls buffering.

The NCP:

• Sends and receives data from communication lines and adapters.

• Checks for and records errors.

Terminal (or logical unit)

Depending on the system type, each LU can consist of one or more terminals. An application program that controls an LU consisting of more than one terminal or component must be able to direct output to a specific device. Therefore, the application program must be capable of some form of data interrogation in order to make the proper device selection. IMS assists the application program in this process by:

• Allowing LU components to be defined and addressed individually.

• Providing, in the header of each output message, the identification of the component to which the message is directed.

Some of the functions performed by the remote application program include:

• Reading from and writing to associated terminals.

• Editing and verifying the data that is received from a terminal.

• Reading from and writing to disk storage within the remote LU.

• Reading from and writing to the host in which IMS is running.

• Editing and verifying data that is received from the host in which IMS is running.

• Communicating with other network logical units.

• Formatting display and printer devices.

• Operating offline when the host, VTAM, IMS, or NCP is unavailable.

Required IMS TM Network Components

An IMS telecommunications network must include the following components:

• IMS

• VTAM

• Communications hardware, such as control units

• Terminals

Optional IMS TM Network Components

The network can optionally include any of the following components:

• IMS TM services, such as:

  - Open Transaction Manager Access (OTMA)

  - Extended Terminal Option (ETO)

  - Fast Path

  - Message Format Service (MFS)

  - Multiple Systems Coupling (MSC)

  - Intersystem Communication (ISC)

  - APPC

• IMS Connect function

• Common Queue Server (CQS) and a z/OS coupling facility with any of the following structures:

  - Shared-queues structures

  - Resource structures

• Common Service Layer (CSL), including:

  - Operations Manager (OM)

  - Resource Manager (RM)

  - Structured Call Interface (SCI)

• VTAM generic resource groups

Related Reading: For more information about:

• IMS Connect, see "IMS Connect" on page 187.

• CQS, see "Common Queue Server" on page 496.

• CSL, see "Common Service Layer" on page 496.

• VTAM generic resources, see "VTAM Generic Resources" on page 476.

IMS TM Services

This section describes several specialized optional Transaction Manager services.

Open Transaction Manager Access

OTMA is an open interface to IMS TM customers. With OTMA, a z/OS or TCP/IP application program can send a transaction or command to IMS without using SNA or VTAM. Many programs can connect to IMS TM using OTMA: middleware software, gateway programs, databases, and applications written by IMS users. Each of the programs or applications that communicates with IMS using OTMA is considered an OTMA client.

The OTMA interface is very flexible. An OTMA client, an application program of the client, or both, can use OTMA in many different ways. The execution of some transactions can involve complex "handshaking" between IMS and the client program; some transactions can simply use the basic protocol.

OTMA can be used to process an IMS transaction using one of the following methods:

Commit-then-send (CM0)

IMS processes the transaction and commits the data before sending a response to the OTMA client. Input and output messages are recoverable. The commit-then-send protocol is the traditional IMS asynchronous protocol, which is similar to the APPC asynchronous protocol.

Send-then-commit (CM1)

IMS processes the transaction and sends the response to the OTMA client before committing the data. Input and output messages are non-recoverable. This is the synchronous protocol, similar to APPC synchronous support.

If the application program uses send-then-commit processing, you must also decide which of the three synchronization levels to use:

None

Output is sent and no response from the client is requested. Data is committed if the send is successful. Data is backed out if the send fails.

Confirm

Output is sent and a response from the client is requested. The OTMA client must respond with an acknowledgement signal to IMS Connect that confirms whether or not the output message send was successful or unsuccessful. Data is committed if the send was successful. Data is backed out if the send was not successful.

Syncpt

Output is sent, and a response from the client is requested. Use syncpt to coordinate commit processing through the z/OS Resource Recovery Service (RRS). The OTMA client must respond with a signal that the send was successful or not. Data is committed if the send was successful and an RRS commit is received. Data is backed out if the send was not successful or an RRS abort is received.

An application can decide, for example, that inquiry transactions should use a synchronization level of none (because there are no database updates) and that update transactions should use a synchronization level of confirm.

The OTMA resynchronization interface ensures that no duplicate CM0 input and output messages exist by using a unique recoverable sequence number in every CM0 message. The client can optionally initiate the resynchronization during connection time. IBM WebSphere MQ for z/OS and IMS Connect extensively exploit this OTMA interface. An IBM WebSphere MQ for z/OS application program can send a persistent message to IMS to take advantage of resynchronization. However, sending an IBM WebSphere MQ for z/OS non-persistent CM0 message to IMS bypasses resynchronization.

Definitions:

Persistent message A message that survives a restart of the queue manager.

Non-persistent message A message that does not survive a restart of the queue manager.

Tpipe A named IMS process management resource. An OTMA client must specify this resource when submitting a transaction to IMS. A Tpipe is analogous to an LTERM.

Use Table 12-2 to determine which OTMA method is appropriate for your application.

Table 12-2. OTMA Methods for Processing Transactions

Type of Processing	Commit-then-send (CM0)	Send-then-commit (CM1)
Conversational transactions	Not supported	Supported
Fast Path transactions	Not supported	Supported
Remote MSC transactions	Supported	Supported
Shared queues	Supported in IMS Version 7 and later	Supported in IMS Version 8 and later
Recoverable output	Supported	Not supported
Synchronized Tpipes	Supported	Not supported
Program-to-program switch	Supported	Supported, but with qualifications.[a]

^[a] If a series of programs within one IMS perform program-to-program switches from one program to the next program, all the programs process as send-then-commit (CM1). If more than one program-to-program switch is performed within a single program (to other programs), only one of the program-to-program switches processes as send-then-commit (CM1). The other program-to-program switches process as commit-then-send (CM0). The techniques to mitigate this situation are described in IMS Version 9: Open Transaction Manager Access Guide and Reference.

Extended Terminal Option (ETO)

IMS Extended Terminal Option (ETO) provides dynamic terminal and local and remote logical terminal (LTERM) support for IMS TM. ETO is a separately priced feature of IMS TM.

You can add terminal hardware and LTERMs to the IMS without first defining them. ETO gives you the option of eliminating macro statements in the IMS system definition of VTAM terminals and LTERMs. ETO enhances the availability of your IMS by eliminating the need for you to bring the system down in order to add terminals and LTERMs.

ETO also enhances security for the IMS TM user by associating all output with a specific user, instead of with a device. ETO requires the user to sign on.

ETO reduces the IMS system definition time for those systems where the terminal network is defined dynamically.

Restriction:

The Security Maintenance Utility (SMU) does not support ETO. Security for ETO is enforced using RACF or a similar product.

Related Reading: For more information about how ETO can dynamically add terminals and users to an IMS system, see "The Extended Terminal Option (ETO)" on page 338. For complete information about ETO, see IMS Version 9: Administration Guide: Transaction Manager and IMS Version 9: Installation Volume 2: System Definition and Tailoring.

Fast Path

Fast Path is capable of performing transaction and database processing at high rates. When your system requirements include a high transaction volume, using Fast Path can be advantageous if you do not require all the facilities of full-function processing. Examples of such applications include teller transactions in banking and point-of-sale transactions (inventory update) in retail marketing. Fast Path input and output messages use expedited message handling (EMH) and bypass message queuing and the priority-scheduling process.

Related Reading:

• For more information on the expedited message handler (EMH), see "Scheduling Fast Path Transactions" on page 212.

• For more information on message queuing and message scheduling, see "Message Queuing" on page 198.

Message Format Service

IMS Message Format Service (MFS) is a facility that formats messages to and from:

• Terminals, so that application programs do not have to process device-dependent data in input or output messages. An application program can format messages for different device types using a single set of editing logic, even when device input and output differ from device to device.

• User-written programs in remote controllers and subsystems, so that application programs do not have to be concerned with the transmission-specific characteristics of the remote controller.

Related Reading: For more information on MFS, see Chapter 17, "Editing and Formatting Messages," on page 297.

Connections to Other IMS and CICS Subsystems through MSC and ISC

IMS TM has special protocols for connecting to other IMS systems, such as Multiple Systems Coupling (MSC), and to other CICS and IMS systems, such as Intersystem Communication (ISC), which allows work to be routed to and from the other systems for processing.

The MSC connections can be through the network to other IMS systems on the same or other z/OS systems, by using:

• Channel-to-channel connections to the same or another channel-attached z/OS system.

• Cross memory services to another IMS subsystem on the same z/OS system.

• The VTAM LU 6.1 protocol.

ISC links to other CICS or IMS systems are provided over the network by using the VTAM LU 6.1 protocol.

Multiple Systems Coupling (MSC) MSC is a service of IMS TM that provides the ability to connect geographically dispersed IMSs. MSC enables programs and operators of one IMS to access programs and operators of the connected IMSs. Communication can occur between two or more (up to 2036) IMSs running on any supported combination of operating systems.

MSC permits you to distribute processing loads and databases. Transactions entered in one IMS system can be passed to another IMS system for processing and the results returned to the initiating terminal. Terminal operators are unaware of these activities; their view of the processing is the same as that presented by interaction with a single system.

MSC supports transaction routing between the participating IMSs by options specified in the IMS system definition process.

Definitions:

• The IMS system where the transaction is entered by the terminal user is referred to as the front-end system.

• The IMS system where the transaction is processed is referred to as the back-end system.

The transaction is entered in the front-end system and, based on the options specified in the IMS system definition process, the transaction is sent to the back-end system. When the transaction reaches the back-end system, all standard IMS scheduling techniques apply. After processing, the results are sent back to the front-end system, which then returns the results to the terminal user, who is unaware of this activity.

Intersystem Communication (ISC) ISC is also a service of IMS TM and, in addition to MSC, provides another way to connect multiple subsystems. ISC is more flexible than MSC because ISC supports the following connections:

• IMS-to-IMS

• IMS-to-CICS

• IMS-to-user-written VTAM program

The transaction routing specification for ISC is contained in the application program, instead of in the IMS system definition as it is for MSC.

ISC links between IMS and CICS use the standard VTAM LU 6.1 protocol that is available within the network. ISC links can use standard VTAM connections or direct connections.

As defined under SNA, ISC is an LU 6.1 session that:

• Connects different subsystems to communicate at the subsystems level.

• Provides distributed transaction processing that permits a terminal user or application in one subsystem to communicate with a terminal or application in a different subsystem and, optionally, to receive a reply. In some cases, the application is user-written; in other cases, the subsystem itself acts as an application.

• Provides distributed services. Therefore, an application in one subsystem can use a service (such as a message queue or database) in a different subsystem.

SNA makes communication possible between unlike subsystems and includes SNA-defined session control protocols, data flow control protocols, and routing parameters.

Comparing the Functions of MSC and ISC As discussed in "Multiple Systems Coupling (MSC)" on page 183 and "Intersystem Communication (ISC)" on page 184, both MSC and ISC enable a user to:

• Route transactions

• Distribute transaction processing

• Grow beyond the capacity of one IMS system

Both ISC and MSC take advantage of the parallel session support that VTAM provides. Some key differences exist, however. Table 12-3 on page 185 compares the major functions of MSC and ISC.

Table 12-3. Comparing MSC and ISC Functions

Comparative Aspect	MSC Functions	ISC Functions
Connections	IMS systems can connect only to each other. These IMS systems can all reside in one processor, or they can reside in different processors.	Systems connect either like or unlike subsystems, as long as the connected subsystems both implement ISC. You can couple an IMS subsystem to: Another IMS subsystem A CICS subsystem A user-written subsystem
Communication	Message queue to message queue.	Subsystem to subsystem. The subsystems themselves are session partners, supporting logical flows between the applications.
Processing	Processing is transparent to the user. MSC processing appears as if it is occurring in a single system.	Message routing for processing requires involvement by the terminal user or the application to determine the message destination because ISC supports coupling of unlike subsystems. Specified routing parameters can be overridden, modified, or deleted by MFS.
Message routing	MSC routing is performed automatically through system definition parameters or by exit routines (for directed routing). Neither the terminal operator nor any application is concerned with routing.	ISC provides a unique message-switching capability that permits message routing to occur without involvement of a user application.
Distributed conversations	MSC supports the steps of a conversation being distributed over multiple IMS subsystems, transparent to both the source terminal operator and to each conversational step (application).	ISC supports the use of MFS in an IMS subsystem to assist in the routing and formatting of messages between subsystems.
Fast Path Expedited Message Handler (EMH)	MSC does not support the use of the Fast Path EMH.	ISC supports the use of Fast Path EMH between IMS subsystems.

APPC/IMS and LU 6.2 Devices

APPC/IMS is a part of IMS TM that supports the formats and protocols for program-to-program communication. APPC/IMS allows you to use Common Programming Interface Communications (CPI-C) to build CPI application programs. APPC/IMS supports APPC with facilities provided by APPC/MVS.

APPC/VTAM is part of the Communication Server for z/OS and facilitates the implementation of APPC/IMS support. In addition, APPC/MVS works with APPC/VTAM to implement APPC/IMS functions and communication services in a z/OS environment. APPC/IMS takes advantage of this structure and uses APPC/MVS to communicate with LU 6.2 devices. Therefore, all VTAM LU 6.2 devices supported by APPC/MVS can access IMS using LU 6.2 protocols to initiate IMS application programs, or, conversely, be initiated by IMS.

APPC/IMS Application Programming Interfaces IMS supports implicit and explicit application program interfaces (APIs) for APPC support.

• Implicit API for APPC:

  - Supports only a subset of the APPC functions, but enables an APPC incoming message to trigger any standard IMS application that is already defined in the normal manner to IMS, and uses the standard IMS message queue facilities, to schedule the transaction into any appropriate dependent region.

  - Allows the IMS application program to communicate with APPC devices using the same techniques employed with other remote devices.

  - Allows an application program, written by a programmer who has no knowledge of APPC LU 6.2 devices, to:

  • Be started from an APPC LU 6.2 device

  • Receive input messages from originating LU 6.2 devices

  • Send output messages back to originating LU 6.2 devices

  • Start transaction programs on remote LU 6.2 devices

  The same application program can work with all device types, (LU 6.2 and non-LU 6.2) without new or changed coding.

• Explicit APPC/IMS Interface:

  - Supports the complete CPI-C interface. The CPI-C interface is available to any IMS application program. The IMS application program can issue calls to APPC/MVS through this interface. The IMS application program can also use z/OS ATBxxx call services. For information on these call services, see z/OS MVS Programming: Writing Transaction Programs for APPC/MVS.

  - Supports the full set of CPI-C command verbs. IMS applications are written specifically to respond only to APPC-triggered transactions. The standard IMS message queues are not used in this case and the IMS control region helps create only the APPC conversation directly between the APPC client and the IMS dependent region to service this request. The IMS control region takes no further part, regardless of how much time the conversation might use while active.

Related Reading: For more information on APPC/IMS, see IMS Version 9: Administration Guide: Transaction Manager.

IMS Connect

IMS Connect is an optional IMS TM network component that provides high performance communications for IMS between one or more TCP/IP clients (such as IBM WebSphere Application Server for z/OS) and one or more IMS systems. IMS Connect provides the following features:

• Provides commands to manage the communication environment.

• Assists with workload balancing.

• Reduces design and coding efforts for client applications.

• Offers easy access to IMS applications and operations with advanced security and transactional integrity.

As shown in Figure 12-5, IMS Connect enables TCP/IP or local z/OS clients to exchange messages through the IMS OTMA facility or to exchange commands through the IMS Structured Call Interface (SCI) to the IMS Operations Manager (OM).

Figure 12-5. System Overview using IMS Connect

IMS Connect runs in a separate address space.

IMS Connect performs router functions between TCP/IP clients, and local option clients on z/OS with datastores (IMSs) and IMSplex resources. Request messages that are received from TCP/IP clients (using TCP/IP connections) or local option clients (using the z/OS Program Call PC) are passed to a datastore through cross-system coupling facility (XCF) sessions. IMS Connect receives response messages from the datastore and then passes them back to the originating TCP/IP or local option clients.

IMS Connect supports TCP/IP clients communicating with socket calls, but it can also support any TCP/IP client that communicates with a different input data stream format. User-written message exit routines can execute in the IMS Connect address space to convert customer message format to OTMA message format before IMS Connect sends the message to IMS. The user-written message exit routines can also convert OTMA message format to customer message format before sending a message back to IMS Connect. IMS Connect then sends output to the client.

If the datastore goes down, the status of the datastore is sent to IMS Connect from OTMA through XCF. When the datastore is brought back up and restarted, IMS Connect is notified and automatically reconnects to the datastore. You do not need to manually reconnect to the datastore.

In addition to TCP/IP client communications, IMS Connect also supports local communication through the local option, which provides a non-socket (non-TCP/IP) communication protocol for use between IBM WebSphere Application Server for z/OS and IMS Connect in the z/OS environment. Servlets that run in IBM WebSphere Application Server for z/OS and use IMS Connector for Java,^[1] can communicate with IMS Connect through the local option.

^[1] IMS Connect for Java is included in IBM WebSphere Studio Application Developer Integration Edition.

IMS Connect also supports TCP/IP connections from the DB2 UDB V8.1 Control Center to exchange IMS Control Center commands and responses. A single IMS Connect can support communication between the IMS Control Center and any IMS within the sysplex. For more information about the IMS Control Center, see "Operating an IMSplex" on page 499.

Requirement:

To use local option client communications, both IMS Connect and the IBM WebSphere Application Server for z/OS instance where IMS Connector for Java is running must reside in the same z/OS image.

Restriction:

Local option client communications are supported only through IMS Connector for Java and the IMS Connect HWSJAVA0 user message exit.

Related Reading: For the complete details of IMS Connect, see IMS Version 9: IMS Connect Guide and Reference.