OSI/MHS Gateway Programmatic Interface (GPI) Programming Guide

Introduction
OSI/MHS Gateway Programmatic Interface (GPI) Programming Guide—424822-001
1-10
P1-EXIT Message Flow
One of the gateway object’s attributes is TYPE. There are two types: NORMAL and
P1-EXIT. The NORMAL type gateway is the standard case described in the preceding
pages of this section. The two types of gateway are very different. The system
administrator or the installer of the gateway determines the gateway’s type when the
gateway is configured. For complete information on configuring gateways, refer to the
OSI/MHS Configuration and Management Manual.
X.400 networks use the P1 protocol to transfer messages between MTAs. For the
NORMAL type gateway, routing is done by the MTA (more specifically, by the MRP).
Messages that specify recipients within the Proprietary Message System are sent to the
gateway. The MTA routes all other messages to further destinations within the X.400
network or delivers them to local message store users.
The P1-EXIT type gateway allows the client program to examine X.400 messages
before the MTA routes those messages. The client program can examine or modify
those messages before transferring them back to the MTA for routing and/or delivery.
The P1-EXIT gateway cannot be configured with APPLs and thus cannot act as a
recipient for messages bound for a proprietary system. In this sense, the P1-EXIT type
gateway functions not as a channel to a proprietary system, but rather as a monitor of
X.400 messages. However, the client can get responsibility for the message and could
conceivably transfer messages to recipients in a proprietary message system without
going back through the X.400 system.
The operation of a P1-EXIT type gateway involves changes to inbound processing.
Figure 1-10
illustrates the internal steps in P1-EXIT processing:
1. The RTS receives a root object (representing a message, probe, report, or
P1-encoded object) from an adjacent MTA. The RTS places the root object on the
PDU store.
2. The RTS process of the MR group notifies the queue manager of the root object.
3. If a wait is pending, the queue manager notifies the GIP that an inbound root object
is available. The queue manager provides the GIP with the object’s PDU ID.
4. When the client initiates inbound transfer, the GIP decodes the root object into a
form suitable for manipulation by GPI object management procedures.
5. The GIP transfers the root object to the GPI library.
6. The client examines the root object and makes a decision on how to go about
completing the transfer-in of the root object. The client exercises this decision by
calling the GPI_MT_FINISH_TRANSFER_IN_ procedure with one of four options
to the remove parameter. The four options are: MH-ARCHIVE, MH-CANCEL,
MH-REMOVE, or MH-TRANSFER.
The MH-ARCHIVE option moves the root object from the input queue to the
archive queue. The MH-CANCEL option cancels the transfer-in and leaves the root
object on the input queue. The MH-REMOVE option deletes the root object from
the input queue and gives responsibility for the root object to the client. These three
options are used during NORMAL operation. MH-TRANSFER, however, is only
valid for P1-EXIT type gateways.