Normally, method monitoring intervals are set in the TP1/Client/J environment definition. These specifications in the TP1/Client/J environment definition apply to all methods. If a particular method requires a considerable amount of processing time on the TP1/Server system, you will have to specify large values, making it impossible to adjust the execution time according to the processing.
To solve this problem, TP1/Client/J provides methods that enable you to adjust the method monitoring intervals dynamically. When one of these methods is executed, the value specified in its argument is set as the applicable value during execution and remains in effect as long as the instance of the TP1Client class exists (until the rpcClose method is called) or until the same method is called with a different argument value specified. For details about these methods, see 4. Classes Used with TP1/Client/J.
- Organization of this subsection
- (1) Adjusting the time monitoring
Three methods are provided for adjusting time monitoring: setDcwatchtim, setDccltinquiretime, and setDccltdelay. The time monitoring that can be specified with each method is described below.
- setDcwatchtim method
- Sets the response monitoring interval. When the openConnection, rpcCall, and closeConnection methods are called, inquiry response takes place between the CUP and the RAP-processing listener and server. A timeout occurs if no response is returned within the specified response monitoring interval since the inquiry began. Specify an appropriate value taking into account the duration of service execution and the communication speed.
- setDccltinquiretime method
- The permanent connection between a CUP and a RAP-processing listener and server that is established by calling the openConnection method remains established until the closeConnection method is called. If TP1/Client/J cannot call the closeConnection method due to an error, the RAP-processing listener and server will not be released. To avoid this, you use this method to set the length of time allowed for a response from TP1/Client/J before connection with the RAP-processing listener and server is released forcibly.
- Note that if the connection-target RAP-processing server is DCCM3, the value set in the setDccltinquiretime method is ignored.
- setDccltdelay method
- When the rpcCall method is called, the TP1/Client/J system monitors the response time based on the value specified in the setDcwatchtim method. The RAP-processing server that relays RPC requests from TP1/Client/J monitors for a response for the specified amount of time (i.e., the value specified in the setDcwatchtim method minus the value specified in the setDccltdelay method). The value specified in the setDccltdelay method is a delay time for communication between TP1/Client/J and TP1/Server. If the monitoring interval is the same for both TP1/Client/J and the RAP-processing server, a timeout occurs at TP1/Client/J before a timeout occurs at the RAP-processing server because TP1/Client/J starts response monitoring before the RAP-processing server starts response monitoring. If the RAP-processing server sends a response just in time, a timeout may have already occurred at TP1/Client/J and the response may not be received. To prevent such an event, this method is used to force a timeout at the RAP-processing server. To put the value specified in this method into effect, either specify dcwatchtiminherit=Y in the TP1/Client/J environment definition or specify the DRPC_WATCHTIMINHERIT argument in the setRpcextend method.
All Rights Reserved. Copyright (C) 2006, 2009, Hitachi, Ltd.
![[Contents]](FIGURE/CONTENT.GIF)
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)