Barbara, Did you transport the catalog dump dataset with ftp? 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.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: 07 November 2019 06:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another >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. And just to add my two cents: A few years back I tried to migrate a (user) catalog from one RDT lpar (where I had things customized) to another RDT lpar (at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS imported the catalog with RC=0, but the content was completely unusable. Trying to access any data set in that catalog on the DASD (that had also been migrated, but not via ftp) resulted in a plethora of strange rc/rsn combinations that really didn't make any sense. I eventually tersed the catalog dump and untersed/restored/imported on the other side. Now the data sets were accessible without any problems. I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I need to send it somewhere via ftp otherwise the results could get unpredictable. I don't think there's anything worse than a dataset that may or may not have been altered subtly. Don't take any chances, even if this is not clearly documented anywhere. Regards, 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
