[6394] in APO-L

home help back first fref pref prev next nref lref last post

FTP Site Problems....(possible Solutions)

daemon@ATHENA.MIT.EDU (Scott Begin)
Tue Jun 29 15:51:11 1993

Date:         Tue, 29 Jun 1993 19:26:00 GMT
Reply-To: Scott Begin <0005555440@mcimail.com>
From: Scott Begin <0005555440@mcimail.com>
To: Multiple recipients of list APO-L <APO-L%PURCCVM.BITNET@mitvma.mit.edu>

I have received several messages indicating that the APO-L.* files seem to
be garbage.

I think most of the problems stem from differences in computer systems,
most notabley between DOS and Unix.

The APO-L.* files are text files, 125 characters max line length.  They
were origionally created on a IBM PC (MS DOS), uploaded to Delphi (VAX
running VMS), and FTP'd to vtucs.cc.vt.edu (UNIX)

Each of these computers uses ASCII as the main character set.  However,
each handles text files in a slightly different manner.  DOS uses a CR-LF
combination to designate an end of line (Character 13 followed by
Character 10; Chr 13 is ^M and Chr 10 is ^J).  Unix uses a single LF
character (Character 10) to mark the end of a line.  I don't remember what
a VAX uses (I'll check when I get back to work on thursday), so I'm not
sure if that caused a problem.  I know when I uploaded the files to
Delphi, I used a binary transfer (which probably didn't translate CR-LF).
When I FTP'd them to the site, it probably preserved the eoln characters.

For those experiencing ^M^J and no line breaks, it seems that when you
FTP'd the files to your Unix machine, it knew you were getting files from
a unix machine, and didn't translate the text.

As for Nathan Brindle, (no description of the problem), I wonder if you
experienced a EBCDIC vs ASCII translation problem (since your address
indicates like you are using an IBM running CMS), which may have been
compounded by the MS DOS format in a Unix file system problem. (Yes,
Nathan, I tend to believe from previous conversations that you would have
looked at that, but.....)

In any case, the first suggestion I have is to try downloading the file to
an IBM PC (as a binary file, so no end of line translation takes place)
and examine the file there.  Theoretically, it should be fixed.  If that
doesn't work, I'll prepare a Unix version of the file an upload it
tonight.  I have a program that will convert files between the different
formats, there may be one available on your system (although I have the
source which could be compiled on a Unix system if you know what you are
doing).

One other thought I had (may or may not be the case, I'm not as familiar
with FTP as I'd like to be) is that FTP retrevial of text files is limited
to text files with line lenghts less than 80 characters.  It would have
been a problem with the previous files, but it is something to look into.

I'll let you know when I get the new files up.

Scott A. Begin      Epsilon Beta Alumni, Central Michigan University
SBEGIN@mcimail.com  Chapter List Maintainer

home help back first fref pref prev next nref lref last post