e programs written by the programmer has to make local procedure calls to the client skeletons using remote program. The rpcgen com- piler allows programmers to mix low-level code with high-level code. After writing the server procedures, the main program can be linked with the server skeletons to produce an executable server program. Handwritten routines can be easily linked with the rpcgen output. The client skeletons interface with the RPC library hides the network from its caller. The server skeleton hides the network from server procedures that are to be invoked by remote clients. The most important file for conversion when using rpcgen is the protocol definition file. This file has a description of the interface of the remote procedures. It also maintains function prototypes and definition of any data structures used in the calls. These definitions will include both argument types and return types that need to be converted. The protocol definition file can also include "C" (programming language) code shared by client and server. Before Conversion type1 PRO1 (operands1) type2 PRO2 (operands2) Fundamentals of EMS, NMS and OSS/BSS After Conversion Client Stub type1 *pro_1 (operands1 * , CLIENT *) i type2 *pro_2 (operands2 *, , CLIENT *) ; After Conversion Server Procedure type1 *pro_1_svc (operands1 *, struct svc_req *) type2 *pro_2_svc (operands2 *, struct svc_req *) ; 27.3.4 RPC Procedure Identification An RPC call message identifies the procedure to be called using the three fields: Program number: There can be multiple programs running on the remote host and each of the programs is identified by a unique number. Once a program number is administered by some central authority it can be imple- mented as a remote program. Program version number: The version field of the call message identifies the version of the RPC protocol being used by the caller. Presence of protocol version makes it possible to speak old and new protocols through the same server process. Remote procedure number: The procedure number docu