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. <[email protected]> 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. <[email protected]> > 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 <[email protected]> On > >> Behalf Of R.S. > >>> Sent: Tuesday, July 14, 2020 1:23 PM > >>> To: [email protected] > >>> 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: [email protected]. 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: [email protected]. 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
