Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-07, at 23:19, retired mainframer wrote: :: -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. That's still a pretty big target. I'm looking at: z/OS DFSMSdfp Utilities SC23-6864-00 http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.idau100/u1086.htm The relevant section would seem to be: SYSUT1 (anyname1) and SYSUT2 (anyname2) DD Statements ... where I see nothing like what you quote. Can you narrow it down some more? Thanks, 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: Sunday, June 08, 2014 6:25 AM :: To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :: Subject: Re: ADRDSSU VTOC -- also IEBCOPY :: :: On 2014-06-07, at 23:19, retired mainframer wrote: :: :: :: -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. :: :: That's still a pretty big target. I'm looking at: :: :: z/OS DFSMSdfp Utilities :: SC23-6864-00 :: :: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.idau10 :: 0/u1086.htm :: :: The relevant section would seem to be: :: :: SYSUT1 (anyname1) and SYSUT2 (anyname2) DD Statements :: :: ... where I see nothing like what you quote. Can you narrow it down :: some more? The section is Job Control Statements, Table 9. In my version of the manual it reads (note the last two lines): SYSUT2 or anyname2 DD Defines a partitioned data set or unload data set for output. A partitioned data set must reside on DASD or be a VIO data set. The unload data set is a sequential data set that was created as the result of an unload operation and may reside on DASD or tape or any other device supported by the QSAM access method.
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-07, at 14:46, John Gilmore wrote: I certainly concede the possibility of front-ending BSAM or QSAM. Nevertheless, the data-management facility for multiple-member operations is BPAM; and in most circumstances it is the one that should be used. With my back to the wall I could even dispense with BSAM too, rolling my own instead using EXCP; but such expedients are for back-to-the-wall situations, not for routine use. Moreover, they are not very robust out of the hands of the few. Another contributor to this thread told me long ago that IEBCOPY did not (then) rely on customary access methods. Rather, with the goal of best performance it used specialized channel programs and facilities such as EXCP V=R and I/O appendages. In consequence, it needed to operate with APF priviliges and could not deal with VIO. I suspect that the advent of PDSE partly impelled conversion to more conventional access methods rather than duplicating in IEBCOPY facilities available in PDSE and Binder. -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
On 8 June 2014 18:15, Paul Gilmartin paulgboul...@aim.com wrote: Another contributor to this thread told me long ago that IEBCOPY did not (then) rely on customary access methods. Rather, with the goal of best performance it used specialized channel programs and facilities such as EXCP V=R and I/O appendages. In consequence, it needed to operate with APF priviliges and could not deal with VIO. I suspect that the advent of PDSE partly impelled conversion to more conventional access methods rather than duplicating in IEBCOPY facilities available in PDSE and Binder. Indeed, these days IEBCOPY is as likely to produce IEW or IGW messages as its own IEB ones. It seems to have become merely a front end for underlying callable system services. AMBLIST has taken much the same path. Tony H.
Re: ADRDSSU VTOC -- also IEBCOPY
On 6/8/2014 3:15 PM, Paul Gilmartin wrote: I suspect that the advent of PDSE partly impelled conversion to more conventional access methods rather than duplicating in IEBCOPY facilities available in PDSE and Binder. Not only that, but the channel programs it used - which were once considered blazingly fast - became inefficient on modern DASD. The developers were able to speed up IEBCOPY processing and remove the onerous APF requirement with one SMOP. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
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.
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-05, at 17:09, retired mainframer wrote:
IEBCOPY from z/OS 1.11 will not support SYSUT2 with DD DUMMY or
DSN=NULLFILE. This is true for either step in your job. It has no problem
with VIO.
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.
-- gil
Re: ADRDSSU VTOC -- also IEBCOPY
IEBCOPY from z/OS 1.11 will not support SYSUT2 with DD DUMMY or DSN=NULLFILE. This is true for either step in your job. It has no problem with VIO. :: -Original Message- :: From: IBM Mainframe Assembler List [mailto:ASSEMBLER- :: l...@listserv.uga.edu] On Behalf Of Paul Gilmartin :: Sent: Tuesday, June 03, 2014 1:30 PM :: To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :: Subject: Re: ADRDSSU VTOC -- also IEBCOPY :: :: On 2014-06-03 14:10, retired mainframer wrote: :: Why don't you show us the job that built the archive and the job that :: tried :: to read it. :: :: :: -Original Message- :: :: From: On Behalf Of Paul Gilmartin :: :: Sent: Tuesday, June 03, 2014 9:10 AM :: :: :: :: On 2014-06-03, at 10:01, Dougie Lawson wrote: :: :: :: :: Well, you say it works for you with the archive on tape. I tried :: it :: :: with the archive on disk, and it didn't work. :: :: JCL: :: :: //IEBCNULL JOB 505303JOB,'Paul Gilmartin', :: // MSGLEVEL=(1,1),REGION=0M :: //* :: //* Doc: IEBCOPY with SYSUT2 DUMMY :: //* :: //USERCOUTPUT JESDS=ALL,DEFAULT=YES, :: // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 :: //* :: //STEP1 EXEC PGM=IEBCOPY :: //SYSPRINT DD SYSOUT=(,) :: //SYSUT1 DD DISP=SHR,DSN=SYS1.PARMLIB :: //SYSUT2 DD DISP=(,PASS),UNIT=SYSALLDA,SPACE=(1000,(1000,1000)) :: //* :: //STEP2 EXEC PGM=IEBCOPY :: //SYSPRINT DD SYSOUT=(,) :: //SYSUT1 DD DISP=OLD,DSN=*.STEP1.SYSUT2 :: //SYSUT2 DD DISP=OLD,DSN=NULLFILE,DSORG=PO :: //* :: //
Re: ADRDSSU VTOC -- also IEBCOPY
You can run with //SYSUT1 DD DISP=OLD,DSN=tape.dataset,LABEL=(,SL) //SYSUT2 DD DISP=OLD,DSN=NULLFILE,DSORG=PO That will get a listing of what would have been copied back. On 3 June 2014 02:13, Paul Gilmartin paulgboul...@aim.com wrote: On 2014-06-02 13:27, Gibson, Vincent wrote: Is it possible to get a ADRDSSU VTOC listing of data set names were dump on to tape. Any help is appreciate. Similar question for an IEBCOPY archive. Thanks, gil -- http://twitter.com/DougieLawson
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-03, at 02:59, Dougie Lawson wrote: You can run with //SYSUT1 DD DISP=OLD,DSN=tape.dataset,LABEL=(,SL) //SYSUT2 DD DISP=OLD,DSN=NULLFILE,DSORG=PO That will get a listing of what would have been copied back. I'll take your word for it; I assume you've tested it. But what if the archive is on DASD rather than tape? Must I copy it to tape first? On 3 June 2014 02:13, Paul Gilmartin wrote: Is it possible to get a ADRDSSU VTOC listing of data set names were dump on to tape. Any help is appreciate. Similar question for an IEBCOPY archive. Thanks, gil
Re: ADRDSSU VTOC -- also IEBCOPY
IEBCOPY archives are a simple VBS (variable blocked spanned) dataset. It makes not a jot of difference whether that's on tape or disk (or something emulating either of those). On 3 June 2014 15:30, Paul Gilmartin paulgboul...@aim.com wrote: On 2014-06-03, at 02:59, Dougie Lawson wrote: You can run with //SYSUT1 DD DISP=OLD,DSN=tape.dataset,LABEL=(,SL) //SYSUT2 DD DISP=OLD,DSN=NULLFILE,DSORG=PO That will get a listing of what would have been copied back. I'll take your word for it; I assume you've tested it. But what if the archive is on DASD rather than tape? Must I copy it to tape first? On 3 June 2014 02:13, Paul Gilmartin wrote: Is it possible to get a ADRDSSU VTOC listing of data set names were dump on to tape. Any help is appreciate. Similar question for an IEBCOPY archive. Thanks, gil -- http://twitter.com/DougieLawson
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-03, at 10:01, Dougie Lawson wrote: IEBCOPY archives are a simple VBS (variable blocked spanned) dataset. It makes not a jot of difference whether that's on tape or disk (or something emulating either of those). Well, you say it works for you with the archive on tape. I tried it with the archive on disk, and it didn't work. On 2014-06-03, at 02:59, Dougie Lawson wrote: You can run with //SYSUT1 DD DISP=OLD,DSN=tape.dataset,LABEL=(,SL) //SYSUT2 DD DISP=OLD,DSN=NULLFILE,DSORG=PO That will get a listing of what would have been copied back. -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
Why don't you show us the job that built the archive and the job that tried to read it. :: -Original Message- :: From: IBM Mainframe Assembler List [mailto:ASSEMBLER- :: l...@listserv.uga.edu] On Behalf Of Paul Gilmartin :: Sent: Tuesday, June 03, 2014 9:10 AM :: To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :: Subject: Re: ADRDSSU VTOC -- also IEBCOPY :: :: On 2014-06-03, at 10:01, Dougie Lawson wrote: :: :: IEBCOPY archives are a simple VBS (variable blocked spanned) dataset. :: It :: makes not a jot of difference whether that's on tape or disk (or :: something :: emulating either of those). :: :: Well, you say it works for you with the archive on tape. I tried it :: with the archive on disk, and it didn't work.
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-03 14:10, retired mainframer wrote: Why don't you show us the job that built the archive and the job that tried to read it. :: -Original Message- :: From: On Behalf Of Paul Gilmartin :: Sent: Tuesday, June 03, 2014 9:10 AM :: :: On 2014-06-03, at 10:01, Dougie Lawson wrote: :: :: Well, you say it works for you with the archive on tape. I tried it :: with the archive on disk, and it didn't work. JCL: //IEBCNULL JOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=0M //* //* Doc: IEBCOPY with SYSUT2 DUMMY //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* //STEP1 EXEC PGM=IEBCOPY //SYSPRINT DD SYSOUT=(,) //SYSUT1 DD DISP=SHR,DSN=SYS1.PARMLIB //SYSUT2 DD DISP=(,PASS),UNIT=SYSALLDA,SPACE=(1000,(1000,1000)) //* //STEP2 EXEC PGM=IEBCOPY //SYSPRINT DD SYSOUT=(,) //SYSUT1 DD DISP=OLD,DSN=*.STEP1.SYSUT2 //SYSUT2 DD DISP=OLD,DSN=NULLFILE,DSORG=PO //* // SYSPRINT from STEP2: * TOP OF DATA *** IEBCOPY MESSAGES AND CONTROL STATEMENTS PAGE 1 IEB1135I IEBCOPY FMID HDZ1D10 SERVICE LEVEL UA67459 DATED 20121210 DFSMS 01.13.00 z/OS01.13.00 HBB7780 CPU 2818 PUT1307 10/01/13 IEB1035I IEBCNULL STEP214:21:45 TUE 03 JUN 2014 PARM='' STEP2COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT IEB120I SYSUT2 VALIDATION ERROR IEB187I NOT A DIRECT ACCESS OR TAPE DATA SET IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME WORK02 NAMED SYS14154.T142143.RA000.IEBCNULL.R0183068 IEB1030I DDNAME SYSUT2 REFERS TO PDS? DATA SET ON VOLUMENAMED NULLFILE IEB166I NO MEMBERS COPIED TO DATA SET REFERENCED BY SYSUT2 IEB151I JOB HAS TERMINATED WITH ERROR(S) IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE BOTTOM OF DATA * -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-03 15:03, Dougie Lawson wrote: You didn't tell us it was your output file that failed. You said it was the input that got the error. No, I said merely that the JCL sample failed, but conceded that I had changed SYSUT1 from tape (which I assumed you verified) to DASD. So we've learned that the input can either be on tape or disk. (Actually, I haven't yet verified with tape.) ...The output can't be DSN=NULLFILE because IEBCOPY does too much checking that you're not trying to pull the wool over its eyes. IEB120I SYSUT2 VALIDATION ERROR Too much checking indeed. I did try changing your SYSUT2 DSORG=PO to DSORG=PS, suspecting that BPAM might conflict with NULLFILE. Made no difference. You could try UNIT=VIO or you'll have to read the VBS dataset with a user program and interpret what the bits and bytes mean. I trust DISP=(,DELETE),UNIT=VIO (or SYSALLDA) would work (or at least fail with a different message). I was just hoping to avoid the superfluous I/O. (I also know, by experience, that SYSUT2 DD PATH=... doesn't work.) -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
Try NEW on the SYSUT2. Then it should go down the copy DCB, etc. path. With OLD, it understandably tries to verify compatibility. OLD and an output NULLFILE isn't all that logical. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, June 03, 2014 2:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ADRDSSU VTOC -- also IEBCOPY On 2014-06-03 15:03, Dougie Lawson wrote: You didn't tell us it was your output file that failed. You said it was the input that got the error. No, I said merely that the JCL sample failed, but conceded that I had changed SYSUT1 from tape (which I assumed you verified) to DASD. So we've learned that the input can either be on tape or disk. (Actually, I haven't yet verified with tape.) ...The output can't be DSN=NULLFILE because IEBCOPY does too much checking that you're not trying to pull the wool over its eyes. IEB120I SYSUT2 VALIDATION ERROR Too much checking indeed. I did try changing your SYSUT2 DSORG=PO to DSORG=PS, suspecting that BPAM might conflict with NULLFILE. Made no difference. You could try UNIT=VIO or you'll have to read the VBS dataset with a user program and interpret what the bits and bytes mean. I trust DISP=(,DELETE),UNIT=VIO (or SYSALLDA) would work (or at least fail with a different message). I was just hoping to avoid the superfluous I/O. (I also know, by experience, that SYSUT2 DD PATH=... doesn't work.) -- gil
Re: ADRDSSU VTOC -- also IEBCOPY
On 2014-06-02 13:27, Gibson, Vincent wrote: Is it possible to get a ADRDSSU VTOC listing of data set names were dump on to tape. Any help is appreciate. Similar question for an IEBCOPY archive. Thanks, gil
