A SUP is an OpenTP1 client UAP that starts the application processing in client/server communications. A SUP can control the start and finish of a transaction, and request a service from a server UAP. A SUP is used as a client only and cannot also function as a server UAP to provide a service to another UAP.

A SUP can be started at a user-determined time: at the same time as OpenTP1 starts, or online with the OpenTP1 command dcsvstart. In a user service configuration definition, you can specify whether a SUP is to start at the same time as OpenTP1.

OpenTP1 does not control the termination of a SUP so the programmer must code the SUP so that it terminates at the end of application processing.

An SPP provides a service as a user server in client/server communications. An SPP processes requests for a service: the requests are sent by client programs such as a SUP or CUP. An SPP can also start a transaction or send messages.

An SPP can be started at a user-determined time: either started online with the OpenTP1 command dcsvstart, or started at the same time that OpenTP1 starts. In the latter case, when OpenTP1 starts, the SPP is made ready to receive requests. In a user service configuration definition, you can specify whether an SPP is to start at the same time as OpenTP1.

SPPs can be created for each work process, and provide required processing as services. Required services can be added as a system expands. This makes such services easy to maintain and easy to expand.

An SPP can request a service from another SPP, so processing can be nested. Figure 2-8 illustrates such a situation and the relation between SUPs and SPPs.

Figure 2-8 SUPs and SPPs in OpenTP1 systems

(a) SPP structure

When writing an SPP in C, C++, or COBOL, the programmer codes SPP services as functions. An individual function is called a service function in C or a service program in COBOL. The function that organizes the component functions is called the main function in C or the main program in COBOL.

(b) Compilation and linkage

To create an SPP executable file, the SPP source program is compiled and linked. At linkage, the stubs that define the entry point for each service function are linked. A stub is a code module that provides an interface for RPCs between a client and server.

A stub is unnecessary when service functions are created in a UAP shared library^# and loaded dynamically. For details about dynamic loading, see 3.8 Dynamic loading of service functions.

#

This involves compiling the UAP source files and linking the created UAP object files into a shared library.

The two figures below show the SPP structure when a stub is used and when dynamic loading of service functions is used. Figure 2-9 shows the structure of an SPP (when using a stub). Figure 2-10 shows the structure of an SPP (when using dynamic loading of service functions). For details about creating a UAP, see the OpenTP1 Programming Guide.

Figure 2-9 SPP structure (when using a stub)

Figure 2-10 SPP structure (when using dynamic loading of service functions)

(c) Relationship between SPPs and RPCs

In a user service definition, you can specify an SPP executable file as a service-group name, and specify each service function as a service name. Such service names correspond to entry points specified in RPC interface definitions. When writing code for a client UAP to request a service, the programmer must specify the SPP service group name and service name in the RPC function parameters.

An MHP is used in message-exchange configurations and is used exclusively for processing messages. An MHP receives messages from other systems and processes the messages. An MHP can use the various MCF services that, for example, enable the sending or receiving of messages. A node on which an MHP runs requires TP1/Message Control. An MHP can also request a service from an SPP.

An MHP starts application processing when a message is received. In the user service configuration definition, you can specify whether an MHP is to start at the same time as OpenTP1. If an MHP starts when OpenTP1 starts, messages can be received from the start of online processing. If an MHP does not start when OpenTP1 starts, the MHP can be started at a user-determined time using the OpenTP1 command dcsvstart.

Figure 2-11 shows how MHP functions in an OpenTP1 system.

Figure 2-11 MHP in an OpenTP1 system

(a) MHP structure

The unit or part of a UAP that processes a message during message-exchange processing is called an MCF application. The programmer codes the processing of an MHP that corresponds to an MCF application as a function. An individual function is called a service function in C or a service program in COBOL. The function that organizes the created service functions is called the main function in C or the main program in COBOL.

(b) Compilation and linkage

To create an MHP executable file, the MHP source program is compiled and linked. At linkage, the stubs that define the entry point for each service function are linked. A stub is created after creating the RPC interface definition and then executing the stbmake command.

Note that stubs are not needed if you create all service functions as a shared UAP library^# and then perform dynamic loading of service functions. For details about dynamic loading of service functions, see 3.8 Dynamic loading of service functions.

#

A shared UAP library is a shared library that contains UAPs created by compiling the UAPs' source files and then linking the resulting UAP object files.

The two figures below show the MHP structure when a stub is used and when dynamic loading of service functions is performed. For details on writing MHPs, see the OpenTP1 Programming Guide.

Figure 2-12 MHP structure (when using a stub)

Figure 2-13 MHP structure (when performing dynamic loading of service functions)

In a user service definition, you can specify an MHP executable file as a service-group name, and specify each service function as a service name. Such service names correspond to entry points specified in RPC interface definitions. The service-group name and service name are specified in the RPC function parameters.

A service name specified in a user service definition corresponds to an application name in an MCF application definition. OpenTP1 uses this application name as the basis for processing.

(a) Types of MHP applications

MHP services (applications) can be classified according to the kind of message processing, which is specified in the application attribute part of the MCF application definition. The kinds of MHPs are:

ans

An MHP that returns an answer (reply) to the other system.

noans

An MHP that does not return an answer (reply) to the other system.

cont

An MHP that continues sending or receiving messages with the other system.

Programmers can write a UAP that can access a DAM file offline. In a UAP that handles offline work, the programmer must ensure that the DAM file is initialized for use as a DAM file before OpenTP1 starts. A UAP that handles offline work can use the OpenTP1 facilities for initializing DAM files but cannot use the OpenTP1 facilities for RPCs or message-processing.

A user controls the starting and terminating of a UAP that handles offline work, and starts the UAP from the UNIX prompt.