Suppress Carriage Return Character during FTP

vgmurthy · New User Joined: 19 Feb 2008 Posts: 8 Location: Chennai

Hello Everyone!

Need your assistance on an FTP Issue.

The background:
We use FTP to transfer files from Unix system to Mainframe host. My Mainframe Job logs into Unix Server and GET the file onto a Mainframe flat file. The source for this Unix box is a "File System" box

The Issue:
One of the file at Unix uses x'0D' as a delimiter. (We at Mainframe host have no control on what could be sitting on the file). When I try extracting the file from the Unix box, the x'0D' is intepreted as Carriage Return(CR) character and the rest of the data is written on to the next line.

Help:
I tried the following locsite options:
UNICODEFILESYSTEMBOM=ASIS/NEVER/ALWAYS
SBSENDEOL=NONE
MBSENDEOL=NONE
NOREMOVEINBEOF

Can anyone please throw some light on how to stop interpreting the CR character, to avoid data being written to next line?.

I have set the TYPE as ASCII for FTP transfer. Even tried to change the format to Binary, but in vain. The extracted dataset looks holding bad data.

I have attached my input file and output file for your reference.

Appreciate your help.
Thanks,
Venu

[img][/img]

Robert Sample · Posted: Tue Apr 26, 2011 5:29 am

MBSENDEOL and SBSENDEOL only have a bearing when sending data to the server -- using the GET command means neither of them will do anything.

What does the file have for end of line if X'0D' is used in other ways? You could try setting up a translate table to convert the X'0D' to spaces but you need to know what the end of line character is. Alternatively, you may have to reconstruct each line from the multiple lines on the mainframe.

The best solution would be to get the file on the Unix server to start using standards (like spaces instead of X'0D' for separators), but the best solution is not always possible.

superk · Posted: Tue Apr 26, 2011 5:40 am

When confronting this situation in the past, dealing with ANSI EDI data that unfortunately used a LF as a segment terminator, the best solution I could come up with is to FTP the data in binary mode, wrapping the file into fixed-length records. Then, I'd use Unix System Services to convert the data from ASCII to EBCDIC, and then write a program to un-wrap the data disregarding and/or converting the LF to some other character. Sorry.