Like I said, the RFC says text data is sent as ASCII with CR/LF at the end of each record.
If the data is sent as binary, then the file is sent as is. No translation takes place and no record separators are added by the sender. ____________________ Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586 Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -----Original Message----- From: CMSTSO Pipelines Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, April 13, 2011 11:08 AM To: [email protected] Subject: Re: Issue with FTP REXX On Apr 13, 2011, at 08:57, Hughes, Jim wrote: > The RFC for ftp says text data is placed on the wire in ascii with a > carriage return/line feed at the end of the line. However not all > systems put CR/LF at the end of the records. > > Without getting into a religious battle, here is a pipeline we use. We > get files from our ftp server in binary mode and then process it with a > pipeline similar to this one. > > "PIPE < consumer binary a |", > " deblock linend 0a |", > " strip trailing 0d 1 |", > " xlate from 819 to 1047 |", > " > consumer text a" > Hmmm. Classic Macintosh use[sd] as a line separator, but I don't know that these were ever placed on the wire. But I believe HTTP allows any of CR/LF, LF, or CR as a line separator. A challenge to deblock these accepting the constraints that: o The CR and LF may be split between packets. o The entire file transmitted may be too big to fit in memory and/or it's desirable to stream it in real time. -- gil
