I sustain all of the worries except problems with ftp and RECFM=U.
It is still better to avoid unnecessary ftp step. Shared DASD solve it.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 14.07.2020 o 16:47, Joe Monk pisze:
I would agree with you if this weren't an LPAR to LPAR copy. So, there's a
direct connection between the LPARs, and most of the worries that you are
concerned about dont really exist in that situation.

Joe

On Tue, Jul 14, 2020 at 9:39 AM R.S. <r.skoru...@bremultibank.com.pl> wrote:

Because of reasons. ;-)
Seriously: it is better to make it simpler and faster.

Your method: dump, ftp, restore.
Other methods: a) dump, restore. b) copy.
Which is faster?
Which consume less CPU?
Which require less disk space for intermediate copies?

Not to mention issues with RECFM=U and ftp.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 14.07.2020 o 15:26, Joe Monk pisze:
Why not just dump them, FTP the dump file between the two partitions,
then
restore the dump file?

Joe

On Tue, Jul 14, 2020 at 8:11 AM R.S. <r.skoru...@bremultibank.com.pl>
wrote:
Well, that change the perspective. It's a pity you didn't mention it
before ;-)
In this case one step is better (faster) than two-step approach.
However in this case you should share catalog (BCS). Then you can try to
share storage group.
Or do it from target system - you still need to share volumes and BCS,
but you can read datasets from "foreign" volumes and write them to
target volume.
Caution: sharing catalog usually means unique dataset names. Do you
accept dataset rename, i.e. change of HLQ?
Of course it is possible to rename dataset names after that or maybe use
some paths and aliases.

Another approach is to divide the task. You submit dump of first part,
then submit restore on target. Then submit second part dump, and after
that restore... It's still two-step, but temporary storage is not so
big. Or use tape...

--
Radoslaw Skorupka
Lodz, Poland






W dniu 14.07.2020 o 12:44, Gadi Ben-Avi pisze:
Thanks
I guess I'll have to bite the bullet. It's 393GB of files.

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of R.S.
Sent: Tuesday, July 14, 2020 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Copying Extended format datasets between partitions

You cannot do it.
Both datasets require to be DFSMS-managed and then cataloged.
So you have to share the catalog (BCS), otherwise you will get error or
uncataloged datasets on SMS volume, which is also not the best idea.
Another method: dump you datasets to PS file on shared volume. Then
restore it on target system. Much easier and less error-prone.
--
Radoslaw Skorupka
Lodz, Poland






W dniu 14.07.2020 o 12:06, Gadi Ben-Avi pisze:
HI,
I have to copy extended format (PS-E and VS-E) datasets between
partitions.
The partitions share DASD but do not share anything else.
They have different SMS configurations.
The same Storage Group is defined in both partitions, but each
partition has different volumes.
I've been copying datasets between partitions like these for a while
using this DFSMSdss copy command:
COPY DATASET( -
       INCLUDE( -
       SYS1.IOA.V919.LNKLST -
       SYS1.IODF24.CLUSTER -
       )) -
       REPLACE    -
       TOL(ENQF) -
       BYPASSACS(**) -
       NULLSTORCLAS  -
       PROCESS(SYS1)  -
       ALLDATA(*) ALLEXCP -
       RECATALOG(ICFCAT.MCATZ23) -
       OUTDYNAM(Z23R01) -
       SHARE

The catalog in the RECATALOG parameter is the catalog for the
destination partition.
Does anyone have an idea how to do this for SMS managed extended
format
datasets?





======================================================================

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Reply via email to