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.
