On Monday, 09/22/2008 at 02:10 EDT, gah <[EMAIL PROTECTED]> wrote: > > The defect exists in the ftp client, not the servers. > > In text mode (also called ASCII mode) the form on the TCP > stream is CRLF terminated. It is the responsibility of > both client and server to convert from native text form > to that form. > > For unix, that means both server and client convert from > X'0a' termination to X'0a0d' termination. > > The traditional CMS file formats would be either FB or VB, > and both client and server should be able to do that. > > If (and I don't know one way or the other) unix files are > considered native in current VM/CMS then client and server should > be able to do the conversion. Specifically, under OpenVM: > > http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v > 53.dmsp3/osmask.htm
I'm not sure what you're getting at, Glen, but it has been alleged that some systems do NOT convert LF to CRLF on ASCII/TEXT mode transmissions. Looking at Debian's ftp client and vsftpd, it would appear they do the right thing, but it would be great if a few folks would try various clients and servers and confirm the behavior. The z/VM FTP client and server both look for CRLF to delimit the records. The file format (F or V) is not relevant except that it affects the maximum length of a record in a text transmission. Alan Altmark z/VM Development IBM Endicott
