VAX/VMS Run Time Support

This section describes the particular properties of RPC uner the VMS operating system. See also: Installation under VMS , Tips on debugging under VMS .

Raw Ethernet

Ethernet 2.0 may be used on VAX/VMS, for communication with other VAXes or microprocessor systems, Personal Computers, etc.

The addressing possibilities for ethernet are described in the general section on Ethernet .

Under VMS, the RPC system will attempt to find an ethernet device using the following list of device names in order, until success:

RPC_ETHERNET_DEVICE (A logical name you may define)
XEA0: (For UNIBUS interfaces, DEUNA, DELUA)
XQA0: (For Qbus interfaces, DEQNA)
ESA0: (for Vaxstations)
ETA0: (for BI machines with DEBNT devices)

You can define the logical name RPC_ETHERNET_DEVICE at system or process level if you will to force a particular device to be used, or you wish to use one not in the list.

RS232 Serial Line

An asynchronous V24 (RS232-C) line may be used for connecting two devices. The medium name is V24. The address is the device name, or a logical name which translates to the device name. A set of options may be specified following a colon terminating the device or logical name specification. The options currently supported are

B: Binary coding method: use all 8 bits of the communication path. This is the default.
L: Printable ASCII coding method: use only the printable ASCII characters (seven bits).
F: Disables the RTS/CTS protocol. By default (or with R specified), a strict handshake is used for flow control, for the benefit of those systems with inadequate input buffering. If both connected systems have sufficient input buffering, the F option may be used to make the protocol run faster.

Examples :

TT:L.V24 7 bit working on the user's terminal

_TTA6:.V24 8 bit working on _TTA6: device

Note that data overrun errors can occur when using 8 bit operation, as XON/XOFF control is not used. This can be avoided by increasing the size of the typeahead buffer under VMS, or, better, by using the characteristic TT2$M_ALTYPEAHD on the line involved, which allows the use of a larger typeahead buffer defined at system generation. The non-privileged user could avoid the data overrun errors by not using the above mentioned F (Fast) option, and, if the problem persists, by setting the line to a lower baud rate.

DECnet

Between VAX machines under VMS, a service may be provided over decnet, the server being automatically loaded by the network server at the remote machine, or run explictly by command. The is given as DECNET. The for the server should be either the DECNET address of an object, or an asterisk followed by the decnet object name of an object to be created. In the first case, a connection is requested to the given object. In the second case, the program declares itself as being a given object, and waits for incoming connections.

Explicit DECNET addresses

If the DECNET address of the remote server or client is known, that should be given as the network address. This comprises the nodename followed by the object specification: node::"TASK=object" or node::"0=object" (equivalent) Example : $ DEFINE filer "0@VXCRNA::""0=FILER"".DECNET" (Note the double quotes necessary within a quoted string under VMS) There is a limit of 40 characters on any RPC address. You can avoid exceeding this by defining a logical name for a long decnet address: Example : $ DEFINE FILER "0@HOST.DECNET" ! 40 char. limit $ DEFINE HOST "VXIMAG""USER PASSWORD""::""TASK=IMAGE3""" When such an address is used, a connection will be set up to the named object on the remote node. When this is done, the actions DECNET will take on the remote node as as follows:

If a multiple client server (see below) is already running with that object name, the connection will be made to that process.
If not, then DECNET will look for a command file with the same name as the object requested, and extension .COM. The directory searched will be the home directory if access control information is passed (user and password), otherwise the DECNET directory. If it finds that file, it will run it. The file may start a multi-client server, or a single client server using the address "SYS$NET.DECNET".
If the .COM file is not found, DECNET will search for an executable file (.EXE) and run that in the same way.
If none of the above work, a "No such object at remote node" error is returned to the client.

For instance, in the example above, if a server does not already exist which has network name FILER, VMS will try to run a file FILER.COM or FILER.EXE on the remote machine.

Single-client server

If a process (a server, for instance), is automatically started by DECNET as descibed above, then within that process, the originating process may be addressed as SYS$NET. This is a logical name set up by VMS to point to the process which made the connection. In this way, the command file run by VMS can set up the RPC name of the partner process:

Example filer.com :

$ DEFINE RPC_CLIENT_NAME SYS$NET.DECNET $ RUN FILER.EXE This method is normally used to make a server which will be activated automatically when the client runs. In this case, if a second client tries to contact the same server, a second copy of the server process will be created to service it.

Handling multiple clients

It is equally possible to make a client program which is automatically activated when the server runs. This method may be useful which the server is interactive, or when the server is to be debugged interactively.

For a server wanting to service a number of clients of unknown address, a wildcard network address may be given. This consists of "*", followed by the network name by which the server is to be known.

Example filer.com:

$ DEFINE RPC_CLIENT_NAME *FILER.DECNET $ RUN FILER.EXE In this example, when filer.com is run (by hand, or automatically by VMS when the client accesses it) a network object is created which will endure even when the first client has exited. A server set up with a wildcard client address may service requests from many clients, who may be connected at the same time. It is necessary for the process to have SYSNAM privilege under VAX/VMS to use this facility.

If the decnet object name is omitted, then the name of the process is used. This makes it possible to handle many clones of the same server process easily. It also make it easy for a client to call a server back, as RPC_CALLER_ADDRESS returns a string made made up as an RPC address with the proces name of the server as a decnet object name.

See example: VAX-VAX by decnet

Internet Protocols (TCP, UDP)

To use TCP/IP UDP/IP under VMS requires the installation of an internet protocol package such as the WIN/TCP, the SRI_Mulitnet package, of Digital's UCX. To use this facility,

Use library RPCLIBC rather than RPCLIB, or RPCLIBC8K instead of RPCLARGE.
Produce the stubs with the GeniericC options of the compiler.
Compile the stubs without the /DEFINE=VAXVMS qualifier.

The ability to declare a server using one's own "well known port number" requires SYSPRV privilege.

See the sections on Internet addressing , Using SRI_Multinet , using UCX

ISO Transport Protocol

ISO class 4 Transport Protocol ("TP4") may be used. This requires the installation of the VOTS package under VAX/VMS. The medium name is IEEE.CATS. The "IEEE" selects the protocol used, from those supported by the CATS library . For the client, the address part is of the form <tsuf> @ <node> where the tsuf (transport suffix) identifies the process that will run the server - it should be the same as the tsuf specified by the server; and the node gives the physical address of the machine running the server. The maximum length of a tsuf on DECnet is 12 characters.

The address may optionally be preceded by a "#", which causes the client to make a new transport connection for each RPC call rather than to leave it open after the RPC_Open and only close it when RPC_close is called. The "transient" client is useful when either the client or server can only have limited number of connections open.

For the server, the address is of the form

*<tsuf>@IEEE.CATS where the identifies the current process to the network system.

Examples :

The following examples give two possible addresses for the client and the corresponding address for the server. 0@MYSERVER@AA000400DD58.IEEE.CATS Normal client. 0@#MYSERVER@AA-00-04-00-DD-58.IEEE.CATS Transient client. *MYSERVER@ieee.cats Server .

CERN Host Interface to VME or FASTBUS

This is a fast point to point communication link between VAXes, VME and FASTBUS systems. See the section on CERN Host Interface addressing .

Debugging Trace

The logical name (VAX/VMS) rpc_trace_flag controls diagnostic output. To turn it on, this must be defined as the output filename, for instance SYS$OUTPUT: (with the colon). If trace is on, the RPC run-time system will produce copious trace information @bout each transaction, including the contents of each message received or transmitted, and the addresses involved. Two commands are provided to manage this:

$ TRON: Turn run-time trace on
$ TROFF: Turn run-time trace off

If a run time error occurs which you do not understand, running the trace (perhaps to a file) may explain what went wrong more clearly than the single error message.