Subj:   RE: remote magtape
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
Lessee now. I haven't messed with zt much; my remote disk version had
the net object at the real disk end, so you just define an object
where the DISK is which does the mount. Wolfgang put the net object
at the end where ztdriver is, so yes, you need to log into each end.
And yes, the zt2 that talks to ztdriver needs cmkrnl at least.
   I think things could be improved if you know the tape unit ahead
of time. What you might do is define a network object that runs a
short .com file. This object needs to be priv'd and needs to run a
real detached process OR needs to just somehow stick around till you
close the connection from your end. That object then mounts the tape,
defines the logicals, and runs ztns2 for you. In practice, you
could handle this with a DCL open statement from the command file that
runs ZT2 for you.
   Getting the thing to exit can be cleaned up somewhat also by
taking a forcex image source off the sig tapes or the like, and
hard wiring it to forcex only a process named whatever your ZT2 process
could always be named, or by having it do a $getjpi and ensure that
the image being $forcex'd is ZT2 (simpler). Then that image could be
installed with privilege and the nonpriv'd user problem goes away.
   Normally I set things up so ZTNS2 was run in a detached process for
others to use, and I had people just use $forcex to get ztns2 to go
away and the .com file then would dismount the tape. Since the detached
.com file mounted the tape itself in the first place if someone just
used stop/id, all was also well.
   I did NOT try to stay logged into the tape node; I had a detached
process and some simple command to start it instead; there's no need
for a console to hang around just to run ztns2. Since the tape access
was for a fairly long period, this was not a great problem. If
you want easier use, put the .com file inside a DECnet object instead
so it'll get killed when the net link goes away, and have ztdriver
and zt2 on the end that controls everything. The sequence would then be

1. Load ztdriver sometime
2. Mount the tape on the node where it exists
3. Start ZT2 via .com file that includes a DCL open of the net object
   that will mount the tape and run the ZT2 DECNET object locally.
That is, you have a .com file that starts the REMOTE DECnet object
on the node with the tape, and that DECnet object starts the decnet
object on your local node that runs ZT2. The .com file can be run from
a detached process and just hibernate forever. When someone stop/id's
it, the decnet object that is running ztns2 loses its connection and dies,
releasing the tape on the end with the tape. Also the decnet connection
to ZT2 will then die a moment later, which should force ZT2 to exit
without your having to mess with it. Since killing ZTns2 kills zt2,
this gives a somewhat clean exit in that zt will go offline.

Obviously dismounting zt first is a good idea.

I hope this helps. The package could use at minimum a better writeup
and something like these suggestions to help it get used.
Glenn Everhart