OSI/MHS Gateway Programmatic Interface (GPI) Programming Guide

Writing Your Program

OSI/MHS Gateway Programmatic Interface (GPI) Programming Guide—424822-001

5-28

Processing Inbound Information

The objective of inbound processing is to transfer in and retrieve information from an

inbound root object. The client can also choose to copy the root object or edit its

content. As described previously, transfer-in occurs in two stages: a starting stage and a

finishing stage. Following the first stage, the root object is unmodifiable; it can be

inspected and copied but not changed. Following the second stage, the root object can

be edited with decomposing and composing procedures.

The tasks covered in this subsection are:

•

Initiating transfer-in of a root object

•

Retrieving information from a root object

•

Finishing transfer-in of a root object

•

Editing a root object

The GPI procedures used for these tasks are highlighted in Figure 5-7. Note that object

management composing procedures are not highlighted. Composing procedures were

described earlier in this section.

Initiating Transfer-in of a Root Object

The first stage of inbound transfer begins with checking for an available (unreserved)

root object on the GPI service input queue. If an unreserved root object is available, it

can be transferred in.

The tasks covered in this subsection are:

•

Checking for an inbound root object (using GPI_MT_WAIT_ )

•

Starting transfer of an inbound root object (using

GPI_MT_START_TRANSFER_IN_ )

Checking for an Available Inbound Root Object

You call the GPI_MT_WAIT_ procedure to poll the input queue for an unreserved root

object. Once called, GPI_OM_WAIT_ monitors the queue for a specified time. When it

detects an unreserved root object, GPI_MT_WAIT_ returns an indicator.

Note. Dotted arrows indicate that inbound processing might be preceded or followed by

outbound processing. Not shown is the looping that typically occurs for tasks within the

inbound processing block.

Note. You should not issue a call to GPI_MT_WAIT_ within a current Transaction Management

Facility (TMF) transaction defined in your program, because the wait can be extensive and

transactions should not be outstanding for a long period of time. GPI_MT_WAIT_ does not

make use of your transaction.