On Fri, 6 Jun 2014 10:43:57 -0600, Paul Gilmartin
<paulgboul...@aim.com> wrote:
> I suspect the restriction (we have it at 1.13) spans many
> releases. How silly to go to trouble to avoid doing nothing.
>
> DISP={OLD|NEW} seems to make no difference. I suspect that DISP
> is among many DD options that are simply ignored in connection
> with DUMMY.
Here are few extractions from the "DUMMY Parameter" topic contained
within z/OS 1.11 MVS JCL Reference (SA22-7597-13):
"Because no I/O is performed to the dummy data set, the system
checks the SPACE and DISP parameters, if coded, for syntax,
then ignores them. If you code UNIT with DUMMY, the system
will ignore it if the specified unit name is syntactically
correct and defined to the system. Otherwise the system
terminates the job."
:
:
:
"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)"
You'll notice that BPAM (and many other access method types) is
(are) not supported. Nothing has changed here in decades.
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.
Bob
