"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 zt_transport.com client; one for running the zt_library.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 zt_transport configuration (i.e. accept connections from your respository machine). On your repository machine, you have to write startup scripts to run a separate zt_library 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 zt_library 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.
I'm looking for marbles all day long.
