I don't think there is anything particularly wrong with what
you propose, however, it is both more code/work than what
currently exists and looking inside the data set referenced by
the DD being operated upon can only happen after it is OPENed
(and the BPAM OPEN will fail when referencing a DUMMY allocation).
Bob
On 2014-06-07 9:30 AM, Robert A. Rosenberg wrote:
At 08:30 -0600 on 06/07/2014, Bob Raicer wrote about Re: ADRDSSU VTOC -- also
IEBCOPY:
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.
I disagree.
Here is my reasoning.
Support of output to SYSUT2 requires that for each file that is being selected
to be
potentially copied to SYSUT2, there is a check to see if it already is in the
PDS(E)
UNLESS Replace (SYSUT2,R) is coded in the Copy command before the copy is
attempted.
If SYSUT2 is DUMMY/NULLFILE, then the check is bypassed and the copy acts as if
the file
does not exist in SYSUT2. All that is needed is to error at open time if you
have a
DUMMY as input. For output, set a flag that says the dataset is dummy, and as
each file
is selected, just issue the copied to message bypassing any reading of the
member itself.
Note, I am assuming that you do not want to be warned of duplicate files from
input (ie:
No Replaced or Not Copied messages).
If I am missing something in this analysis, please point it out.
