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/
