Re: ADRDSSU VTOC -- also IEBCOPY
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
Re: ADRDSSU VTOC -- also IEBCOPY
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
Re: ADRDSSU VTOC -- also IEBCOPY
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.
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-07, at 09:30, Robert A. Rosenberg wrote: ... 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 I am missing something in this analysis, please point it out. My objective when I raised the topic of IEBCOPY was to obtain a list of members in the SYSUT1 PDSU archive. For this, it would suffice, and I assumed, that SYSUT2 has DSORG=PS. Certainly I'd expect a failure attempting to create a member or update a directory in any object not having DSORG=PO. -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
Bob Raicer can defend his own positions, but it does seem to me that he made it clear, with appropriate extracts from the manual, that DUMMY is usable only with BSAM, QSAM, and VSAM, i.e., not with BPAM. That being the case, most of this backing and filling is, at best, irrelevant. John Gilmore, Ashland, MA 01721 - USA
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-07, at 10:06, John Gilmore wrote: Bob Raicer can defend his own positions, but it does seem to me that he made it clear, with appropriate extracts from the manual, that DUMMY is usable only with BSAM, QSAM, and VSAM, i.e., not with BPAM. Why are people fixated on BPAM? My assumption was that both SYSUT1 and SYSUT2 have (or can be treated as) DSORG=PS. BPAM is irrelevant, and as you say, DUMMY is usable with BSAM or QSAM. -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
Bob quoted the JCL manual. So yes, DUMMY is usable with QSAM. The issue however is what is IEBCOPY's requirement. My manual says SYSUT2 must reside on a device that supports QSAM, such as (but not limited to) DASD or tape. Since a DUMMY dataset does not reside on a device, it fails that test. The fact that the error message refers only to DASD and tape is just another example of poor wording. Why IEBCOPY has such an apparently unneeded restriction is a different question. And the original issue about member lists is solved by using VIO instead of DUMMY. :: -Original Message- :: From: IBM Mainframe Assembler List [mailto:ASSEMBLER- :: l...@listserv.uga.edu] On Behalf Of John Gilmore :: Sent: Saturday, June 07, 2014 9:07 AM :: To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :: Subject: Re: ADRDSSU VTOC -- also IEBCOPY :: :: Bob Raicer can defend his own positions, but it does seem to me that :: he made it clear, with appropriate extracts from the manual, that :: DUMMY is usable only with BSAM, QSAM, and VSAM, i.e., not with BPAM. :: :: That being the case, most of this backing and filling is, at best, :: irrelevant. :: :: John Gilmore, Ashland, MA 01721 - USA
Re: ADRDSSU VTOC -- also IEBCOPY
To retired mainframer's post my response can be brief: I think not. A single member of a PDS[E] can be accessed in the usual way using BSAM or QSAM. A list of them cannot. For that operation BPAM must be used. BPAM does not support the use of DUMMY. John Gilmore, Ashland, MA 01721 - USA
Re: ADRDSSU VTOC -- also IEBCOPY
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.
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-07, at 11:17, retired mainframer wrote: Bob quoted the JCL manual. So yes, DUMMY is usable with QSAM. The issue however is what is IEBCOPY's requirement. My manual says SYSUT2 must reside on a device that supports QSAM, such as (but not limited to) DASD or tape. Since a DUMMY dataset does not reside on a device, it fails that test. Which manual and section? This depends on some nice semantics of reside on a device. Why, for example, does it permit VIO and SYSOUT but prohibit DUMMY and UNIX files? The latter, at least have to reside somewhere. And it's arguable whether VIO files reside on a device. The fact that the error message refers only to DASD and tape is just another example of poor wording. Indeed. Why IEBCOPY has such an apparently unneeded restriction is a different question. Indeed. I think of Doug Gwyn's maxim (out of context here): Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. Sometimes it seems to me that z/OS more effectively stops users' doing clever things than their doing stupid things. And the original issue about member lists is solved by using VIO instead of DUMMY. Which has lower overhead, VIO or SYSOUT? -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
:: -Original Message- :: From: IBM Mainframe Assembler List [mailto:ASSEMBLER- :: l...@listserv.uga.edu] On Behalf Of Paul Gilmartin :: Sent: Saturday, June 07, 2014 11:46 AM :: To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :: Subject: Re: ADRDSSU VTOC -- also IEBCOPY :: :: On 2014-06-07, at 11:17, retired mainframer wrote: :: :: Bob quoted the JCL manual. So yes, DUMMY is usable with QSAM. :: :: The issue however is what is IEBCOPY's requirement. My manual says :: SYSUT2 :: must reside on a device that supports QSAM, such as (but not limited :: to) :: DASD or tape. Since a DUMMY dataset does not reside on a device, it :: fails :: that test. :: :: Which manual and section? This depends on some nice semantics of The DFSMSdfp Utilities manual in the chapter devoted to IEBCOPY.
