I am doing FTP from a server and getting below ERROR:
WARNING! 16126 bare linefeeds received in ASCII mode
File may not have transferred correctly.
I looked into web and found that I may need to change the mode to binary, but when I do so the records are not in readable format...So need the file in ascii so that I can use it in our ETL.
below is the script:
ftp -n $SERVER <<EOF>./ftp.log
user $USER $PASSWD
ascii
cd ..
cd $DIR
get $FTP_FILE $LOCAL_FILE
bye
EOF
What is the ftp server's O/S. What do you mean by unreadable? What is the ftp client's O/S. Did you try a different client like filezilla? Te ftp script is not the issue.
A "mainframe" might supply differently coded files, e.g. EBCDIC. Try to transfer the file in binary mode and then convert it using e.g. iconv or recode .
dd if=oldfile of=newfile conv=ascii gives you a file converted from EBCDIC to ASCII. The only caveat is: do you have packed decimal data (raw "binary" formatted numbers) coming in from the mainframe - dd will not handle that.
If you have packed data on the server, your best bet will be to unpack the data on the server to a straight text format either in ASCII (if you can which won't require any further conversion after you upload your data) or in EBCDIC (in which case you can then use dd to convert the EBCDIC to ASCII after you upload your data).
Consider getting one of the mainframe coders to write a small bit of ANSI COBOL. Use that to transform the packed data.
Here is a discussion of the COBOL needed. Packed Decimal
IF you have Microfocus COBOL on UNIX you can compile and run it there on the UNIX box. If you really want to spend some time consider C. There is not much I can see out there in the way of C code to convert packed decimal data.
We had a similar requirement to transfer vast amounts of data across a small network link from one site to another. We used PKZip from PKWare to achieve it. There is a cost to the software I think, but it did the job beautifully. We closed our window for data transfer from 38 hours to about 6 - obviously we had plenty of CPU available to do the compression part.
Results will vary depending on the data volume, data structure, the CPU available and the network speed, but it was pretty impressive. The EBCIDIC to ASCII conversion was handled, but we could not send packed data and we had to be careful with unusual characters, e.g. those with accents etc.
I'm sure other vendors may also be able to help you too.
Thanks all for your reply..As per the suggestion we are talking to vendor if then can unpack the data at their end...hope it will help, else I will come back to you..