Because TRS produces FB records, whereas, DFSMSdss produces RECFM=U records.
On 2019-11-06 10:17, Vernooij, Kees (ITOP NM) - KLM wrote: > 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://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7C%7Cd7713c39c0014bae14d808d762cc86d0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637086502902466082&sdata=6MRc7HkHKQ%2F8wMUfxpolvnOQtdHt%2F%2Fu3gUaU%2Bic5MSU%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://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7C%7Cd7713c39c0014bae14d808d762cc86d0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637086502902466082&sdata=6MRc7HkHKQ%2F8wMUfxpolvnOQtdHt%2F%2Fu3gUaU%2Bic5MSU%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