Re: Speed up DASD copy

[David Devine]

Hello,
with regard to the undocumented use of the "optimize" parameter on dfdss copy, 
those nice people at Ibm in Dfdss R&D have opened a marketing req to get it 
fully supported and also an apar which will ignore it if coded with copy.   

"We have the following Marketing Requirement opened:
User Group Number - MR0318131821

We also have an APAR to ignore the keyword for now:
OA41764"

regards
Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Miklos Szigetvari]

Thank you Dave.
Disturb me a little "the code is not fully developed" sentence, but we 
are now over the big copy(140 volumes with 3 errors) .

Thank you again .

On 14.03.2013 17:32, David Devine wrote:

Hello,
further to this query and the oddity of Optimize being tolerated for dfdss full copy but not 
documented, i emailed one of the guys who present's the "What's new in dss" 
share sessions asking for clarifcation and they were kind enough to send on to R & D who 
gave the response.

Here's the reply.

"Hi David,

Thank you for your questions.  You are correct, Optimize is only valid for 
dump.  Optimize for copy was prototyped 20+ years ago, but was never intended 
to be shipped as part of the product.  I understand you do see some performance 
gains when running your copy commands, but the code is not fully developed.  We 
will take an APAR and are considering two approaches:
1.  ignore the OPTIMIZE keyword for the COPY command.  This means that 
existing jobs that specify OPTIMIZE on COPY that run today would continue to 
run, however, they will be forced to OPTIMIZE(1).
2.  cause a syntax error when OPTIMIZE is specified on the COPY command.  
This means existing jobs that specify OPTIMIZE on COPY that run today would now 
fail.

We would appreciate any comments you have on whether we should take one 
approach over the other.  Also, if you would like to see OPTIMIZE for COPY 
fully supported I would ask you open a marketing requirement.  A requirement 
will help get that work prioritized amongst other requirements.

Thank you again,
Robert Gensler
DFSMSdss Architecture and Development
Tucson, AZ"

Nice people to talk to.

In the short term, i think the first apar option is probably desirable rather the second as 
they need to cater for the fact its unsupported and mitigate for any unforseen consequences 
of its usage, but longer term, getting it fully deployed & supported on copy, if only for 
"Copy Full" would be the way to go, so i'd say opening a marketing requirement 
would be the preferred approach.

An invitation hard to refuse.
The more requests they get the more likely it is to happen so anyone attending the next 
few "shares" could bring it up too.

Dave
  


***

Miklos,
Others may want to correct me, but from what I've observed OPT(4) is only used 
for the DUMP command.
COPY will accept OPT(4), but all you seem to get is  OPT(3).
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Miklos Szigetvari
Sent: Thursday, March 07, 2013 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Speed up DASD copy

   Hi

The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
10 minutes to abut 7 minutes.
The  "real" copy will go from ESCON channels to FICON .
We have to do this only once, as "BusTech" gave up the support for zDASD .

Thank you
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[David Devine]

Hello,
further to this query and the oddity of Optimize being tolerated for dfdss full 
copy but not documented, i emailed one of the guys who present's the "What's 
new in dss" share sessions asking for clarifcation and they were kind 
enough to send on to R & D who gave the response.

Here's the reply.

"Hi David,

Thank you for your questions.  You are correct, Optimize is only valid for 
dump.  Optimize for copy was prototyped 20+ years ago, but was never intended 
to be shipped as part of the product.  I understand you do see some performance 
gains when running your copy commands, but the code is not fully developed.  We 
will take an APAR and are considering two approaches: 
1.  ignore the OPTIMIZE keyword for the COPY command.  This means that 
existing jobs that specify OPTIMIZE on COPY that run today would continue to 
run, however, they will be forced to OPTIMIZE(1). 
2.  cause a syntax error when OPTIMIZE is specified on the COPY command.  
This means existing jobs that specify OPTIMIZE on COPY that run today would now 
fail.

We would appreciate any comments you have on whether we should take one 
approach over the other.  Also, if you would like to see OPTIMIZE for COPY 
fully supported I would ask you open a marketing requirement.  A requirement 
will help get that work prioritized amongst other requirements.

Thank you again,
Robert Gensler
DFSMSdss Architecture and Development
Tucson, AZ"

Nice people to talk to.

In the short term, i think the first apar option is probably desirable rather 
the second as they need to cater for the fact its unsupported and mitigate for 
any unforseen consequences of its usage, but longer term, getting it fully 
deployed & supported on copy, if only for "Copy Full" would be the way to go, 
so i'd say opening a marketing requirement would be the preferred approach.

An invitation hard to refuse.
The more requests they get the more likely it is to happen so anyone attending 
the next few "shares" could bring it up too.  

Dave
 

***
>Miklos,

>Others may want to correct me, but from what I've observed OPT(4) is only used 
>for the DUMP command.

>COPY will accept OPT(4), but all you seem to get is  OPT(3).

>Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Miklos Szigetvari
> Sent: Thursday, March 07, 2013 4:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Speed up DASD copy
> 
>   Hi
> 
> The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
> 10 minutes to abut 7 minutes.
> The  "real" copy will go from ESCON channels to FICON .
> We have to do this only once, as "BusTech" gave up the support for zDASD .
> 
> Thank you


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bloat (was: Speed up DASD copy)

[Shmuel Metz (Seymour J.)]

In
,
on 03/11/2013
   at 09:57 AM, John Gilmore  said:

>My gmail server has an 'include quoted text' box which is checked 
>by default.  If it and other ermail servers' defaults were not to
>include quoted text the work required to include great gobbets of 
>it repetitively would discourage some posters from doing so.

ITYM that google[1] makes it difficult to do the right thing and makes
it easy to quote the entire message. A decent mail client displays the
original message at the same time[2] as the composition window and
makes it easy to quote selectively . A really good e-mail client makes
it easy to reflow nested quotes; mine, alas, does not do the latter.

[1] Google is far from the only offendor.

[2] It's a matter of taste whether they belong in independent
windows or as two panes in a larger window; I prefer the latter,
but google offers neither.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bloat (was: Speed up DASD copy)

[DASDBILL2]

Sounds like a highly profitable symbiosis between DASD hardware vendors,  any 
type of software product  that generates data that might need to be stored for 
a very long time, and any governmental requirement for such data . . 



Bill Fairchild 
Franklin, TN 
- Original Message -
From: "John Gilmore"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 11, 2013 9:57:01 AM 
Subject: Re: Bloat (was: Speed up DASD copy) 

We have here yet another instance of the turnpike effect.  Traffic 
volumes will continue to expand while any capacity to serve them 
remains. 

My gmail server has an 'include quoted text' box which is checked by 
default.  If it and other ermail servers' defaults were not to include 
quoted text the work required to include great gobbets of it 
repetitively would discourage some posters from doing so.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bloat (was: Speed up DASD copy)

[John Gilmore]

We have here yet another instance of the turnpike effect.  Traffic
volumes will continue to expand while any capacity to serve them
remains.

My gmail server has an 'include quoted text' box which is checked by
default.  If it and other ermail servers' defaults were not to include
quoted text the work required to include great gobbets of it
repetitively would discourage some posters from doing so.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bloat (was: Speed up DASD copy)

[Paul Gilmartin]

On Mon, 11 Mar 2013 08:40:49 -0500, Shane Ginnane wrote:

>According to wc, miklos' last answer was comprised of 125 (new)lines - being 
>737 words (and 5010 bytes). That analysis can be considered approximate, but 
>close.
>All for a 4 word answer - 5 if you include the introductory "Hi".
>
>Extravagant maybe ?.
>  
Yes.  Actually, looking at the raw data in my mbox, I get:

:w ! wc
 21010298566

But that's just as an email message.  A similar count of the web
page on IBM-MAIN gives:

:w ! wc
 9953130   45820

Parkinson's Law.  Small wonder Shmuel with his dialup connection
uses POP3 and reads offline.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Shane Ginnane]

According to wc, miklos' last answer was comprised of 125 (new)lines - being 
737 words (and 5010 bytes). That analysis can be considered approximate, but 
close.
All for a 4 word answer - 5 if you include the introductory "Hi".

Extravagant maybe ?.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Miklos Szigetvari]

Hi

On 10.03.2013 01:28, Ron Hawkins wrote:

Miklos,

Others may want to correct me, but from what I've observed OPT(4) is only used 
for the DUMP command.

COPY will accept OPT(4), but all you seem to get is  OPT(3).

Seems you are right

Ron


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Miklos Szigetvari
Sent: Thursday, March 07, 2013 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Speed up DASD copy

   Hi

The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
10 minutes to abut 7 minutes.
The  "real" copy will go from ESCON channels to FICON .
We have to do this only once, as "BusTech" gave up the support for zDASD .

Thank you

On 07.03.2013 12:37, David Devine wrote:

Hi Miklos,
I'm making the assumption that your are referring to dfdss.
The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by

using the OPT keyword.

I believe the default is (3) which is 5 tracks read at at time.
OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at

at time.

If you are doing a full volume copy i expect your sysin should look
something like this:-

COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) - COPYVOLID

PURGE

OPT(4)

or you may use INDD OUTDD for your volume selection

Other criteria to consider, region size on your jobcard or pgm; number of

available channels; whether you want to copy your disks when in use or not.

Using a product like softek's tdmf will allow for in flight disk copys.
If you don't ahve it, then dfdss should only be used for packs when not in

use.

With dfdss you need to cater for the volume ids on the source & target

volumes, so you may want to add steps to "clip" (ickdsf reformat) the source
volume before the dfdss copy and "clip" the target volume to the original
source name after the copy.

This will keep it isolated and stop inadvertant access to the original source

volume.

Good luck!

Dave


**


*

Hi

We need to copy a large number of DASD volumes (from zDASD to

DS6800).

Any option to speed up?
Seems CONCURRENT is not supported by the zDASD.
Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new
extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally binding.
Unauthorised use, publication, reproduction or disclosure of the content of
this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts no
responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Elardus Engelbrecht]

Ron Hawkins wrote:

>Others may want to correct me, but from what I've observed OPT(4) is only used 
>for the DUMP command.
>COPY will accept OPT(4), but all you seem to get is  OPT(3).

I wanted to jump in this thread, saying that OPT() is only for DUMP (as per 
documentation for z/OS v1.12), but I intentionaly waited to see what others 
said.

Ron, how did you see OPT(3) is used instead of OPT(4) as given as parm?

Could it be that OPT is a 'phantom' keyword to be ignored instead of rejected 
as a syntax error? Or in other words - is ONE syntax checker is used for all 
the DFDSS commands and just ignore(s) 'undefined'/'undocumented' keywords?

Mind you, there are some threads about syntax of DFDSS input in IBM-MAIN this 
last 12 or so months.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Ron Hawkins]

Miklos,

Others may want to correct me, but from what I've observed OPT(4) is only used 
for the DUMP command.

COPY will accept OPT(4), but all you seem to get is  OPT(3).

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Miklos Szigetvari
> Sent: Thursday, March 07, 2013 4:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Speed up DASD copy
> 
>   Hi
> 
> The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
> 10 minutes to abut 7 minutes.
> The  "real" copy will go from ESCON channels to FICON .
> We have to do this only once, as "BusTech" gave up the support for zDASD .
> 
> Thank you
> 
> On 07.03.2013 12:37, David Devine wrote:
> > Hi Miklos,
> > I'm making the assumption that your are referring to dfdss.
> > The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by
> using the OPT keyword.
> > I believe the default is (3) which is 5 tracks read at at time.
> > OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at
> at time.
> >
> > If you are doing a full volume copy i expect your sysin should look
> > something like this:-
> >
> > COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) - COPYVOLID
> PURGE
> > OPT(4)
> >
> > or you may use INDD OUTDD for your volume selection
> >
> > Other criteria to consider, region size on your jobcard or pgm; number of
> available channels; whether you want to copy your disks when in use or not.
> >
> > Using a product like softek's tdmf will allow for in flight disk copys.
> > If you don't ahve it, then dfdss should only be used for packs when not in
> use.
> >
> > With dfdss you need to cater for the volume ids on the source & target
> volumes, so you may want to add steps to "clip" (ickdsf reformat) the source
> volume before the dfdss copy and "clip" the target volume to the original
> source name after the copy.
> > This will keep it isolated and stop inadvertant access to the original 
> > source
> volume.
> >
> > Good luck!
> >
> > Dave
> >
> **
> 
> > *
> >> Hi
> >>
> >> We need to copy a large number of DASD volumes (from zDASD to
> DS6800).
> >> Any option to speed up?
> >> Seems CONCURRENT is not supported by the zDASD.
> >> Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> 
> --
> Kind regards, / Mit freundlichen Grüßen
> Miklos Szigetvari
> 
> Research&  Development
> ISIS Papyrus Europe AG
> Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
> T: +43(2236) 27551 333, F: +43(2236)21081
> E-mail: miklos.szigetv...@isis-papyrus.com
> Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new
> extended Website at www.isis-papyrus.com
> ---
> This e-mail is only intended for the recipient and not legally binding.
> Unauthorised use, publication, reproduction or disclosure of the content of
> this e-mail is not permitted.
> This email has been checked for known viruses, but ISIS Papyrus accepts no
> responsibility for malicious or inappropriate content.
> ---
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[R.S.]

W dniu 2013-03-07 14:41, Matthew Stitt pisze:

The PARALLEL keyword will cause DSS to start each copy as a sub task
and run them together.  Use SERIAL to single thread the copy if you
wish.


The same can be done by submitting several jobs in parallel, but 
actually we talk about quite poor device - a PC connected to some FBA 
disk array. This is bottleneck.


IMHO the only feasible method is to copy as much as possible in the 
background.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Matthew Stitt]

The PARALLEL keyword will cause DSS to start each copy as a sub task and run 
them together.  Use SERIAL to single thread the copy if you wish.

On Thu, 7 Mar 2013 13:34:15 +0100, Miklos Szigetvari 
 wrote:

>  Hi
>
>The dfdss accepting haply the OPT(4) keyword, the copy time dropped from
>10 minutes to abut 7 minutes.
>The  "real" copy will go from ESCON channels to FICON .
>We have to do this only once, as "BusTech" gave up the support for zDASD .
>
>Thank you
>
>On 07.03.2013 12:37, David Devine wrote:
>> Hi Miklos,
>> I'm making the assumption that your are referring to dfdss.
>> The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by 
>> using the OPT keyword.
>> I believe the default is (3) which is 5 tracks read at at time.
>> OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at 
>> at time.
>>
>> If you are doing a full volume copy i expect your sysin should look 
>> something like this:-
>>
>> COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) -
>> COPYVOLID PURGE OPT(4)
>>
>> or you may use INDD OUTDD for your volume selection
>>
>> Other criteria to consider, region size on your jobcard or pgm; number of 
>> available channels; whether you want to copy your disks when in use or not.
>>
>> Using a product like softek's tdmf will allow for in flight disk copys.
>> If you don't ahve it, then dfdss should only be used for packs when not in 
>> use.
>>
>> With dfdss you need to cater for the volume ids on the source & target 
>> volumes, so you may want to add steps to "clip" (ickdsf reformat) the source 
>> volume before the dfdss copy and "clip" the target volume to the original 
>> source name after the copy.
>> This will keep it isolated and stop inadvertant access to the original 
>> source volume.
>>
>> Good luck!
>>
>> Dave
>> ***
>>> Hi
>>>
>>> We need to copy a large number of DASD volumes (from zDASD to DS6800).
>>> Any option to speed up?
>>> Seems CONCURRENT is not supported by the zDASD.
>>> Kind regards, / Mit freundlichen Grüßen
>>> Miklos Szigetvari
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>
>
>--
>Kind regards, / Mit freundlichen Grüßen
>Miklos Szigetvari
>
>Research&  Development
>ISIS Papyrus Europe AG
>Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
>T: +43(2236) 27551 333, F: +43(2236)21081
>E-mail: miklos.szigetv...@isis-papyrus.com
>Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
>Visit our brand new extended Website at www.isis-papyrus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Miklos Szigetvari]

 Hi

The dfdss accepting haply the OPT(4) keyword, the copy time dropped from 
10 minutes to abut 7 minutes.

The  "real" copy will go from ESCON channels to FICON .
We have to do this only once, as "BusTech" gave up the support for zDASD .

Thank you

On 07.03.2013 12:37, David Devine wrote:

Hi Miklos,
I'm making the assumption that your are referring to dfdss.
The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by 
using the OPT keyword.
I believe the default is (3) which is 5 tracks read at at time.
OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at at 
time.

If you are doing a full volume copy i expect your sysin should look something 
like this:-

COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) -
COPYVOLID PURGE OPT(4)

or you may use INDD OUTDD for your volume selection

Other criteria to consider, region size on your jobcard or pgm; number of 
available channels; whether you want to copy your disks when in use or not.

Using a product like softek's tdmf will allow for in flight disk copys.
If you don't ahve it, then dfdss should only be used for packs when not in use.

With dfdss you need to cater for the volume ids on the source & target volumes, so you may want to 
add steps to "clip" (ickdsf reformat) the source volume before the dfdss copy and 
"clip" the target volume to the original source name after the copy.
This will keep it isolated and stop inadvertant access to the original source 
volume.

Good luck!

Dave
***

Hi

We need to copy a large number of DASD volumes (from zDASD to DS6800).
Any option to speed up?
Seems CONCURRENT is not supported by the zDASD.
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Miklos Szigetvari]

Hi


Thank you

We will migrate from the zDASD to DS6800 .
We need to make a physical copy while the systems are down.
We will use a backup system and we would like to speed up something like 
this:

COPY FULL INDYNAM(HFS039) OUTDYNAM(RESML1) COPYVOLID -
ALLDATA(*) ALLEXCP ADMIN

Funny but for the COPY , I didn't find the OPT keyword .

07.03.2013 12:43, Elardus Engelbrecht wrote:

Miklos Szigetvari wrote:


We need to copy a large number of DASD volumes (from zDASD to DS6800).
Any option to speed up?

Format/Init and then copy? :-D

Sorry, but I can't resist above... Yes I saw Radoslaw's excellent comment.


Seems CONCURRENT is not supported by the zDASD.

Questions:
Do you want a physical or logical copy? Or do you need something like 
peer-to-peer copy or a variant of it?

Do you need instant copy? Copy while datasets are in use?

IMHO, I think you should describe your copy needs in details?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[Elardus Engelbrecht]

Miklos Szigetvari wrote:

>We need to copy a large number of DASD volumes (from zDASD to DS6800).
>Any option to speed up?

Format/Init and then copy? :-D

Sorry, but I can't resist above... Yes I saw Radoslaw's excellent comment.

>Seems CONCURRENT is not supported by the zDASD.

Questions: 
Do you want a physical or logical copy? Or do you need something like 
peer-to-peer copy or a variant of it?

Do you need instant copy? Copy while datasets are in use?

IMHO, I think you should describe your copy needs in details?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[David Devine]

Hi Miklos,
I'm making the assumption that your are referring to dfdss.
The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by 
using the OPT keyword.
I believe the default is (3) which is 5 tracks read at at time.
OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at at 
time.

If you are doing a full volume copy i expect your sysin should look something 
like this:-

COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) -
COPYVOLID PURGE OPT(4)

or you may use INDD OUTDD for your volume selection 

Other criteria to consider, region size on your jobcard or pgm; number of 
available channels; whether you want to copy your disks when in use or not.

Using a product like softek's tdmf will allow for in flight disk copys.
If you don't ahve it, then dfdss should only be used for packs when not in use.

With dfdss you need to cater for the volume ids on the source & target volumes, 
so you may want to add steps to "clip" (ickdsf reformat) the source volume 
before the dfdss copy and "clip" the target volume to the original source name 
after the copy.
This will keep it isolated and stop inadvertant access to the original source 
volume.

Good luck!

Dave
***
> Hi
>
> We need to copy a large number of DASD volumes (from zDASD to DS6800).
> Any option to speed up?
> Seems CONCURRENT is not supported by the zDASD.
>Kind regards, / Mit freundlichen Grüßen
>Miklos Szigetvari

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speed up DASD copy

[R.S.]

W dniu 2013-03-07 11:36, Miklos Szigetvari pisze:

Hi

We need to copy a large number of DASD volumes (from zDASD to DS6800).
Any option to speed up?
Seems CONCURRENT is not supported by the zDASD.



For obvious reasons you cannot use FlashCopy or similar PiT techniques, 
the same for PPRC,SRDF, etc.


So, you can try to optimize dss copy process, replace dss with something 
faster (IMHO marginal gain) or use specialized software for data 
migration - like TDMF. Note the last will not make the process faster, 
put the migration to the background. Of course it's not free.


Last, but not least: for application data, which should be SMS-managed, 
you can use COPY "in place" while old volumes are in DISNEW state and 
new volumes are added to the storage groups. Similar technique can be 
used for DB2 data and other. As result you will have to move only few 
system volumes.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Speed up DASD copy

[Miklos Szigetvari]

Hi

We need to copy a large number of DASD volumes (from zDASD to DS6800).
Any option to speed up?
Seems CONCURRENT is not supported by the zDASD.

--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN