On Tue, 15 Jan 2013 07:01:44 +0100, [email protected] <[email protected]> wrote:
>> As noted, this fails on the empty record problem. However, for RECFM=U >> (possibly via DD override) and z/OS-to-z/OS, >> >> BINARY >> PUT >> >> works. (Of course, DD override is not possible on GET. Might need >> LABEL=SL.) >> They seem to have fixed something! IIRC, attribute override on the DD >> statement >> used not to work; it seemed to look at the DSCB regardless. > >Not my recent experience, not even with a BLKSIZE less than 32K and >preallocated receiving data set. While the ftp finished, the receiving system >told me that it was not an adrdssu dump at all and would not read it. >I would also suggest to wrap this into an amaterse file. Have amaterse create >a *.trs file, ftp that *.trs file, unterse on the receiving side (back to >tape, if you want to), and then restore via adrdssu. > For z/OS to z/OS, I have FTPed DFDSS format dumps directly with no problem. From disk to tape or disk to disk. Tape, without changing the BLKSIZE is a problem. I think Barbara mentioned she has done this, but I never tried overriding it. I think I mentioned this before, but for FTPing full volume dumps, tape to tape, I prefer to use FDR with "FORMAT=SPLIT" which restricts the BLKSIZE to 32K. Then as already has been posted several times you use "MODE B" and "TYPE E" (or EBCDIC). Tersing and untersing as an extra (CPU intensive) unnecessary step if you are FTPing between z/OS systems. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
