Stubs are required to communicate between UAPs using RPCs. A stub is a program which corresponds the service group name and service name specified by the client UAP to the server UAP service.

The stub defines the point of entry (entry point) for each UAP service.

When creating a server UAP, link the stub to the object file of the server UAP.

For SUP and UAP that handles offline work, there is no need to define and link the stub.

The figures below show how service functions are created using a stub, for SPP and for MHP separately.

Figure 2-18 Using a stub to acquire service functions (SPP)

1. The entry point of the service function is defined in the RPC interface definition, and a stub is generated by the stbmake command.
   The service group name and the service name are defined in the user service definition.
   
2. In the execution form file of the server UAP to which a service was requested, the library created according to the stub and the user service definition is searched for the corresponding service during execution. The results of service processing are then returned to the client UAP.

Figure 2-19 Using a stub to acquire service functions (MHP)

1. The entry point of the service function is defined in the RPC interface definition, and a stub is generated by the stub-generating command.
   The application name, service group name, and service name are associated with each other in the MCF application definition. The service group name and service name are defined in the user service definition.
   
2. During execution, TP1/Message Control searches for the service name that corresponds to the application name based on the MCF application definition, and starts the corresponding server UAP. In the execution form file of the server UAP to which a service was requested, the library created according to the stub and user service definition is searched for the corresponding service. The service is then processed and service completion is communicated to TP1/Message Control.

When the facility for dynamic loading of service functions is used, the service functions are acquired from a UAP library that specifies the point of entry (entry point) for each UAP service. There is no need to create a stub. Instead, you need to create a UAP shared library^# that incorporates the service functions. You can then acquire service functions from the UAP shared library, eliminating the need to incorporate multiple services into the main function.

#

A UAP shared library is created by compiling UAP source files to produce UAP object files, which are then linked to create a shared library.

The figures below show how service functions are created using dynamic loading of service functions, separately for SPP and MHP.

Figure 2-20 Using dynamic loading of service functions only (SPP)

Figure 2-21 Using dynamic loading of service functions only (MHP)

Note that a UAP that uses a stub can also use dynamic loading of service functions. In this case, a service function can be added without modifying the UAP that uses a stub.

The figures below show, separately for SPP and MHP, how service functions are created using both a stub and dynamic loading of service functions.

Figure 2-22 Using both dynamic loading of service functions and a stub (SPP)

Figure 2-23 Using both dynamic loading of service functions and a stub (MHP)