In some cases, where the communication medium and protocol used
is unreliable, or where
the remote software may be unreliable, one wants to specify the
maximum time for execution of a remote routine.
The timeout may be specified in two ways.
PRAGMA TIMEOUT (q.v.) may be specified in the RPC definition file,
in which case it is given separately for each procedure.
Alternatively, the defualt timeout for the package may be specified on the
compiler command line when generating the client stubs, using the option
TIMEOUT=nnnn
where nnnn is the time limit
in units of 10ms.
For example, the option
..bf MONO
TIMEOUT=1000
..pf
selects a timeout of ten seconds.
Allowance should be made for any delays which could occur in the transmission
of messages, or due a machine being heavily loaded.
This ensures that timeouts only
occur when a real problem has arisen.
If a timeout occurs on a remote call, it is treated as an error.
That is, the client program will stop with an error message, unless a
user error handler (discussed above) is declared,
or a call_status (q.v.) parameter is given.
Stub Version Numbers
By default, the RPC compiler generates a version number from the
RPC interface definition file.
This 4 digit number is displayed on the
standard output by the compiler, and inserted as a comment into the
external definition (.ext) file produced.
It is also compiled into the stub code.
At run time, the client stub sends a version number to the server stub,
which checks it against its own version number.
If the version numbers do not match the request is rejected,
and the error message "incompatible versions" is produced at the client.
This ensures that the two stubs were generated from the same definition file,
and will therefore refer to compatible modules.
The version number is formed from a checksum of the non&hyphen.comment
characters in the definition,
and so will change when a material alteration to the package definition
is made.
In some cases, it is possible to make a small change to a package
which will not cause serious compatabilty problems.
For instance, the procedure names may be changed,
another procedure is added
to the end of
the package definition,
or a modification is made to a procedure which has in fact never yet been used.
In this case it is possible to force the stubs to a have a particular
version number, with the
version=
option. The version number must be an integer between 1 and
32767. Numbers between 1 and 999 will not be generated automatically
by the compiler, and so may be used for a private version numbering scheme.
Example
:
Suppose there is a requirement that the procedure names on the client
machine should differ from those on the server.
This may be required to prevent a clash, for example, between
local and remote versions of the same procedure, so that the same
program can access either.
In this case, two RPCL files are made, which differ only in the
procedure names. The server stub is compiled first, with an
automatically generated version number, and then the client stub is compiled
with the version number forced to be compatible.
$ RPC MYSTUB1.RPC /SVAXVMS
RPCC: Generated stub version number is 2765
$ RPC MYSTUB2.RPC /CVAXVMS /VERSION=2765
[The option
version=0
causes the RPCC to generate "unsafe" stubs with no version number check.
If use of this option later allows the inadvertent
connection of incompatible stubs,
run&hyphen.time errors
(access violations etc) may occur without the cause
of the problem being obvious.
This may lead to wasted debugging time, and so is not recommended.]