>> The metadata for the spool file could > >easily be added to the stream (similar to the method used by DISK DUMP > >or CARD DUMP) and read on restore. > > Hmm...well, it wouldn't be (STREAM since it's a CP command, and CP > commands don't use parens for options. But it seems ironic to suggest > backing up spool files to spool;
I wasn't suggesting backup to spool -- that would be useless. What I meant here is that DISK DUMP/CARD DUMP add a :READ card with the file metadata immediately previous to the actual file data, which could be used to actually restore the spool files with the correct information. The data would still be written to the IUCV service, which would be connected to a pipeline to store or otherwise manipulate the data. I was thinking a bit more about the logic of this. If the actual spool manipulation code remained in CP, you could architect it as two IUCV services: *SPCTL (to tell the CP code what to do) *SPDATA (the actual data stream) SPXTAPE could become a pipeline that connected *SPDATA to the pipeline for disk/tape/whatever, and then sent a dump/restore command to the CP code via *SPCTL. The CP code would then select the spool files as appropriate and dump them to *SPDATA, inserting the :READ metadata card as appropriate. The pipeline then takes those records and feeds them out to the appropriate pipeline stages. On restore, same structure, except the pipe is reading from the pipeline input and writing to *SPDATA after telling the CP code to expect input by sending a restore command to the CP code via *SPCTL. This would finally make SPXTAPE synchronous (a real PITA for automation now), and trivially allow encryption and other post-processing w/o having to reinvent the SPXTAPE wheel every time some government moron adds a new requirement for data protection.
