The problem is that SPXTAPE does not run as a normal application, reading spool data and writing data to its output device using SSCH logic. If there were normal virtual I/O operations writing to the output (backup) or reading from the input (load), then the problem has already been solved in a number of ways. CMS flat files could be used, tape (either real or virtual) could be used, etc.
Virtual Tapes for VM are not something new. They have been in use in the ACP/TPF world at least since late 1984. We even used them for an MVS3.8 guest in 1984. I do not know for sure whether CA's CDTAPE is a proper inclusion in this discussion. I do not believe that it really does tape virtualization. How about it someone from CA, is it a generalized tape emulator or simply a specialized program that does not fit the discussion? Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Tom Duerbusch > Sent: Friday, September 08, 2006 9:34 AM > To: [email protected] > Subject: Re: Saving a backup copy of NSSs with no tape drive > > > Well, to take that one step farther.... > > In the VSE world, they have VSE Virtual Tape. Can go to a VSE > supported VSAM file or via IP to a JAVA platform (such as our > PC). So, > IBM does have the code, just the wrong group. > > CA has a virtual tape function for VM which is used for product > distribution and maintenance. So, apparently, it wasn't too > hard to do > it under VM. > > So, we just need to combine the code from VSE, with the knowledge of > how to do it under VM, and we can get rid of many of the > requirements to > modify a command to support a disk file also. > > But then, bringing up VSSI.... > I wonder if there is some hesitation in IBM providing a "free" feature > that wipes out a venders chargable product? > > > Tom Duerbusch > THD Consulting > > >>> [EMAIL PROTECTED] 9/8/2006 10:58 AM >>> > That would solve the problem of using the VTAPE product from VSSI as > the mechanism for reading and writing SPXTAPE files. There would be no > need for vendor defined modifications to CP to accomplish the > feat. I am > for that (and I expect the folks at VSSI would welcome it too). > > Regards, > Richard Schuh >
