> >My comment would be to move the actual tape handling part out of DDR > >entirely and let the data storage be handled by something else, eg a > >pipe connecting to the input or output of the DDR engine. Then it > >wouldn't matter how we were storing the data, and all the positioning > >stuff could be out in user space, so DDR wouldn't need to know or care. > >Then we wouldn't need CMSDDR any more.
> I don't see how that removes the need for CMS DDR. If anything it seems > to strengthen it because standalone DDR wouldn't have access to whatever > is doing the tape handling. Sorry -- CMSDDR is a specific thing. It is a specifically modified version of DDR that can store it's output in CMS files rather than on tape. The Germans modified it and released it for download on the VM Download page. It's very handy, but it's not part of the standard DDR package. > I don't think you meant we wouldn't need > standalone DDR because that will always be needed as a last resort for > when CMS is not available, and therefore it has to be able to read what > CMS DDR wrote. This requires the media handling function to be part of > standalone DDR, which seems contrary to your comment. Please clarify in > case I misunderstood you. 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
