|
|
|
|
|
|
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 ApplicationIf a server will be part of a transaction, then it must be in a group on a machine that has a TLOGDEVICE. The 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.The tmloadcf(1) command is used to load the ASCII configuration file into a binary TUXCONFIG file before the application is booted.Note that entries for RPC servers can be added to a booted application using the tmconfig command, as described in tmconfig, wtmconfig(1) in the Oracle Tuxedo Command Reference.When the configuration has been modified, boot the application using tmboot(1). The application is shut down using tmshutdown(1). See the example in Appendix A, A Sample ApplicationThe 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 -s option.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 tmconfig, 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 ApplicationRPC 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.