Future

Presently, the only advantage of multithreading is that RS-232-C polling requests do not block the server from handling RPC requests. The GPIB would have to be rewritten to take advantage of multithreading. Most I/O is via RS-232-C interfaces, but this will be implemented if found necessary.

SR Data Acquisition at TRIUMF will be moving to a Motorolla 68k/VxWorks front end and OpenVMS/VAX or AXP back end methodology. The port of CAMP to OpenVMS/AXP should be trivial, as CAMP has been written in portable C code, without dependence on address size, etc. The port to the VxWorks front end is the implementation of choice for the new system, but will require some development. GPIB and Serial I/O Industry Packs will be used on an MVME162. A driver for the GPIB is available from Dave Morris at TRIUMF. The Serial I/O driver has been located at several sites, but has not yet been tested. Furthermore, since, as far as current documentation suggests, DECthreads is not available for VxWorks, it will be necessary to port the multithreaded functionality.

The alarm facility of CAMP is available, but has not yet been used in practice. It currently consists of a fixed number of alarm functions statically linked with the server. Ideally, however, the available alarms, and their function would be implemented in the system initialization file using Tcl. This upgrade will be made soon.

If necessary, the possibility of simultaneous processing of multiple RPC requests will be investigated. The option of asynchronous RPC processing is also possible; that is, client applications do not wait for the completion of a request, but this would represent a divergence from the current methodology. It is considered desirable that when a client request returns, the return status always represents the completion status of the request.