> > You are aware that you can't use a channel-attached 3494 or VTS > > from > > Linux w/o getting some other OS to handle the tape mounts > I already have one virtual machine performing DFSMS/RMS > mounts of VTS tapes for another virtual machine. > While I myself have no vague idea how to do it, I don't imagine > it would be a major production to convert tape requests in > linux to CP message/smsg to a CMS server machine. > The server then performs a DFSMSRM MOUNT .... > Would it???
Depends on the Linux app -- remember, Linux has no native tape management support beyond the device drivers in the kernel; what exists is all in user-space programs. If your Linux app is smart enough to call an user-configurable external program like 'mtx' to manipulate the tape library and changer robotics, you can use the tape mount server code Adam and I developed and posted, and it's not a big deal at all. This is exactly why we wrote the thing. If your Linux app insists on managing the changer directly (as some do), then it's a fairly major operation. Intercepting SCSI commands sent to a changer device entry is non-trivial (not impossible, but not for the faint of heart) and not supported by IBM at all (compare to the Solaris and Windows drivers for the 3494). For some sites, this matters. You could try to use the "foreign tape manager" support in DFSMS/RMS, but be aware that the code as supplied leaks memory, and there is no Linux client support. (It also only interacts with specific physical drives, so you have to know the actual hardware information on the drive to get it to work) You could hack something up to use some of the VSE DFSMS/RMS support routines, but you're back to inventing your own line protocol and network protocol to interact with Linux, and then you're back to square one. The existing DFSMS code uses APPC to communicate with its various parts, and is NOT trivial to configure. I have Linux APPC and CPI-C libraries, but they were too much work to give away for free. -- db
