Multiple services corresponding to requests of various client UAPs are created. The created services are grouped into an SPP executable file. When C language is used, each service is called a service function; when COBOL language is used, each service is called a service program. To produce an SPP executable file, link multiple services with a main function (or a main program in COBOL language). Then, define the SPP executable file, comprising one main function and multiple service functions, as a service group in OpenTP1.

The facility for dynamic loading of service functions allows multiple services to be rolled into a UAP shared library^#. This eliminates the need to link the services with the main function.

#

Refers to the concept of compiling UAP source files to produce UAP object files, which are then linked to create a shared library.

The figures below show SPP configurations, the first of which uses a stub and the second of which uses dynamic loading of service functions.

Figure 1-10 SPP configuration (when using a stub)

Figure 1-11 SPP configuration (when using dynamic loading of service functions)

The SPP can be started either at the same time as OpenTP1 or anytime after OpenTP1 is started. If the first method is selected, SPP processing will start as soon as OpenTP1 starts. The starting time can be selected according to the purpose of the SPP.

(a) Starting at the same time as OpenTP1

Before starting OpenTP1, specify that the SPP is to start at the same time as OpenTP1. The specification method is as follows:

• TP1/Server Base
  Specify the user server name of the SPP in the definition command dcsvstart for the user service configuration definition.
  
• TP1/LiNK
  During the operation to set up the user server environment, specify that the SPP is to start automatically.
  

(b) Starting anytime after OpenTP1 is started

To start the SPP anytime after OpenTP1 is started, specify the user server name of the SPP as the argument to the dcsvstart command.

The SPP process is initiated from the main function. It becomes ready to offer service when the SPP service starting function (dc_rpc_mainloop()[CBLDCRSV('MAINLOOP')]) is normally executed.

The started SPP works as a previously specified process so that memory can be used efficiently. The started SPP may be activated as a resident process or nonresident process. In the former case, the SPP starts processing upon receiving a service request. Even in the latter case, a service request activates the process, thereby starting SPP processing.

For details about setting up UAP processes, see 1.3.5 Application program environment setup.

The SPP is normally terminated when:

• OpenTP1 is normally terminated.
• The dcsvstop command in which the user server name of the SPP is specified is executed during OpenTP1 operation.

When one of the above events occurs, the function dc_rpc_mainloop() returns, thereby terminating the SPP.

Do not use the kill command to terminate the SPP process.

Perform the following pre-processing for SPP main functions:

• Application program start (dc_rpc_open()[CBLDCRPC('OPEN ')]).
• SPP service start (dc_rpc_mainloop()[CBLDCRSV('MAINLOOP')]).

If the transaction start function has been called from the SPP, terminate the SPP after using the transaction commitment function (synchronization point acquisition).

To use an MCF function from the SPP, call the MCF environment open function (dc_mcf_open()[CBLDCMCF('OPEN ')]) and the MCF environment close function (dc_mcf_close()[CBLDCMCF('CLOSE ')]) as main functions.

The figure below shows SPP processing.

Figure 1-12 Outline of SPP processing (C language)