User service network definition

When using an SPP service under the control of TP1/Server Base at another node through the remote API facility, this definition specifies the SPP service group name, as well as the host name and port number that serve as the receive port for the service through the remote API facility.

In addition, when using an SPP service under the control of TP1/Server Base at a node not specified by the all_node operand, this definition specifies the SPP service group name. This definition also specifies the host name at any node in the global domain where the SPP exists and the port number specified by the scd_port operand for schedule service definition. You can specify multiple host names and port numbers (unless you use the remote API facility).

This command executes the dc_rpc_call service request called by the UAP specified with namd or definition in the rpc_destination_mode operand in the user service definition, without requesting a destination search by the name server.

When namd is specified in the rpc_destination_mode operand for the UAP, the UAP executes the service request based on the information specified in this definition command if the destination search request to the name server fails. When definition is specified in the rpc_destination_mode operand and multiple hosts are specified in this definition command for the UAP, the UAP executes the service request based on the information specified in this definition command. If the request fails, the UAP requests the destination search by the name server. If only one host is specified in this definition command, the UAP does not request the destination search by the name server.

For dc_rpc_call called from the UAP whose name or definition is specified in the rpc_destination_mode operand of the user service definition, OpenTP1 retrieves the service group name specified by the first argument from among the service group names specified by the user service network definition. If the system finds a definition having the same service group name, the system sends a service request to the host and port number specified by the definition.

When you specify multiple host names, OpenTP1 selects a host at random and sends a service request. If an error occurs during the transmission of a service request, OpenTP1 selects another host at random from the remaining host names. If a service request to all the hosts fails, dc_rpc_call returns an error. Once a service request is successful, if a destination reselection interval is not specified, service requests from subsequent dc_rpc_call invocations made in the UAP for the same service group continue to be sent to the same host until an error occurs. If an error occurs during continuing transmission of service requests, OpenTP1 selects a different host at random from the remaining host names and tries to send service requests to the newly selected host.

Note that in certain situations, OpenTP1 selects a host at random and sends a service request to the host the next time dc_rpc_call is invoked. Those situations are as follows:

When rpc_destination_mode is definition or omitted and either of the following occurs:

A service request is not successfully sent to any host, a destination search request to the name server fails, and, as a result, dc_rpc_call returns an error.
A service request is not successfully sent to any host, a destination search request to the name server is successful, and dc_rpc_call is successful.

When rpc_destination_mode is namd and all of the following conditions are satisfied:

A destination search request to the name server fails.
A service request is not successfully sent to any host.
dc_rpc_call returns an error.
Another destination search request to the name server fails the next time dc_rpc_call is invoked.

In case more than one dcsvgdef specifies the same service group name, the dscvgdef specification that appears earlier in the user service network definition file is regarded valid. The presence or absence of the -w option determines whether the information is the service information requested through the remote API facility or the service information on a node that is not specified in the all_node operand.

Do not give the dcsvgdef service group name a service request through the XATMI interface; otherwise, the operation cannot be guaranteed.

If the dcsvgdef service group (SPP) that does not specify the -w option is atomic_update = N, and if dc_rpc_call is issued to this service group from within the transaction, dc_rpc_call returns an error with DCRPCER_TRNCHK. In this case, you must specify Y in the SPP's atomic_update operand or specify DCRPC_TPNOTRAN in the flags part of dc_rpc_call.

If you execute dc_rpc_call for a service group name in dcsvgdef without the -w option and acquire the trace for performance verification, the acquired trace is not linked with the trace information for performance verification on the server. In other words, the serial number of the trace for performance verification acquired by the client UAP is not inherited by the server and a new serial number is output to the trace for performance verification acquired on the server.

Giving an asynchronous RPC request to the dcsvgdef service group name by specifying the -w option will make this user service network definition invalid; as before, processing follows the retrieval of name information. Even if you give a transaction service request to the dcsvgdef service group by specifying the -w option, processing is conducted unconditionally in the non-transaction mode.

When you execute dc_rpc_call to the service group name in dcsvgdef specified with the -w option, OpenTP1 does not acquire the RPC trace. When executing dc_rpc_call to the service group defined in the user service network definition as a service on a node using the remote API facility, OpenTP1 does not acquire the client's trace information even if you specify the acquisition of the RPC trace in the system definition of the client UAP.

When you execute dc_rpc_call to the service group name in dcsvgdef specified with the -w option, OpenTP1 acquires the performance verification trace. However, this trace is not linked with the performance verification trace information which is acquired when dc_rpc_call is executed on the RAP-processing server as a proxy. Since the RAP-processing server does not inherit the serial number of the performance verification trace acquired by the client UAP, a new serial number is output for the performance verification trace that is acquired by dc_rpc_call when executed by the RAP-processing server as a proxy.

When you execute dc_rpc_call to the service group name in dcsvgdef specified with the -w option, OpenTP1 does not acquire the response statistics or the communication delay time statistics. When executing dc_rpc_call to the service group defined in the user service network definition as a service on a node using the remote API facility, OpenTP1 does not acquire statistics even if you specify to acquire these statistics in the system definition.

When you specify the -w option and use the remote API facility between TP1/Server Bases (for example, to make RPCs via a gateway such as an application gateway-type firewall), no transaction is created even if you issue the dc_rpc_call function using the transaction attribute. When you use the remote API facility, you cannot correctly start a chained RPC from a transaction and cannot terminate a chained RPC using the synchronous processing. You need to specify DCNOFLAGS in the flags argument in the dc_rpc_call function and explicitly terminate the chained RPC.