On Mon, 19 Nov 2012 14:16:59 -0600, McKown, John wrote: >This though occurred to me when Lindy said that no mainframe shop he knows of >has tape drives. I wonder what others would think of the possibility of being >able to use both ADRDSSU and AMATERSE in a UNIX environment. Why? Well, image >doing a ADRDSSU DUMP of a disk (or even a logical dataset backup) and sending >it to a UNIX pipe instead of a data set. This pipe would be the input to >AMATERSE. ... > The real pity is that IEBCOPY can't write its PDSU (not PDS or PDSE) output to/ read from a UNIX file or other stream. It employs the block boundaries on reload, but since the PDSU is RECFM=VBS, they can be reconstructed from the BDWs. GIMZIP/GIMUNZIP do this. Considerable overhead and some SPACE crises incurred by GIMUNZIP could be circumvented if IEBCOPY read the GIMZIP UNIX files directly (or via a pipe from uncompress; they're .pax.Z).
Conway's Law: SMP/E can't impose a requirement for even a trivial enhancement to IEBCOPY that would reap a much greater saving for IBM and its customers. AMATERSE can't compress a PDS(E) directly to tape; it must go via DASD. The reason appears to be that AMATERSE must POINT back to the first block to write some sort of summary; perhaps SPACE requirements. GIMZIP supplies similar metadata in the GIMFAF files. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
