Skip to main content
    United States [change]      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     
  TPF : Library : Newsletters

New TCP/IP Middleware

Dan Yee, IBM TPF Development

Now that TPF Transmission Protocol/Internet Protocol (TCP/IP) support is being used by more and more TPF customers, we have noticed a need for additional TCP/IP middleware code to take advantage of this popular communications protocol. Program update tape (PUT) 10 helps to fill that need by providing both Mapping of Airline Traffic over Internet Protocol (MATIP) and IP Bridge support. This article describes both of these enhancements and will help you to decide whether you should install them on your TPF system.

MATIP Background

When airlines first started building their communications networks in the 1960s and 1970s, they used protocols such as Airline Line Control (ALC) and Synchronous Link Control (SLC) to send messages through their networks. Today, airlines use Airline X.25 (AX.25) and Synchronous Data Link Control (SDLC) protocols in addition to ALC and SLC to send messages through both Systems Network Architecture (SNA) networks and non-SNA networks. However, with these types of networks there is the problem of hardware components that are no longer supported by the original manufacturer. In addition, software written to handle the legacy ALC and SLC protocols is old and difficult to maintain and upgrade. Currently, airlines are starting to implement new TCP/IP applications to transmit messages through their networks while legacy applications remain to handle ALC, SLC, and AX.25 traffic. The airlines would like to remove some of the old hardware and software from their networks and use TCP/IP as the standard protocol for communication in their computer networks. As a result, MATIP was developed as a common standard by the Societe Internationale de Telecommunications Aeronautiques (SITA) in Paris, France and by major airline system vendors to enable airlines to migrate their legacy systems to a TCP/IP network. The standard was accepted by the Internet Engineering Task Force (IETF) and was assigned Request for Comments (RFC) 2351.

Newsletter Article Illustration

MATIP Architecture

The MATIP RFC defines the following three types of message traffic flow:

  • Type-A conversational
  • Type-A host-to-host
  • Type B.

Type-A conversational sessions typically consist of high-priority, low-integrity message traffic between terminals and other host airline systems.

Type-A host-to-host sessions consist of high-priority, low-integrity message traffic between two host airline systems.

Type-B sessions consist of low-priority, high-integrity message traffic between two host airline systems.

The MATIP RFC states that a host or terminal can initiate a session by building a session open control packet with appropriate routing information included in the packet. The recipient can confirm or reject the session open request and, if the request is confirmed, both sides can exchange data packets with the length of each packet included in a header attached to the packet. At any point during the session, either side can send a control packet to close the session.

Of all the MATIP session types, Type-A conversational is the most complex type because a list of agent set control units (ASCUs) can be included in the session open request. An ASCU is a term used in the airline industry for a concentrator that is associated with a group of remote terminals. By including a group of ASCUs in each MATIP session open request, the client that initiates the session can reduce the number of sockets that need to be opened for Type-A sessions, thus enabling multiplexing or multiple traffic flows to occur within the same session.

TPF MATIP Implementation

The TPF implementation of MATIP for PUT 10 is based on the SITA RFC and includes Type-A conversational, Type A host-to-host, and limited Type-B support. As part of this implementation, the TPF system will support session open requests sent from IBM Advanced Application Communication Systems/2 (A2CS) workstations with their own MATIP support installed. A2CS workstations serve as a gateway for other ASCUs, which may have IBM Advanced Communications Systems Access (ACSA) software installed on the associated terminals. These terminals are able to start a session with TPF and transmit data messages in ALC format to an A2CS workstation, which attaches a MATIP header to each of the data messages. The A2CS workstation then forwards the messages to TPF across an IP network. As a server, the TPF system can accept or reject session open requests from another client, indicate to the client that a list of ASCUs passed to it is incorrect, and send a corrected list of ASCUs back to the client.

Newsletter Article Illustration

In a Type-A conversational session, the TPF system will typically be a server to accept session open requests from another MATIP client, such as an A2CS workstation. TPF can also be the client in Type-A host-to-host and Type-B sessions. In these sessions, TPF sends an open confirm control packet to the server to indicate that it either accepts or rejects the session open request. The TPF system can then start sending data packets to the server with the length of each packet included in a header at the beginning of each packet. Like Type-A conversational sessions, TPF can also function as a server in Type-A host-to-host and Type-B sessions.

The TPF MATIP code sits above the TPF TCP/IP socket layer and below the TPF application layer and, therefore, is classified as TCP/IP middleware code. As middleware code, it intercepts ROUTC macros issued by TPF applications, converts them to send() socket application programming interface (API) function calls, and transmits the messages across an IP network. It also issues socket(), bind(), and connect() socket API function calls to start MATIP sessions and activate_on_receipt_with_length() and read() socket API function calls to read data.

MATIP Customization

To use MATIP in your TPF system, you must do a certain amount of customization. The amount of customization depends on whether your application programs issue ROUTC macros to send messages to their destination and whether the Router Control Parameter List (RCPL) associated with the ROUTC macro contains the line number, interchange address, and terminal address (LNIATA) of the destination of the message. If your application does not issue a ROUTC macro and does not include an LNIATA in the RCPL when sending a message, either additional customization is needed or the TPF system will not be able to send the message through MATIP. Because Type-B message processing includes additional application code to secure the message on input and output, and also may not use LNIATAs during outbound processing, more customization may be needed for Type-B messages. In that sense, TPF MATIP support of Type-B messages is limited at this time.

To help you customize your system to use MATIP, the ZMATP functional message and seven user exits are provided. The MAXASCU and MAXMATIP keywords have also been added to the ZNKEY functional message to enable you to define the maximum number of ASCUs that will be associated with MATIP and the maximum number of MATIP sessions that can be open at one time on your TPF system.

The ZMATP functional message with the DEFINE parameter specified enables you to associate an LNIATA with an IP address and MATIP session type (Type-A conversational, Type-A host-to-host, and Type B) so that the TPF system can start a session with another client. When your application program issues a ROUTC macro, TPF intercepts the ROUTC macro in its service routine, starts a new MATIP session if necessary, removes the application message format (AMSG) header, brings any chained message blocks on file into core (working storage), and issues a send() socket API function call to send the entire message across an IP network. To comply with the MATIP RFC, TPF attaches a header that includes the length of the data packet before TPF sends out the packet to the network. If TPF needs to create a new session, it uses the IP address provided by the ZMATP functional message to issue a connect() socket API function call and uses the session type to determine the type of MATIP session that needs to be created. The Session Start user exit enables you to define specific MATIP characteristics for the session, and the Translation user exit enables you to add code to translate your message before it is sent by TPF and also to translate messages received by TPF.

The Security user exit must be modified to enable the TPF system to accept session open requests from other MATIP clients. For Type-A conversational sessions, it must be able to recognize a list of valid ASCUs sent from the client during the opening of a new session and modify the list, if necessary, if one or more of the ASCUs is not correct for that session.

The ASCU List user exit must be used for Type-A conversational sessions when the TPF system is attempting to confirm a session open from a client and the client did not provide a list of ASCUs in the request. You can define a list of ASCUs in the user exit so that TPF can send that list back to the client when it confirms the session. This user exit must be used for sessions with A2CS and ACSA workstations because the A2CS software does not provide a list of ASCUs when it attempts to open a session with another host.

The Assign LNIATA user exit must be used for Type-A host-to-host and Type-B sessions to assign an LNIATA to each incoming message. For Type-A conversational sessions, this user exit must be used if 4-byte ASCUs are included in the session instead of 2-byte ASCUs. The TPF system needs the LNIATA to obtain the application name table index from the terminal control table (WGTA) entry of the LNIATA and to route the message to the appropriate application. If an LNIATA is not assigned to the message, the message is passed to the Router user exit so that the TPF application can determine where to route the message.

Starting MATIP

To define your Type-A MATIP server, enter the following:


To define your Type-B MATIP server, enter the following:


If you are in 1052 state, enter ZCYCL CRAS or ZCYCL NORM and the servers will start automatically on reaching CRAS state or NORM state, as long as your Common Link Access to Workstation (CLAW) protocol devices are connected. If you are in CRAS state or NORM state, enter the ZMATP functional message with the START parameter specified to start the MATIP servers. Use the ZMATP functional message with the STOP parameter specified to stop your MATIP servers after they have been started.

IP Bridge Support

IP Bridge support is TCP/IP middleware code that was designed and developed by the TPF lab and is not associated with the MATIP support that was described previously. However, the architecture of the support is very similar to MATIP. Like MATIP, IP Bridge support intercepts ROUTC macros issued by TPF applications, converts them to send() socket API function calls, and transmits the messages across an IP network. IP Bridge support also issues socket(), bind(), and connect() socket API function calls to start IP Bridge sessions and issues activate_on_receipt_with_length() and read() socket API function calls to read data.

The reasons for using IP Bridge support are similar to those for using MATIP. If you have old hardware that was used to transmit messages through a non-IP network and you now use TPF TCP/IP support, you may be able to discard the old hardware and use IP Bridge support to transmit the messages across an IP network. The old hardware may no longer be supported by its manufacturer; therefore, it may be in your best interest to discard the old hardware before you have a problem with it.

To install IP Bridge support for outbound message processing, use the ZMATP functional message to associate an LNIATA with an IP address. With IP Bridge support, ROUTC macros destined for that LNIATA are intercepted, a socket is created, and a connection is made to the message destination using the IP address provided by the ZMATP functional message. The AMSG header is removed, any chained message blocks on file are brought into core, and the entire message is sent across an IP network by the send() socket API function. For each message destined for that same LNIATA, the message is sent with the same socket over the IP network as long as the socket is still open. Unlike MATIP, no control blocks are exchanged to open and close sessions, and no headers are added to data messages before they are sent.

To install IP Bridge support for inbound message processing, update the Assign LNIATA user exit to enable you to associate an IP address with a port number. In addition, you need to use the ZINET ADD functional message to define one or more IP Bridge servers that can be listening on various ports; for example:


specifies an IP Bridge server with a port number of 9000. A client attempting to connect to that server needs to specify a port number of 9000 and the appropriate TPF IP address in its connect() call. When a message is received by the IP Bridge server, the user exit looks up the LNIATA associated with the server's port number and TPF then routes the message to the application associated with the LNIATA.

MATIP and IP Bridge Prerequisites

The APARs needed to install MATIP and IP Bridge support are included on PUT 10, but you can install APARs PJ26161, PJ26324, and PJ26359 on a PUT 9 system if you do not want to upgrade to PUT 10. If you want to use A2CS and ACSA workstations to establish MATIP sessions with TPF, your A2CS workstation must have MATIP support installed.

MATIP and IP Bridge References

For more information about MATIP, the best reference is the SITA Web site at:

This site contains three useful documents that were written by SITA:

  • Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP (RFC 2351)
  • MATIP Implementation Guide
  • Type-B ACS Traffic over TCP/IP.

The following TPF documents were modified for MATIP and IP Bridge support:

  • TPF Migration Guide: Program Update Tapes, GH31-0187
  • TPF Operations, SH31-0162
  • TPF ACF/SNA Network Generation, SH31-0131
  • TPF System Installation Support Reference, SH31-0149
  • TPF Messages, SH31-1056.


    About IBM Privacy Contact