MQ Bridge to Mainframe IMS - Acumen ... - Acumen · PDF fileMQ Bridge to Mainframe IMS Using IMSBridge to access Mainframe IMS August 12, 2001 Acumen Advanced Technologies Inc

MQ Bridge to Mainframe IMS Using IMSBridge to access Mainframe IMS

August 12, 2001

Acumen Advanced Technologies Inc.

Using IMSBrdige to access Mainframe IMS

11/21/2002 Copyright © Acumen Advanced Technologies Inc. 2 All rights reserved worldwide

Important Note to Users While every effort has been made to ensure the accuracy of all information in this document, Acumen Advanced Technologies Inc. (ACUMEN) assumes no liability to any party for any loss or damage caused by errors or omissions or by statements of any kind in this document, its updates, supplements, or special editions, whether such errors are omissions or statements resulting from negligence, accident, or any other cause. ACUMEN further assumes no liability arising out of the application or use of any product or system described herein; or any liability for incidental or consequential damages arising from the use of this document. ACUMEN disclaims all warranties regarding the information contained herein, whether expressed, implied or statutory, including, but not limited to, implied warranties of merchantability or fitness for a particular purpose. ACUMEN makes no representation that the interconnection of products in the manner described herein will not infringe on existing or future patent rights, nor do the descriptions contained herein imply the granting or license to make, use or sell equipment constructed in accordance with this description. ACUMEN reserves the right to make changes without further notice to any products herein to improve reliability, function, or design.

© Copyright 2002 Acumen Advanced Technologies Inc. (ACUMEN) All rights reserved worldwide. No part of this publication may be reproduced or transmitted in any form or by any means (graphic, electronic, electrical, mechanical, or chemical, including photocopying, recording in any medium, taping, by any computer or information storage and retrieval systems, etc.) without prior permission in writing from ACUMEN.



TABLE OF CONTENTS

1 INTRODUCTION ................................................................................................................................ 3 2 MQ SERIES.......................................................................................................................................... 3

2.1 MESSAGES....................................................................................................................................... 3 2.2 QUEUE MANAGER ........................................................................................................................... 3 2.3 MQSERIES OBJECTS........................................................................................................................ 3

2.3.1 Queues .................................................................................................................................... 3 2.3.2 Channels ................................................................................................................................. 3

2.3.2.1 Message Channel ............................................................................................................................... 3 2.3.2.2 MQI channel ...................................................................................................................................... 3

2.3.3 Process Definitions................................................................................................................. 3 2.4 CLIENTS AND SERVERS ................................................................................................................... 3

2.4.1 MQSeries client ...................................................................................................................... 3 2.4.2 MQSeries server ..................................................................................................................... 3 2.4.3 Leaf node ................................................................................................................................ 3

2.5 HOW MQ WORKS............................................................................................................................ 3 2.6 COMMUNICATION BETWEEN QUEUE MANAGERS............................................................................ 3

3 IMS BRIDGE........................................................................................................................................ 3 3.1 OTMA ............................................................................................................................................ 3 3.2 THE IMS BRIDGE ............................................................................................................................ 3

4 IMS MESSAGE FORMAT ................................................................................................................. 3 4.1 IMS GENERAL MESSAGE FORMAT.................................................................................................. 3 4.2 PROCESSING OF INPUT AND OUTPUT IN IMS ................................................................................... 3



TABLE OF FIGURES

Figure 1: MQ Series at Runtime...................................................................................................... 3 Figure 2: Program-to-Program Communication in One System ..................................................... 3 Figure 3: Program-to-Program Communication in Two Systems.................................................... 3 Figure 4: MQSeries Channels ......................................................................................................... 3 Figure 5: MQSeries Parts and Logic ............................................................................................... 3 Figure 6: Communication Between Two Queue Managers ............................................................ 3 Figure 7: Access to IMS .................................................................................................................. 3 Figure 8: IMS Standard Triggering with MQSeries.......................................................................... 3 Figure 9: Transmission, Message and Segment in IMS.................................................................. 3 Figure 10: IMS Message Segment.................................................................................................. 3 Figure 11: Formatting Input by MFS................................................................................................ 3



1 INTRODUCTION It is repeatedly recorded that 90% of the business data is still stored on the mainframe systems worldwide. Aside form that; there is still significant amount of business service that is also still hosted on the mainframe systems worldwide. It took sometime for the data processing community to realize that in an open system era it is neither smart nor required to change any of this to be able to share mainframe systems with their magnificent amount of data and service in WWW. Mainframes are now very much considered as happy constituents of the open system land. This document briefly examines only one of the ways that services of an application system resident on an IBM mainframe could be invoked by an open system agent. In particular it examines the ability to invoke IMS transactions remotely.

A very popular method to connect applications running on open systems to the IMS based applications running under OS/390 environment is through the use of MQSeries IMS Bridge. There are several advantages in considering this technology, among which we could articulate the following:

• It is a solid and proven technology.

• This technology is known to the most of the operational staff in a large enterprise.

• There are components of this technology that may be of some use either directly (by reusing the implementation) or indirectly (by following a similar design).

This document provides some background information that is required to understand the resulting solution. It also provides a high-level overview of the MQSeries / IMS Bridge connection as well as an overview of message processing and formatting in IMS.



2 MQ SERIES MQSeries is IBM’s middleware for commercial messaging and queuing. It runs on a variety of platforms. The MQSeries products enable programs to communicate with each other across a network of unlike components, such as processors, subsystems, operating systems and communication protocols. MQSeries programs use a consistent application program interface (API) across all platforms.

Application Program

MQ

MQ

I

Network

Application Program

MQ

MQ

I

MQ Objects

Figure 1: MQ Series at Runtime

Figure 1 shows the parts of an MQSeries application at runtime. Programs use MQSeries API calls, which are the message queue interface (MQI), to communicate with a queue manager (MQM), the runtime program of MQSeries. For the queue manager to do its work, it refers to objects, such as queues and channels. The queue manager itself is an object as well.

MQSeries is used in a client/server or distributed environment. Programs belonging to an application can run in one workstation or in different machines on different platforms.



Message queuing is a method of program-to-program communication. Programs within an application communicate by writing and retrieving application-specific data messages) to/from queues, without having a private, dedicated, logical connection to link them. Messaging means that programs communicate with each other by sending data in messages and not by calling each other directly. Queuing means that programs communicate through queues. Programs communicating through queues need not be executed concurrently. With asynchronous messaging, the sending program proceeds with its own processing without waiting for a reply to its message. In contrast, synchronous messaging waits for the reply before it resumes processing.

This section briefly introduces the components in the MQSeries system.

2.1 Messages A message consists of two parts: data that is sent from one program to another and a message descriptor. The message descriptor identifies the message (message ID) and contains control information, also called attributes, such as message type, expiry time, correlation ID, priority, and the name of the queue for the reply. In MQSeries Version 5, the maximum message length is 100 MB. Messages can be segmented and grouped.

MQSeries knows four types of messages:

• Datagram A message containing information for which no response is expected.

• Request A message for which a reply is requested.

• Reply A reply to a request message.

• Report A message that describes an event such as the occurrence of an error.

Application design determines whether a message must reach its destination under any circumstances, or if it can be discarded when it cannot get there in time. MQSeries knows persistent and non-persistent messages. Delivery of persistent messages is assured. They are written to logs on a hard drive and survive system failures. Non-persistent messages cannot be recovered after a system restart.

2.2 Queue Manager The heart of MQSeries is its run-time program, the queue manager (MQM). Its job is to manage queues of messages. Application programs invoke functions of the queue manager by issuing API calls. For example, the MQPUT API puts a message on a queue to be read by another program using the MQGET API. This scenario is shown in Figure 2.



Application Program A

PUT to Q1

Application Program B

GET from Q1

Message Q Q1

Messages

Figure 2: Program-to-Program Communication in One System

A program may send messages to another program that runs in the same machine as the queue manager, or to a program that runs in a remote system, such as a server or a host. The remote system has its own queue manager with its own queues. This scenario is shown in Figure 3.

Application Program A

PUT to Q1

Channel

Application Program B

GET from Q1

Message Q Q1 Message Q Q1

Messages

Figure 3: Program-to-Program Communication in Two Systems

Application programmers do not need to know where the program to which they are sending messages runs. They put their message on a queue and let the queue manager worry about the destination machine and how to get it there.

For the queue manager to do its work, it refers to objects that are defined by an administrator, usually when the queue manager is created or when a new application is added. The objects are described in the next section. The functions of a queue manager can be defined as follows:

• It manages queues of messages for application programs.



• It provides an application-programming interface, the Message Queue Interface (MQI).1

• It uses networking facilities to transfer messages to another queue manager when necessary.

• It provides additional functions that allow administrators to create and delete queues, alter the properties of existing queues, and control the operation of the queue manager. These functions are invoked through the utility RUNMQSC, which stands for run MQSeries commands.

MQSeries clients do not have a queue manager of their own. Client machines connect to a queue manager in a server. This MQM manages the queues for all clients attached to it.2

2.3 MQSeries Objects This section provides an overview of the queue manager objects, such as queues and channels. The queue manager itself is also an object. Usually, an administrator creates one or more queue mangers and their objects. A queue manager can own objects of the following types:

• Queues

• Process definitions

• Channels

The objects are common across different MQSeries platforms. There are other objects that apply to MVS systems only, such as the buffer pool, PSID, and storage class.

2.3.1 Queues Message queues are used to store messages sent by programs. There are local queues that are owned by the local queue manager, and remote queues that belong to a different queue manager.

2.3.2 Channels Messages are transmitted via channels. A channel is a logical communication link. In MQSeries, there are two different kinds of channels: Message channel and MQI Channel.

To transmit non-persistent messages, a message channel can run with two speeds: fast and normal. Fast channels improve performance, but messages are lost if there is a channel failure.

1 The IBM Networking Blueprint identifies three communication styles: Common Programming Interface – Communications (CPI-C), Remote Procedure Call (RPC), Message Queue Interface (MQI). 2 In contrast to MQSeries clients, each workstation that runs MQSeries for Windows has its own queue manager and queues. MQSeries for Windows has a single-user queue manager and is not intended to function as a queue manager for other MQSeries clients.



A channel can use one of the following transport types:

• SNA LU 6.2

• TCP/IP

• NetBIOS

• SPX

2.3.2.1 Message Channel A message channel connects two queue managers via message channel agents (MQA). Such a channel is unidirectional. It comprises two message channel agents (MCA), a sender and a receiver, and a communication protocol. An MCA is a program that transfers messages from a transmission queue to a communication link or vice versa. For bi-directional messaging it is necessary to define two channels, a sender channel and a receiver channel.

2.3.2.2 MQI channel A Message Queue Interface (MQI) channel connects an MQI client to a queue manager in a server machine. MQI clients don’t have a queue manager of their own. An MQI channel is bi-directional. Figure 4 on page 3 shows the use of both channel types.

2.3.3 Process Definitions A process definition object defines an application to a queue manager. For example, it contains the name of the program to trigger when a message arrives.3

2.4 Clients and Servers MQSeries distinguishes clients and servers. Before the installation of MQSeries it has to be decided whether the workstation will be an MQSeries client, an MQSeries server, or both. With MQSeries for Windows a new term was introduced, the leaf node (description follows). There are two kinds of clients:

• Slim client or MQSeries client

• Fat client

Fat clients have a local queue manager; slim clients don’t. When a slim client cannot connect to its server it cannot work, because queue manager and queues for a slim client reside in the server. Usually, an MQSeries client is a slim client. Several of these clients share MQSeries objects, and the queue manager is one of them, in the server they are attached to.4

In some cases it may be advantageous to have queues in the end user’s workstation, especially in a mobile environment. That would allow the application to continue execution even when a connection between client and server does not (temporarily)

3 With MQSeries Version 5, process definitions for channels have been eliminated. 4 The MQSeries Client for Java is a slim client.



exist. It is possible to install client and server software in the same system and use it as an end user’s workstation.

The difference between an end user’s workstation that is a client and one that has a queue manager is the way messages are sent. The queues reside either in the end user’s workstation or in the server.

MQIClient

MQIClient

MQ SeriesQueue Manager

MQ SeriesQueue ManagerMQI Channels

Message

Channels

Figure 4: MQSeries Channels

Figure 4 shows the use of MQI and message channels. As illustrated, MQI channels connect clients to a queue manager in a server machine. All MQSeries objects for the client reside in the server. MQI channels are faster than message channels. A message channel connects a queue manager to another queue manager in another system.

The following provides a brief account of the three workstation types.

2.4.1 MQSeries client A client workstation does not have a queue manager of its own. It shares a queue manager in a server with other clients. All MQSeries objects, such as queues, are in the server. Since the connection between client and server is synchronous, the application cannot work when the communication is broken. One could refer to such workstations as “slim” clients.

2.4.2 MQSeries server An MQSeries server is a workstation that can be a client and a server. A server is an intermediate node between other nodes. It serves clients that have no queue manager and manages the message flow between its clients, itself and other servers. In addition to the server software it is possible to install the client software, too. This configuration is used in an application development environment.



Network

Program 1 MQI

RemoteQ

Put

ChannelInit Q

XmitQ

ChannelInitiatorMonitor

MCA Start

ChannelA.TO.BSender

ChannelA.TO.B

Receiver

MCA

Start

LocalQ

ChannelInit Q

TriggerMonitorMonitor

Program 2 MQIGet

Message

Start

Listener

Figure 5: MQSeries Parts and Logic

2.4.3 Leaf node MQSeries for Windows was designed for use by a single user. It has its own “small footprint” queue manager with its own objects. However, it is not an intermediate node between other nodes. It is called a leaf node. One could also refer to it as a “fat” client.

This product is able to queue outbound messages when connection to a server or host is not available, and inbound messages when the appropriate application is not active.



2.5 How MQ Works Figure 5 elucidates the parts and architecture of MQSeries. The application program uses the Message Queue Interface (MQI) to communicate with the queue manager.

The queuing system consists of the following parts:

• Queue Manager (MQM)

• Listener

• Trigger Monitor

• Channel Initiator

• Message Channel Agent (MCA)

When the application program wants to put a message on a queue it issues an MQPUT API. This invokes the MQI. The queue manager checks if the queue referenced in the MQPUT is local or remote. If it is a remote queue, the message is placed into the transmission (xmit) queue. The queue manager adds a header that contains information from the remote queue definition, such as destination queue manager name and destination queue name.

Each remote queue must be associated with an xmit queue. Usually, all messages destined for one remote machine use the same xmit queue.

Transmission is done via channels. Channels can be started manually or automatically. To start a channel automatically, the xmit queue must be associated with a channel initiation queue. Figure 5 on page 3 shows that the queue manager puts a message into the xmit queue and another message into the channel initiation queue. The channel initiator monitors this queue.

The channel initiator is an MQSeries program that must be running in order to monitor initiation queues. When the channel initiator detects a message in the initiation queue, it starts the message channel agent (MCA) for the particular channel. This program moves the message over the network to the other machine, using the sender part of the unidirectional message channel pair.

On the receiving end, a listener program must have been started. The listener, also supplied with MQSeries, monitors a specified port, by default the port dedicated to MQSeries, 1414. When a message arrives, it starts the message channel agent. The MCA moves the message into the specified local queue using the receiver part of the message channel pair.5

5 Both channel definitions, sender and receiver, must have the same name. For the reply, another message channel pair is needed.



The program that processes the incoming message can be started manually or automatically. To start the program automatically, an initiation queue and a process must be associated with the local queue, and the trigger monitor must be running.

When the program shall start automatically, the MCA puts the incoming message into the local queue and a trigger message into the initiation queue. The trigger monitor monitors this queue. This program invokes the application program specified in the process definition. The application issues an MQGET API to retrieve the message from the local queue.

This scenario is described in more detail in the next section.

2.6 Communication Between Queue Managers This section provides a description on how to send messages to a queue manager that resides in another system. For this purpose message channels for communication between queue managers are used (see Figure 4 on page 3).

Program 1

RemoteQ1Put

Xmit QA.TO.B

ChannelA to BSender

Net

wor

k

ChannelA to B

Receiver

Local Q1

Program 1

Get

RemoteQ2 Put

ChannelB to ASender

Xmit QB.TO.A

ChannelB to A

Receiver

Local Q2Get

Figure 6: Communication Between Two Queue Managers

Each machine has a queue manager installed and each queue manager manages several local queues. Messages destined for a remote queue manager are put into a remote queue. A remote queue is not a real queue; it is the definition of a local queue in the remote machine. A remote queue is associated with a



transmission (xmit) queue, which is a local queue. Usually, there is one xmit queue for each remote queue manager.

A transmission queue is associated with a message channel. Message channels are unidirectional, meaning that it is necessary to define two channels for a conversational type of communication. Also, it is necessary to define each channel twice, once in the system that sends the message (sender channel) and once in the system that receives the message (receiver channel). Each channel pair (sender and receiver) must have the same name.



3 IMS BRIDGE IMS Bridge is the MQSeries adaptor to IMS environment on MVS. This section describes briefly how MQSeries based applications could share data and processing with IMS legacy applications through the IMS Bridge.

3.1 OTMA IMS Bridge is an implementation of the IMS Open Transaction Manager Access (OTMA) protocol. OTMA is a transaction-based, connectionless client/server protocol. Though easily generalized, its implementation is specific to IMS in an MVS Sysplex environment. OTMA provides the capability of connecting clients that have to support a large network (or large number of sessions) to an IMS server, while maintaining high performance.

In more precise terms, OTMA could correspond to the OSI transport and session layers. As such, OTMA rides on top of a more common networking protocol that is called Cross System Coupling Facility (XCF). XCF is a communication protocol that allows two different MVS applications to communicate. The two applications can stay on different

MVS systems provided those MVS systems belong to the same Sysplex (that means they can communicate over XCF).

Through OTMA, clients can send transactions to IMS and receive output from IMS applications or IMS itself. IMS supports access to the IMS Queue from VTAM by means of the so-called Device Dependent Modules (DDM). There is one DDM for every LU type that IMS supports.

OTMA carries on an extension, or prefix, that contains some information that must be supplied together with the IMS transaction code and the IMS user data.

In high-level terms this prefix contains information such as:

• The user ID that originated the transaction.

• The Tpipe, which correspond to the IMS LTERM. In contrast to LTERM, Tpipes do not need to be assigned in IMS, as they are automatically allocated.



• The type of the message, such as IMS command or IMS transaction.

• A variable portion of user data, that is usually used by the client to correlate output and input. For example, an OTMA client could store here the IP address of the message originator. The OTMA prefix will again be available to the client when the IMS response comes back. So the client will be able to remember to what IP address the output has to be sent.

MVS Sysplex

IMS (Server)

OTMA

DeviceSupport

Client

DeviceSupport

VTAM

XCF

Device

Figure 7: Access to IMS

Among others OTMA could provide the following benefits to the applications requiring cross processing and data sharing with IMS applications:

• Existing IMS applications can run without modification and interact with OTMA clients.



• An OTMA client can submit an IMS transaction and issue commands.

• Messages that go through OTMA can have an extension in the User Data Section of the message prefix. This allows the client to correlate the input with the output.

• An OTMA client can implement functions that IMS does not provide.

• OTMA is out of the scope of a traditional COBOL programmer.

It has to be noted that it is the ultimate responsibility of the client application to deliver the output to the originating end user. IMS cannot deliver it, as it is only aware of the client.

Figure 7 shows, in general, the access to IMS. It is possible to access IMS from a device through VTAM. In this case OTMA is not involved. From the same device however, it is also possible to go through a client that exploits OTMA. In this case, the device is supported by the client that converses with IMS through OTMA.

3.2 The IMS Bridge The IMS Bridge has been the first implementation of OTMA; that is, the IMS

Bridge is MQSeries OTMA support. It is part of MQSeries for MVS/ESA 1.1.4 and higher versions.

MQSeries for MVS/ESA behaves like the client side of an OTMA connection. It allows any MQI application to integrate IMS transactions. Unlike native OTMA, the IMS Bridge is simple to use.

Theoretically, the application programmer does not require knowledge of the OTMA protocol, even though he may build the OTMA header. He could ignore the header or, in the end-user application, place it in the MQSeries message. If it is not there, the IMS Bridge uses defaults.

IMS and MQSeries have interfaced since the first release of MQSeries for MVS/ESA (1993), through the so-called IMS adapter. The IMS adapter allows an IMS application to issue MQI verbs, such as MQCONN, MQGET and MQPUT.

An IMS application can be started through the MQSeries trigger service. This means that an IMS MPP program can be triggered when an MQSeries message arrives at a queue that is intended to be served by IMS. The standard trigger mechanism through an Initiation Queue applies.



Figure 8 on 3 summarizes the (traditional MQSeries) trigger process of an IMS transaction through the standard trigger mechanism.

With the IMS Bridge, an IMS application can get and put messages to an MQSeries queue without using explicit MQI verbs. Note that the IMS Bridge is an OTMA implementation. When a generic MQ application sends a message to the MQ queue that is targeted for IMS, the IMS Bridge puts that message into the IMS message queue, and IMS can schedule the application. The original message should always contain the return address, that is the ReplyTo information in the Message Descriptor. The IMS application can get the incoming message through the standard IMS interface (GU IOPCB). OTMA and IMS take care of the “triggering” and getting the message to the IMS application. The IMS application produces its output through the standard IMS interface (ISTR IOPCB).

The IMS Bridge (and OTMA) maps the IMS outgoing message to a MQSeries message that is sent to the ReplyToQ and ReplyToQMgr specified in the incoming message. The originating generic MQ application can retrieve the response from IMS with an MQGET call.

Any MQIApplication

...MQPUT

MQGET

IMSApplication

MQGET

MQGET

GU IOPCB

PerformApplication

Logic

ISRT IMSTx

MQGET

IMS TriggerMonitor

IMS Serv

Request Queue(triggered)

Initiation Queue

Reply Queue

Figure 8: IMS Standard Triggering with MQSeries

The IMS Bridge introduces implicit MQI support. This means that any application can interact with an IMS application issuing MQI verbs. The IMS Bridge maps the MQSeries message to an



incoming IMS message and again it maps the outgoing IMS message to an MQSeries queue.

The IMS application is not aware that the partner is an MQI application. To be more precise, the IMS application is not aware that the transaction has been entered through OTMA. The same IMS transaction could have been scheduled either from an old 3270 terminal or from an MQI application in a client/server environment.

In summary, the IMS Bridge, that is part of MQSeries for MVS/ESA, behaves like an OTMA client. This means that it communicates to IMS OTMA through the XCF interface.



4 IMS MESSAGE FORMAT

4.1 IMS General Message Format The input and output to the IMS System is in the form of messages, regardless of the target or the destination of the message (physical terminal or application program). IMS upon receiving these messages, process them asynchronously. As the result, IMS will not always send a reply immediately, or sometimes ever, when it receives a message. It may however from time to time send unsolicited messages to certain destinations.

IMS messages are of four types:

• Transactions — the data in these messages is passed to IMS application programs for processing

• Messages to go to another logical destination (network terminals, etc.)

• Commands for IMS to process

• Messages for the IMS APPC feature to process.

If IMS is not able to process an input message immediately, or cannot send an output message immediately, then the message is stored on a message queue external to the IMS system. IMS will not normally delete the message from the message queue until it has received confirmation that an application has processed the message, or it has reached its destination.

The main component of the IMS System, the IMS Transaction Manager (IMS/TM) is the IMS component that is responsible for processing inputs; calling IMS applications and queuing the results back to the IMS queue. As mentioned above all the inputs and outputs from IMS/TM are in the form of messages. A message, in the most general sense, is a sequence of transmitted symbols. In the context of IMS, this is called a transmission. A transmission may have one or more messages, and a message may have one or more segments. A segment is



defined by an end-of-segment (EOS) symbol; a message6 is defined by end-of-message (EOM) symbol; and a transmission is defined as an end-of-data (EOD) symbol.

SegmentEO

SSegment

EOM

Segment

EOS

Segment

EOS

Segment

EOM

Segment

EOS

Segment

EOD

Figure 9: Transmission, Message and Segment in IMS

In Figure 9 there are three messages and seven segments in one transmission.

On the input side the character values and the cardinality of segments and messages per message and transmission is dependent on the device. In a 3270-type device, there is one segment per message and one message per transmission. On the output side also it is possible to combine multiple segments and messages per transmission. In such a case, another IMS based facility would take control over transmitting the messages to the appropriate destinations.

LL ZZ TranCode Datablank

Figure 10: IMS Message Segment

Each segment within a message has a certain format in IMS as illustrated in Figure 10. The following describes the sections in a message segment:

• LL contains the total length of the segment in bytes, including the LL and ZZ fields. The size of this field is 2 bytes.

• ZZ is an IMS system field. The size of this field is 2 bytes.

• Data is the application data, which includes the transaction code.

6 Not to be confused by the general term “message”. A message in this context is a part of a bigger component that is called a transmission.



4.2 Processing of Input and Output in IMS One design goal of IMS system has been to decouple the IMS applications from the input and output formats and destinations. IMS applications are triggered by IMS/TM and use IMS Data Language APIs, called DL/1, to acquire input message from and place their output in the IMS queues. IMS transactions acquire their input from an IMS queue called TRANS and place their output in an IMS queue called LTERM (for Logical Terminal). They perform these activities through DL/1 commands. As the result of this design, the IMS transactions only communicate with an IMS queue depending on the type of their activity (input or output). To achieve this design goal, IMS uses a facility called Message Formatter Service (MFS).

MFS receives all the messages before they are queued in TRANS. It performs validation and formatting on the input messages received before queuing them in TRANS. On the output side, MFS also provides formatting prior to making the output available to the recipient. For example, in the case of a large result set produced by an IMS transaction that is to be displayed on a 3270 terminal, MFS has to break down the result set in sizable parts so it could be handled by the output terminal. The processing of the output in this fashion by MFS is being performed totally outside of the execution of the IMS transaction originating the output.7

F1: AA F2: B F3:

F4: CCCC

F5: DDD

3270 Terminal Screen

DIF

DFLD1

DFLD2

DFLD3

DFLD4

DFLD5

MID

MFLD1

MFLD2

MFLD3

MFLD4

MFLD5

LL ZZ AA B CCCCDDD

MSGFLD 1 2 3 4 5

Device

MFS

Program

Figure 11: Formatting Input by MFS

7 In this fashion, the combination of IMS transaction, MFS and the output device are following the Model/View/Controller pattern.



To format message input and output, MFS uses a format metadata that is referred to as control blocks. MFS control blocks are of four types as follows:

1. Message Input Descriptor (MID)

2. Message Output Descriptor (MOD)

3. Device Input Format (DIF)

4. Device Output Format (DOF)

The MID contains a list of message descriptor fields (MFLDs) which define the layout of the input segment as is to be seen by an application program. The IDF contains a list of device descriptor fields (DFLDs) which define what data is to be expected from which part of the device (that is, location on the screen). MFS maps the data of the DFLDs into the corresponding MFLDs.

Each 3270 terminal input screen is formatted according to a DIF. MFLD statements are to define:

• The device fields (DFLDs) defined in the DIF which contents will be included in the message presented to the application program.

• Constants, defined as literals to be included in the message: a common use of literals is to specify the transaction code.

In addition, the MFLD statement defines:

• The length of the field expected by the application program.

• Left or right justification and the fill character to be used for padding the data received from the device.

• A ‘nodata’ literal for the MFLD if the corresponding DFLD does not contain any input data.

Similar to input processing, MFS uses formatting blocks, MOD and DOF, for out put messages. The control blocks in the output messages, similar to DIF and MOD contain field descriptors with similar information. Obviously the flow is opposite to the one of the input formatting process.

However, one important aspect that is unique to the output processing is the notion of logical paging in the output messages. As indicated above, an IMS transaction may produce a large result set that could not be displayed by the recipient device. By the means of logical pages and device pages in MOD and DOF, MFS can break down the result set before sending it to its target. Logical paging is the way output message descriptor is defined with one or more LPAGE statements. Each LPAGE statement relates a segment produced by an application program to corresponding device page. Using logical paging, the



simplest message definition consists of one LPAGE and one segment description.

Most of IMS application use MFS to format input and output. An open system agent communicating with the legacy application has to use these control blocks so it can send messages that could be processed by IMS applications and read messages that are received from these applications. The intent is to externalize the message formatting from the code that performs the format. To do this all the MIDs and MODs are prepared as XML tagged data. The format application will parse the XML files to reach to the MID and MOD related information. As the result of this, the code that performs formatting could stay generic.

Documents

MQ Bridge to Mainframe IMS - Acumen ... - Acumen · PDF fileMQ Bridge to Mainframe IMS Using IMSBridge to access Mainframe IMS August 12, 2001 Acumen Advanced Technologies Inc