IBM Mainframe Forum

We have a problem FTP'ing VB files that are on tape - the RDW is being dropped. When the dataset is on disk, the RDW is preserved and there are no issues. Do you know what would cause this to happen? The FTP syntax is below...

For better or worse, FTP is operating as designed. Yhe RDW is not sent in a binary transfer.

U was called away while writing my previous post. To continue:

A Unix file is just a stream of bytes. It has no attributes like record format and logical record length as is true of datasets in z/OS. There are no records as we understand them in OS/360 type datasets, so FTP just sends the stream of bytes in a binary transfer. An RDW in a RECFM=VB dataset is non-data control information so it is not sent. RECFM=FB datasets can be reconstructed in Unix because the records are fixed in length, but this is not true of RECFM=VB datasets. You can send RECFM=VB datasets to Unix as a text file because FTP will insert a newline character at the end of each logical record, and FTP will translate text data from EBCDIC to ASCII, but this translation is not always very consistent for non-text data, or for text data like the left and right square brackets that do not have a consistent EBCDIC definition.

When the dataset is on disk, the RDW is preserved and there are no issues.

If you are using the same FTP parameters, then the RDW would not be preserved. Binary FTP transfers of files with variable length files are going to lose the RDW (no matter if the source is tape or disk) as the RDW is not considered part of the record. Without doing some kind of special action, as far as I know it is not possible to successfully transfer using binary a file with variable length records to a Unix system and retain the record structure.

Robert Sample wrote:... it is not possible to successfully transfer using binary a file with variable length records to a Unix system and retain the record structure.

The same is true of datasets with "undefined" records such as load module members.

Gentlemen,

RDW can apparently be sent!

See File Transfer Protocol (FTP) - A List of FTP Commands

Good hunting, Prino.

Needs to be checked upon. Rest of the page seems to talk only of Unix and Windows. May have been pasted uncredited from elsewhere.

The BDW preceding the RDW on occasion is a little trip-up waiting to happen. Would need some work to handle.

prino wrote:Gentlemen,

RDW can apparently be sent!

See File Transfer Protocol (FTP) - A List of FTP Commands

IF mode is STREAM and transfer type is IMAGE (binary).

MrSpock wrote:

prino wrote:Gentlemen,

RDW can apparently be sent!

See File Transfer Protocol (FTP) - A List of FTP Commands

IF mode is STREAM and transfer type is IMAGE (binary).

Also for ASCII, but in this case you may not get what you want:

z/OS:

Windoze:

And the 0017 is a EBCDIC-ASCII translation of x'26', aka 38. In other words, the RDW is sent, includes the length of itself, but it's also translated to ASCII...

Well, that is useful on a scale of zero to zero. Translate it back before using it...

I guess for the BDW it is not really a problem as I assume you get the whole block at once. Then convert it from ASCII....

However, it is always pointless doing both a BINARY transfer and a character-set translation, isn't it?