FTP from Windows to UNIX adds /CR at end

[Danny Wheeler]

I have all interfaces in Cloverleaf set to encode in binary and use eof style.  I have set up a test interface that FTP’s to a local Windows server we have and everything is fine(meaning /CR is not there).  When I transfer this file to our vendor who is using a UNIX FTP site it adds the /CR at the end.  I also read somewhere that to fix this you can run ASCII as the encoding on all interfaces.  This did not help either.  Has anyone had this issue before and how did you resolve it?

Topic

[James Cobane]

Danny,

Do you have the ‘FTP Options’ set to image/binary in the protocol set-up on the thread as well?

Jim Cobane

Henry Ford Health

[Danny Wheeler]

Yes.  I have tried them with ASCII as well.

[James Cobane]

Have you tried to manually FTP from the Server (from the command line) in binary mode to see what happens on the other end?  Also, I’m assuming when you state that the /CR’s are there, you mean that you are seeing x0D x0A (CR/LF) when you only want x0D (CR) after each segment, correct?

Jim Cobane

Henry Ford Health

[Danny Wheeler]

Yes.  I have tried them with ASCII as well.

[James Cobane]

May want to have the receiving system take a look at how they are processing the data.  If you are able to move it successfully to other servers using the same configuration, then evidence points to the receiving system as the offender.

Jim Cobane

Henry Ford Health

[John Stafford]

Danny,

I am having what I feel is a similar issue. We upgraded to CL 6, and one of our outbound FTP interfaces has started adding an extra linefeed character at the end of the file.

This was a raw route with only a directory parse on the inbound and an outbound TPS to append a timestamp to the file name. Otherwise, my settings are similar to yours: image/binary wherever applicable.

As it turns out, our production version of the interface was using ‘single’ style for writing the file, while our test version was on ‘nl’. A nl in AIX is a linefeed, so changing that addressed the issue.

[Danny Wheeler]

I ended up discovering that UNIX FTP servers translate a CR to a LF as there is no CR in UNIX (I may be wrong about that but that’s how I understood it).  I wrote this little TCl script to remove them before they went to the FTP server.  This has fixed our issue.

Code:

######################################################################
# Name: tps_remove_CR_LF
# Purpose: Remove Carriage return and Line Feed.
# UPoC type: tps
# Args: tps keyedlist containing the following keys:
#       MODE    run mode (”start”, “run” or “time”)
#       MSGID   message handle
#       ARGS    user-supplied arguments:
#              
#
#
#        
#

proc tps_remove_CR_LF { args } {
   keylget args MODE mode               ;# Fetch mode

   set dispList {} ;# Nothing to return

   switch -exact — $mode {
       start {
           # Perform special init functions
   # N.B.: there may or may not be a MSGID key in args
       }

        run {
           # ‘run’ mode always has a MSGID; fetch and process it
           
           keylget args MSGID mh

set rawmsg [msgget $mh]
regsub -all {x0D} $rawmsg {} msg1
regsub -all {x0a} $msg1 {} msg2
#set length [string length $rawmsg]
#set end [expr $length – 2]
#set final [string range $rawmsg 0 $end]
msgset $mh $msg2
#echo $final

  lappend dispList “CONTINUE $mh”
       }

       time {
           # Timer-based processing
   # N.B.: there may or may not be a MSGID key in args
       }
       
       shutdown {
   # Doing some clean-up work
}
   }

   return $dispList
}

[Author]

Replies