OSI/MHS Gateway Programmatic Interface (GPI) Programming Guide

Planning Your Program
OSI/MHS Gateway Programmatic Interface (GPI) Programming Guide—424822-001
4-5
Planning for Gateway Security
Planning for Gateway Security
When planning your program, you should also consider aspects related to gateway
security. With regard to the GPI, gateway security involves the following:
•
Proper installation of the GIP program file and configuration of GIPs
•
Use of a gateway password when calling GPI_OPEN_
GIP Configuration
The owner of the program file that contains the GIP needs to be the installer or starter of
the OSI/MHS subsystem by which GIPs are configured. In addition, GIPs must be
configured for read and write access to each of the following:
•
The queue manager queue file
•
The PDU stores contained within the MR groups of the OSI/MHS subsystem to
which the GIP connects
Gateway Password
A gateway password can be established when the GATEWAY object is configured. In
this case, the client program must specify this password when calling GPI_OPEN_ to
link to that GATEWAY object. If a password is required and not specified, the call to
GPI_OPEN_ fails.
Using Extensions and Criticality
Extensions are a means by which the CCITT adds new service elements to existing
recommendations. Extensions allow an existing application to detect protocol changes
within a message and to know whether an understanding of those changes is critical for
processing the message. If you structure your application to handle extensions, it can
more easily accommodate future protocol changes.
With respect to X.400, extensions are elements of service defined in 1988 or later
recommendations and not present in 1984 recommendations. The GPI provides
mechanisms to handle both supported and unsupported 1988 extensions. A supported
extension is known to the GPI and is represented by a separate and distinct attribute
within the GPI gateway. An unsupported extension is not known to the GPI and does
not have its own attribute.
The GPI can process two types of supported and unsupported extension. One type has a
characteristic called criticality, described later. The second type does not have
criticality. Within CCITT X.400 recommendations, extensions that do not have
criticality are referred to as extension-attributes. Within this manual, extensions that
correspond to CCITT extension-attributes are noted clearly.