This topic includes the following sections:
Configuring the Application
Booting and Shutting Down the Application
Administering the Application
Using Dynamic Service Advertisement
The Oracle Tuxedo ATMI system administrator modifying the configuration to add RPC servers should be familiar with creating an ASCII configuration file (the format is described in
UBBCONFIG(5)), and loading the binary configuration using
tmloadcf(1). These activities are described in Administering the Oracle Tuxedo System.
When configuring an RPC server, it is configured the same as a Request/Response server. One entry is needed in the
SERVERS page for each RPC server or group of RPC servers. (
MAX can be set to a value greater than one to configure multiple RPC servers with one entry.) An
RQADDR can optionally be specified so that multiple instances of an RPC server share the same request queue (multiple servers, single queue configuration). The
CONV parameter must be not specified or must be set to N (for example,
CONV=N). See the sample configuration file in Appendix A, "A Sample Application."
If a server will be part of a transaction, then it must be in a group on a machine that has a
GROUPS entry must be configured with a
TMSNAME and an
OPENINFO string that are used to access the associated resource manager.
It is optional to specify
SERVICES entries. If specified, the service name must be the name described in the previous chapter, based on the interface name and version number. This entry is needed only if you want to give a specific load, priority, or transaction time that is different than the defaults. It can also be used to turn on the
AUTOTRAN feature, which ensures that a transaction is automatically started for the service if the incoming request is not in transaction mode. Do not use the service entry to specify buffer types
BUFTYPE since the only buffer type handled is
CARRAY. Also, do not specify
ROUTING because routing is not supported for RPC requests.
tmloadcf(1) command is used to load the ASCII configuration file into a binary
TUXCONFIG file before the application is booted.
The RPC servers are booted and shut down in the same way that Request/Response servers are. They can be booted or shut down as part of the entire configuration with the
-y option, as part of a group with the
-g option, as part of a logical machine with the
-l option, or by server name with the
RPC servers appear as Request/Response servers in the administration interfaces. As mentioned above,
tmconfig can be used for dynamic reconfiguration of RPC servers and services, as described in
wtmconfig(1) in the Oracle Tuxedo Command Reference. The
tmadmin(1) command can be used to monitor RPC servers. The RPC server name and associated run-time information (for example, services or operations run, load, and so forth) can be printed using the
tmadmin printserver command. The RPC services (interfaces) that are available can be printed using
printservice. For samples of the output, see the example in Appendix A, "A Sample Application."
RPC services can be dynamically controlled in the same way that Request/Response services can be controlled. Remember that the service name is not the operation name, but the interface name and version number, as described earlier. Generally, the service name is specified at the time that
buildserver(1) is run using the
-s option and automatically advertised when the server is booted with the
-A option. Service (interface) names can be dynamically advertised either from
tmadmin using the
adv command or from within the server using the
tpadvertise(3c) function. Service (interface) names can be dynamically unadvertised either from
tmadmin using the
unadv command or from within the server using the
tpunadvertise(3c) function. Service names can also be temporarily suspended and unsuspended (resumed) from
tmadmin(1). Note that unadvertising or suspending a service name makes all operations defined in the associated interface unavailable.