; Remote tape driver for tcp/ip to DEC Unix (or maybe others)   @ To run it is expected that cmnode points to the net node address< of the server; the driver and cmhost are run on the VMS end.  F The server cmserver should run on DEC Unix first. Initial version usesF socket 800 for network I/O. Multiple servers can use multiple sockets.  > Once the server is started, it waits for a new connection. ForD repeated connections, run the server from a shell script that is runB NOHUP'd that loops forever. The server does the work of connecting to the tape unit.   ? Note that some unix systems don't allow ALL possible functions.   B Used W. Moeller's zt-driver as starting point but added a bunch ofA mods to get it to work with tcp/ip, using netlib v2. The unix end B is sufficiently generic that it may work on anybody's unix, but itB does presume you start the unix end first. It sits and listens for@ a tcp connect on its (hard-coded) socket and uses that to accessB the device. If the device is a disk file, it won't really care tooD much, but it must be treated as raw. This was tried with a slow tapeB using vms backup & worked. It sends data in little tcp packets andD reassembles at the unix end, or vice versa, so that the integrity of@ getting large packets is not needed. Don't let vms hear about itG being able to handle a larger record than its buffer can hold. It makes C no attempt to do multibuffering, just gets the data across and gets @ it to/from tape. VMS will however think the tape drive is local.  A It is likely that the system can be a bit more robust if the tape B supports the SCSI read position command and that is used to report- tape position. Currently it is just computed.   C Also the ability to reconnect lost net connections would be nice to  add in case your net is flaky.    7 This thing isn't as easy to use as some, but does work.    gce   