Depending on the model of the library, there might be a Linux version of the STK control software. All you need it to do is let you tell the library to put volume A in drive B, and make drive B available to the VM system. Bacula doesn't need more brains than that.
If you can't get the z/OS side to let go of the drive, then for now you'd have to use the NFS trick we documented elsewhere. Once the mainline Bacula code supports volume-level migration as a non-experimental feature, it'd probably be worth porting the Bacula storage daemon to USS and writing the tape interface routines to let it use z/OS-based tape. That'd be a killer use for a hipersocket...hmm. Anyone got a C++ compiler on their z/OS box and want to collaborate a bit? David Boyes Sine Nomine Associates > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Jon > Brock > Sent: Monday, July 24, 2006 4:46 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Bad Linux backups > > Our robotics are controlled by Storagetek's software on our z/OS system; > we do not have a VM version. As far as APIs go, I have no idea. > > Jon ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
