>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
