If I had to do this without any other products, I would go even further and eliminate DDR. The PIPEDDR program from the downloads page does the Dump/Restore function rather well without the read DDR program. It can be enhanced to include an encryption stage along with the built-in PACK option. I did not try modifying it to write/read tapes directly but I am sure a good plumber can add at least VOL1 record support.
/Tom Kern --- David Boyes <[EMAIL PROTECTED]> wrote: > No, I agree that standalone DDR is necessary, but it's a matter of how > you use it, and if we want to ask IBM to do some work on DDR, I want to > get the most bang for the buck out of that work. > > I approach a standalone restore from the point of getting a minimal VM > system up ASAP, then use that to restore the rest of the system. Now > that you can get a full 3390-3 + IPLable DDR on one tape, I approach the > problem as having one "minimal" boot tape that gets me to the one-pack > system, then I've got CMS. I'd then use the pipe suggestion to handle > the tape positioning, because at that point, pipes can handle the > labels, and DDR just eats what it's fed and restores it to the disk it's > told to use. That one-pack system changes so rarely (thank heavens for > dynamic configuration in CP) that one unlabeled tape is considered > acceptable. (It could even be a labeled tape if I were willing to IPL > the tape twice in standalone mode to get past the label). > > An example of what I'm suggesting might look as follows: > > A) Writing to a labeled tape: > > PIPE DDR STREAM INPUT A | DDRCONN DDRDATA | TAP1 SL > > Where STREAM INPUT A might contain something like: > > SYSPRINT CONS > INPUT 123 3390 FOOBAR > OUTPUT STREAM DDRDATA > DUMP ALL > END > > DDR gets modified to create a connectable IUCV resource with the > specified name on the OUTPUT card. We write a pipe stage DDRCONN to > connect to the specified service and copy data to the output of the > stage. We then use whatever pipe function we want to store the data (in > the example, write to a standard label tape). > > B) Restoring from a std label tape > > PIPE TAP1 SL 4 | DDRCONN DDRDATA | DDR RESTORE INPUT A > > Where RESTORE INPUT A might look like: > > SYSPRINT CONS > INPUT STREAM DDRDATA > OUTPUT 123 3390 FOOBAR > RESTORE ALL > END > > In this case DDRCONN eats standard input, and creates a IUCV resource > with the specified name. DDR then reads that as input and writes to > output as specified. > > C) Standalone case > > Preparation: > > Create a one pack VM system (you don't need spool or page space, as this > thing is really only for the purpose of running parallel restores). > > MOVEFILE standalone DDR to front of tape and leave the tape there. > DDR one pack to same tape. > > In Standalone case: > > IPL one pack system tape. > > DDR restore one pack system to spare disk using the usual methods. > > IPL from one pack system. > > Log in as MAINT. > > IPL 190 > > And you're to the point where you can use the pipe method to control > tape positioning again. > > I just want IBM to spend their development money to get us the biggest > bang for the buck. I think that having the I/O from DDR as something we > can get our hands on with other tools would give us a LOT more options. > > Does that help? > > -- db > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
