Open topic with navigation
WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows
USupported on UNIX
VSupported on OpenVMS
result = %RX_CONTINUE(netid[, arg_return_flag])
xcall RX_CONTINUE(netid[, arg_return_flag])
The function call return value. If the remote Synergy routine called by %RXSUBR is a function that returns a ^VAL value, the value is returned as the ^VAL result of %RX_CONTINUE. (n)
Network connection ID corresponding to the value you passed with %RXSUBR. (n)
(optional) Indicates whether you want argument return values from the %RXSUBR call to be updated. If not passed, return values are updated. (n)
Pass zero (0) if the %RXSUBR call passed arguments that return a value (arguments defined as “out” or “in/out” in the SMC) and you want them to be updated when the call completes. This means the call will be completed as though %RXSUBR had not timed out.
Pass a non‑zero value if the %RXSUBR call passed arguments that return a value and you do not want the return values updated when the call completes. In addition, error packets will not be returned. This means the call will be completed, but the results (including errors) will be thrown away.
%RX_CONTINUE allows a remote routine to continue processing after an %RXSUBR call has timed out. An %RXSUBR call will time out if processing does not complete within a specified length of time. The default call time‑out is 30 minutes, but you may set a different value with the XF_RMT_TIMOUT environment variable or with %RX_RMT_TIMOUT or when you make the %RX_START_REMOTE call.
When an %RXSUBR call times out, it will signal an $ERR_TIMOUT error. You can choose either to call RX_SHUTDOWN_REMOTE and end the session or call %RX_CONTINUE and continue processing. %RX_CONTINUE restarts the call time‑out clock, which enables the remote routine to continue processing on the server for the length of time defined by the call time‑out. When %RX_CONTINUE times out, it also signals $ERR_TIMOUT. If desired, you can call %RX_CONTINUE multiple times in succession until the call completes. Each call to %RX_CONTINUE restarts the call time‑out clock.
Use the same form (function or subroutine) for the %RX_CONTINUE call as you did for the %RXSUBR call that has timed out.
Passing a non‑zero value in the arg_return_flag argument enables the return packet to be received but not processed, so that you can make another %RXSUBR call and maintain the session context. In other words, the call completes but you throw away the results.
If you call %RX_CONTINUE when an %RXSUBR call has not timed out, %RXSUBR will return the error “No current call in progress” ($ERR_XFNOCALL).
When an %RXSUBR call times out, you cannot make a second %RXSUBR call until a return packet for the first call has been received. At this point you should call %RX_CONTINUE or shut down the session. If, instead, you attempt to make a second %RXSUBR call, %RXSUBR will return the error “Remote call already in progress” ($ERR_XFINCALL).
In the example below, if the RXSUBR call to method123 times out, RX_CONTINUE is called, resetting the call time‑out value and allowing the call to method123 to continue processing.
onerror ($ERR_TIMOUT) timeout xcall rxsubr(netid, "method123", arg1, arg2) . . . timeout, offerror xcall rx_continue(netid)