_______________________________________________________________________________ Differences of Version 3.0 from Version 2.4 ------------------------------------------- Improvements to RPC for v3.0 from v2.4 - Fragmentation (not for multiclient ethernet systems or multiclient DECnet async. servers). This allows messages of unmilited length to be sent. Libraries are (as before) available to use a basic buffer size of either 1.5kB (normal) or 8kB (large). If fragmentation is to be used, both libarraies must be the same. The compiler will issue a message if fragmentation may be necessary (based on 1.5kB buffers) purely for information. - Conventions between stub and runtime library are modified so that new stubs must use new runtime library, and old stubs must use old runtime library. [Exit conditions for rpc_begin etc] - Source files rearranged to make extension easier to new protocols. Run Time Libraries RPCLIBC and RPCLIBC8K: INET Daemon: You can now make a server which is started automatically by the INET daemon. How to add a server with WIN/TCP on VMS is dealt with in more detail in the WIN/TCP instalation guide: from the rpc point of view, just make a server module calling rpc_loop_server explicitly with the address ".TCP". Compiler: o Options /SVAXPAS and /CVAXPAS were in fact /xVAXPASCAL. The Compiler is now changed to be as described in the documenation, is /xVAXPAS. o Incorrect code was produced for VARYING[n]OF CHAR type with VAXPAS options. Bug fixed. o FORTRAN code was produced with DO..END DO loops in. This is not valid FORTRAN 77: labels are now used. Pascal stubs: - When building stubs with explicit preprocessing, the NOALIGN option is now the default , as for the $RPC command Bug fixes since V2.4: In FORTRAN stubs: - Code in client would overrun 72 columns sometimes. - User functions were not type declared in server stub. - User functions without parameters called without "()". - RPC_CALL_STATUS was not declared as INTEGER*4. - External marshalling routines for FORTRAN now in in _FOR. - In server stubs, missing declarations of error code parameters gave bad error handling for bad procedure no. or bad version. In C stubs: - Code produced for call_status parameters was not good. - Code produced for CONCURRENT procedure was not good. Decnet: - Applications using too many event flags would have problems with an unreported error in RPC.