On 2014-06-07, at 08:30, Bob Raicer wrote:
> On Fri, 6 Jun 2014 10:43:57 -0600, Paul Gilmartin wrote:
>
> > I suspect the restriction (we have it at 1.13) spans many
> > releases. How silly to go to trouble to avoid doing nothing.
> >
...
> "Use one of the following access methods with the DUMMY
> parameter:
>
> . Basic sequential access method (BSAM)
> . Virtual storage access method (VSAM)
> . Queued sequential access method (QSAM)
> . BDAM load mode (BSAM with MACRF=WL in the data control
> block)"
>
But does IEBCOPY use any of these?
> I certainly cannot look at the source code for IEBCOPY, but I
> suspect that IEBCOPY simply checks the device type associated with
> the DD to be operated upon and if it's not something it likes (i.e.
> DASD, TAPE) you get the results you're seeing. Actually supporting
> DUMMY allocations would require more work, not less as your
> assertion implies.
>
No. Simply check DSORG. If DSORG=PO, treat the data set as PDS(E).
Otherwise as PDSU (IEBCOPY's jargon). Avoid device type dependencies
entirely. This would, for example, allow unloading a PDS directly
to a UNIX file. I suspect GIMZIP does this in two steps, IEBCOPY to
unload to a temporary data set, followed by ad hoc code (or IEBGENER
would suffice) to copy to the target UNIX file.
-- gil
