Menu
A few days ago I discovered a pretty cool software for creating a virtual tape library. You can use the virtual tape library as a real library with the robot, drives, tapes etc. Best of all: the tapes are flat files within their own directory. The Virtual Electronics Library, or VE-Lib, is a C++ library used to easily add electronic simulation in your programs. It makes use of the scripting language Lua to easily add new components like new resistors and microchips.
I'm thinking about submitting my virtual tape software for the OpenVMS freeware distibution and would like to see how the source kit packaging behaves in different environments. It should build on any Alpha running 7.2 or higher with DECC 6.0, but most development has been at 8.2. The code is an update of Wolfgang Moeller's old remote tape driver using TCP/IP instead of DECnet (ZTDRIVER.MAR is virtually unchanged). I use the software to backup my AS800 at home to a 300GB disk drive connected to a Windows PC. Uwe Zessin: 'With all due respect, but that is not what I would call a 'virtual tape library' these days.'
I'm not sure where you are drawing the line. The ZTA0 pseudo-device looks like a tape drive to applications issuing I/O to it, but the data goes over the network to a disk file acting as a container for the virtual tape.
Hence it is a virtual tape drive. The remote host serves several of these files and will respond to a mount request by loading the appropriate virtual tape automatically. Seems to meet the minimal criteria for a tape library to me. The IRPs trigger a mailbox message to a transport process which then does most of its work in user mode.
The tape operations are virtualized as separate protocol messages between the transport and the library server, the remote process doesn't VMS IO$. function codes. There is a protocol.txt in the distribution that tries to explain the network protocol. It hasn't been tested with Multinet or Tcpware.
It does a couple direct QIO operations when reading library responses (IO$MNOWAIT and IO$MLOCKBUF) modifiers which would have to be translated if using Multinet or TCPware native interfaces. The remote side (ztlibrary.c) was kept as basic as possible for maximum portability and does all network I/O through standard socket library functions. Dave, I've built both the library and the transport on OpenVMS Alpha V8.2 and OpenVMS I64 V8.2 (both single CPU systems). I've then run localhost tests (both transport and driver on same machine) on the Alpha system and also run a test from Alpha (transport) to I64 (ztlibrary).
![Library Library](/uploads/1/2/5/4/125427432/189359219.jpg)
Backing up 5.5 GB from the Alpha (10 mbit LAN) to a local USB disk on the I64 achieved a throughput rate between 400 to 700 kByte/sec using -wbc (write back caching). Some tests with vtapetorms on Alpha (extracting savesets from.VTAPE and comparing them with BACK/COMPARE against the original BACKUP source files) showed no problems.
Localhost tests on I64 are not yet successful. Nice piece of software. 'Please advise steps required to implement.' Your first step is to read the aaareadme.txt file in the zipfile you downloaded. Then you build the images and experiment using 3 terminal sessions: one for executing the zttransport.com client; one for running the ztlibrary.exe; and one to do tape operations (i.e.
Small backups) to the ZT: psuedo-device. What you want to do is the inverse of what I'm doing. I have a single ZT device on a cluster backing up to virtual tape robots on multiple machines (running windows). Your host machines can have a common zttransport configuration (i.e.
Accept connections from your respository machine). On your repository machine, you have to write startup scripts to run a separate ztlibrary process for each client host, keeping the virtual tape container files for each in a separate directory. Observations after 18 months: The method of loading tapes by inference from IO$DISPLAY requests burdens somewhat your ability to manage the virtual tapes. If you accidently give 2 tapes the same label you can't control which tape you get for a mount request.
I have command procedures to enforce the labeling scheme (e.g. The backup of $15$DKA200 for 15th week of 07 is 715202.BCK).
Reading a virtual tape is a lot slower than writing it (if you enable -wbc option on the ztlibrary command). Adding a decompress step for records read slows it down even further.
Tracking tape position for speculative read ahead is more work than I wanted to do. Given the slow reads, a virtual EOT on the tape at say 20GB would have been a nice feature. Restoring user ZHANG's files could use the trick of loading a 'not the start of a saveset' tape. This would of course exacerbate the tape label problem, since you are down to 5 meaningful characters.