IBM Mainframe Forum

Hi,

I need to receive a file from Unix server in Binary format via connect direct into a Mainframe VB file. After the file transfer onto Mainframe the records are coming onto the same line.i.e say Record1 and Record 2 in Unix is coming onto Mainframe as a single record until it reaches the record length.Once the length exceeds it spills over to the next record.

The same file when transferred in text format having /n (unix new line char) via connect direct is coming properly into separate records at Mainframe end.Could you pls let me know why new lines work with Text format transfer in connect direct and does not work for Binary format transfer ? Also is there a command that needs to be specified for binary transfer in connect direct that would help having new records in Mainframe.

From Mainframe to Unix transfers I have previously used for text transfer; '0D25' and for BINARY transfer '0D0A'.Is there some data that needs to added at UNIX end that will have similar effect to the files received on Mainframe.

Thanks,
Navya

When doing any kind of transfer, binary means character-for-character; text means translation occurs during the transfer. What this means is that record delimiters will be placed in text transfers, while binary transfers will not have record delimiters. And since Unix uses a different file format than the mainframe, a binary transfer usually means the data winds up unusable and unreadable on the receiving system. This is the way file transfers work -- there is nothing you can change or any parameter you can set that will cause a binary transfer to include record delimiters -- period.

You would have essentially the same problem attempting to send a data set containing variable length records or undefined length records as a "binary" data set. This is an issue that has bothered me for many years.

Back in the days when I was a product support tech for an ISV we were often on the receiving end of these transfers. Since I seemed to understand what was really going on, my colleagues often asked for my assistance to straighten out the data. V and U data was usually impossible. F data I could often figure out the LRECL and re receive the data set it since it went to an intermediate FTP server. I prepared a document for my colleagues to help them guess whether a file on the FTP server was an uncompressed IPCS type dump or a data set compressed by the "terse" utility just using the file length, which accounted for most of the data.

At the time I tried to deduce the logic behind not sending RDW data for data sets containing variable length records in a binary transfer. After some thought I concluded RDW data is considered to be control data and not properly data, so it shouldn't be sent. But I was never fully comfortable with that theory. After all, carriage control data for print data sets is set, but the data, by any analysis is "control" data.