I'd probably be inclined to use a TERSEd DFDSS dump, too - but that's just because I don't implicitly 'trust' (read: 'understand') UNIXy things.
One such 'thing' I was shown was: tar -cf - <srcdir> ¦ ssh <targsys> -l <userid> "cd <targdir> ; tar -vxf -" Apparently this means something like: "create a tar ball of <srcdir> on stdout then pipe it through to stdin for input to an un-tar command, after logging on to logging on to <targsys> and cd-ing to <targdir>" It worked without a problem the only time I used it but, as I say, I was too darn scared of using it again. Too many possible ways of screwing up, as far as I was concerned. Sean On Wed, 6 Nov 2019 at 15:45, David Spiegel <dspiegel...@hotmail.com> wrote: > Hi Itschak AMV"SH, > Why did you use IDTF format instead of TRS? > > Regards, > David > > On 2019-11-06 10:22, ITschak Mugzach wrote: > > Kees, > > > > Dfdss in general is not ftp freindly. When we faced that in a large data > > movement project, we used xmit to convert the file format to xmt on one > > side and rexyeive it on the other side. > > > > ITschak > > > > > > > > בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM < > > kees.verno...@klm.com>: > > > >> So do we. > >> > >> And I wonder what the actual problem is? If the DFDSS dump dataset has > >> such a special (internal) format, that FTP cannot always handle it > >> correctly, why can AMATERSE do this without problems? > >> > >> If it FTP only, what is the special problem for FTP? What other dataset > >> formats are a problem for FTP? > >> > >> Questions, Fear, Uncertainty and Doubt... > >> > >> Kees. > >> > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of Lizette Koehler > >> Sent: 06 November 2019 16:11 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Zfs from 1 LPAR to another > >> > >> I have always FTP a DFDSS dump of "things" - What I was told to do long > >> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS. > >> > >> This has never caused an issue (DFDSS ignores the Blksize). And my > >> Transfer have (knock wood) not failed. And I have always been able to > >> restore from the DFDSS dump. > >> > >> > >> Lizette > >> > >> > >>> -----Original Message----- > >>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > >>> Behalf Of Vernooij, Kees (ITOP NM) - KLM > >>> Sent: Wednesday, November 06, 2019 8:02 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Zfs from 1 LPAR to another > >>> > >>> Can you point to where that is documented? > >>> We FTP a lot b.m.o. DFDSS between Sysplexes. > >>> > >>> Kees. > >>> > >>> -----Original Message----- > >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >>> On Behalf Of Tom Conley > >>> Sent: 06 November 2019 15:46 > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Zfs from 1 LPAR to another > >>> > >>> On 11/5/2019 6:54 PM, Jousma, David wrote: > >>>> Terse, dont terse, your call. I have 100% reliability as long as > >>>> the > >>> destination disk dataset for the ftp is newly created. If the > >>> destination dataset already exists, then yes, there have been problems. > >>>> As you mention there are some specific options on the transfer to > >>>> specify, > >>> and as long as you do, it will work fine. > >>>> Sending the dump file outside the company, probably not bad idea to > >>>> terse > >>> since we are all familiar with it. > >>>> ____________________________________________________________________ > >>>> __ > >>>> _______________________________ > >>>> > >>>> Dave Jousma > >>>> > >>>> AVP | Manager, Systems Engineering > >>>> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > >>>> Rapids, MI 49546 > >>>> > >>>> 616.653.8429 | fax: 616.653.2717 > >>>> ________________________________ > >>>> From: Tom Conley <pinnc...@rochester.rr.com> > >>>> Sent: Tuesday, November 5, 2019 5:17 PM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Re: Zfs from 1 LPAR to another > >>>> > >>>> > >>>> **CAUTION EXTERNAL EMAIL** > >>>> > >>>> **DO NOT open attachments or click on links from unknown senders or > >>>> unexpected emails** > >>>> > >>>> On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > >>>>> I always terse the dump file too. Had issues with Restore if the > >>>>> file wasn't tersed. > >>>>> > >>>>> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud <pr...@videotron.ca> > wrote: > >>>>> > >>>>>> Dave, > >>>>>> I'll do that. The files are not big. > >>>>>> They can be sent as ZIP files. > >>>>>> Thanks, Pierre > >>>>>> > >>>>>> ------------------------------------------------------------------ > >>>>>> -- > >>>>>> -- 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 > >>>>> > >>>> Wayne beat me to it. Terse any DFDSS file before sending. You may > >>>> get away with DFDSS with mode block and EBCDIC. Until you don't. > >>>> Terse it for 100% reliability. > >>>> > >>>> Regards, > >>>> Tom Conley > >>>> > >>> Dave, > >>> > >>> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR > >>> that needed it. Worked fine, until it didn't. IBM's response to the > >>> PMR that I opened is that the only 100% reliable way to FTP a DFDSS > >>> dump file was to terse it first. IBM does not support direct FTP of a > >>> DFDSS dump file. So I now terse every DFDSS dump file before FTPing > >>> it to other systems, and I haven't had another failure in 6 years. As > >>> I said, it will work until it doesn't. > >>> > >>> Regards, > >>> Tom Conley > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, send > >>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >>> ******************************************************** > >>> For information, services and offers, please visit our web site: > >>> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7C%7C4f4abcacf8df4e6070d108d762cd48ba%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637086506186117599&sdata=UpBba6fgvR%2FG7uBPIMfdGt1rHxBeXCSOEa%2BFiiM1MAs%3D&reserved=0. > This e-mail and any attachment may contain > >>> confidential and privileged material intended for the addressee only. > >>> If you are not the addressee, you are notified that no part of the > >>> e-mail or any attachment may be disclosed, copied or distributed, and > >>> that any other action related to this e-mail or attachment is strictly > >>> prohibited, and may be unlawful. If you have received this e-mail by > >>> error, please notify the sender immediately by return e-mail, and > delete > >> this message. > >>> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > >>> its employees shall not be liable for the incorrect or incomplete > >>> transmission of this e-mail or any attachments, nor responsible for any > >> delay in receipt. > >>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > >>> Dutch > >>> Airlines) is registered in Amstelveen, The Netherlands, with > >>> registered number 33014286 > >>> ******************************************************** > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> 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 > >> ******************************************************** > >> For information, services and offers, please visit our web site: > >> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7C%7C4f4abcacf8df4e6070d108d762cd48ba%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637086506186117599&sdata=UpBba6fgvR%2FG7uBPIMfdGt1rHxBeXCSOEa%2BFiiM1MAs%3D&reserved=0. > This e-mail and any attachment may contain > >> confidential and privileged material intended for the addressee only. If > >> you are not the addressee, you are notified that no part of the e-mail > or > >> any attachment may be disclosed, copied or distributed, and that any > other > >> action related to this e-mail or attachment is strictly prohibited, and > may > >> be unlawful. If you have received this e-mail by error, please notify > the > >> sender immediately by return e-mail, and delete this message. > >> > >> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its > >> employees shall not be liable for the incorrect or incomplete > transmission > >> of this e-mail or any attachments, nor responsible for any delay in > receipt. > >> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > >> Airlines) is registered in Amstelveen, The Netherlands, with registered > >> number 33014286 > >> ******************************************************** > >> > >> > >> ---------------------------------------------------------------------- > >> 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 > > . > > > > > ---------------------------------------------------------------------- > 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
