Ok, back with ftp then. It keeps thing a little simple. As Americans, they should know that they must document that you cannot dry your cat in the microwave. If ftp cannot handle the standard recfm=u format, it should be corrected or documented, not left to the customer to discover it (crashing a system or a migrationproject).
Can anyone from IBM comment on this? Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: 07 November 2019 09:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another >Did you transport the catalog dump dataset with ftp? Yes. I started out just adrdssu dumping the catalog, then ftp'ing. After restore and import the catalog was broken. Putting terse between the dump and ftp fixed the problem. >If yes, this might again point to ftp. >If not, the problem must be in the dump dataset. Then DFdss dump produces (can >produce) a non-standard recfm=u dataset, that will be processed correctly by >dfdss restore, but might confuse other programs reading it. This should be >documented with DFdss in my opinion. I believe that I later checked about the difference between the untersed dump and the tersed dump with regard to ftp. But I had already lost enough time trying to get things working, so I just blamed ftp. As for documentation - IBM does not document what doesn't work. It always reminds me of my IBM level2 days when I sat beside an IBM developer trying to figure out a problem. It turned out that the customer did something he should not have done, so the developer said "We don't document that you cannot wash dishes with a CPU!" Barbara ---------------------------------------------------------------------- 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: http://www.klm.com. 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
