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
