Introduction

With the ITP Mainframe Connection, you retrieve data from a mainframe for Models that run on an OS/2 or Microsoft Windows client. With the ITP/SDK MultiPlatform, you can create the DIDs for the Mainframe Connection. Data Retrieval during Run Model is performed through programs, modules or routines on the Mainframe.

Connectivity in the ITP Mainframe Connection is established by using the CPI-C API (the standard CPI-C API of OS/2 or the WINCPIC API of Windows that for example is implemented by the Rumba APPC Client) or through MQSeries over a TCP/IP connection.

When running an ITP-model, ITP will have to start the corresponding entry-program for every entry in the model (e.g., a IMS or CICS program).

MQSeries

When ITP encounters an entry during Run Model it orders its local Client Data Manager to send a transaction request via MQSeries to the Host Data Manager. The Host Data Manager receives the request and starts the actual Data Retrieval Program, module or routine. The Data Retrieval Program sends the results to the Host Data Manager, which in turn sends the results back to the Client Data Manager on the PC.

The MQSeries Mainframe Connection uses three MQSeries message queues; a request queues, a reply model queue and the actual reply queues. All requests of all clients are placed in a single request queue. The Host DataManager reads from this queue and handles all requests in turn. Replies are stored in a queue that is private to each client. Each client creates this queue dynamically from a model queue at the moment it issues its first request.

For every entry that is used in an ITP model a separate pair of request-answer messages is used. The queues however, are ordinarily reused for multiple requests. By default the client keeps the connection to the host (and the corresponding message queues) open, for as long as its Client Data Manager is running and uses the same connection settings. Specifying a different Disconnect option can change this behavior. As soon as a client closes the connection it will also remove its private reply queue.

CPI-C

For the CPI-C interface, starting an entry-program means starting a transaction, which then plays the role of ITP Host DataManager. This transaction program is activated and supplied input to by using CPI-C. Using CPI-C sends the output (result record(s) for use by ITP) to the Client, also.

The input for the ITP Host DataManager consists of the name of the entry-program concerned (or a code that identifies this program to be executed) and the key-values for the corresponding entry-program. Depending on these input-values the transaction program will activate the program (module or routine) concerned. Next, this program retrieves the actual data and sends it back.

For every entry that is used in an ITP-model a separate CPI-C conversation is established for the transaction program mentioned before. When an ITP-model uses 5 entries, there also will be 5 CPI-C conversations activated.

When using the implicit CPI-C API in the IMS environment, the ITP Host DataManager can be implemented as a regular transaction program.

An additional option is available to register that per model only one CPI-C conversation must be activated for every entry in the ITP-model concerned (several communication-actions using one conversation). With this option you get a trade-off between performance and network-load). In IMS this option means you cannot use the implicit CPI-C API.

The ITP Client DataManager communicates with both implementation options stated before.

Implementation

Because of the differences in Mainframe environments the implementation of the ITP Host DataManager is done on a per customer basis. The implementation is performed in a joint project between the customer and Aia. You will receive the full ITP Host DataManager specification when you purchase the ITP Mainframe Connection.