The <remote procedure identifier> following as in an exported procedure definition must denote a <remote procedure definition> with the same signature as the exported procedure. In an exported procedure definition with no as clause, the name of the exported procedure is implied and the <remote procedure definition> in the nearest surrounding scope with same name is implied.
For each <remote procedure call> there must exist an <imported procedure specification> of the remote procedure identifier in an enclosing process type, process definition, service type or service definition having the same <remote procedure name>.
A remote procedure call by a requesting process causes the requesting process to wait until the server process has executed the procedure. Signals sent to the requesting process while waiting are saved. The server process will execute the requested procedure in the next state where save of the procedure is not specified, subject to the normal ordering of reception of signals. If neither <remote procedure save> nor <remote procedure input transition> is specified for a state, an implicit transition consisting of the procedure call only and leading back to the same state is added. If a <remote procedure input transition> is specified for a state, an implicit transition consisting of the procedure call followed by <transition> is added. If a <remote procedure save> is specified for a state, an implicit save of the signal for the requested procedure is added.
Remote procedure call is modelled by an exchange of signals. These signals are implicit and are conveyed on implicit channels and signal routes. The requesting process sends a signal containing the actual parameters of the procedure call, to the server process and waits for the reply. In response to this signal, the server process executes the corresponding remote procedure, sends a signal back to the requesting process with the value of all in/out-parameters, and then executes the transition.
There are two implicit <signal definition>s for each <remote procedure definition>s in a <system definition>. The <signal name>s in these <signal definition>s are denoted by pCALL and pREPLY respectively, where p is uniquely determined. The signals are defined in the same scope unit as the <remote procedure definition>.
The <remote procedure call> 'call; Proc(apar) to; destination' where apar is the list of actual parameters, is transformed to the following, where the to clause is omitted, if destination is not given:
A <remote procedure input transition> or <remote procedure input area> which contains <virtuality> is called a virtual remote procedure input transition. A <remote procedure save> or <remote procedure save area> which contains <virtuality> is called a virtual remote procedure save.
NOTE - there is a possibility of deadlock using the remote procedure construct, especially if no <destination> is given, or if <destination> does not denote a <PId expression> of a process which is guarantied by the specification to exist at the time of receiving the pCALL signal.