HP3000-L Archives

January 2003, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Tue, 14 Jan 2003 16:40:18 -0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
---- Original Message ----
From: "Tony Summers" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, January 14, 2003 2:37 PM
Subject: [HP3000-L] FTP - Binary or Ascii ?

> Silly question.  Can someone explain the difference between Binary
> and Ascii FTP transfers ?

At a guess, ASCII transfers detect and respect CR and/or LF, and recreate
these at the other end, according to the 'line ending' conventions of the
sending and receiving platforms.

I'd also expect an ASCII transfer to terminate on encountering an ASCII EOF.

On a binary transfer, it's a pure byte-shovelling exercise up to a count, and
CR, LF and EOF, are just seen as bytes to be transferred.
But if you do an ASCII transfer of a binary file, it will try to respect the
'line-breaks', as it sees them, and stop at the first byte that looks like an
ASCII EOF.

The HP3000, which doesn't have the same ASCII and Binary conventions as a PC,
say, complicates matters even further. There's an 'implied' CR/LF, not an
explicit one, at the end of each ASCII record, and FTP may well add an
explicit one, perhaps after stripping its trailing spaces. And then
reconstitute it at the other end on the target HP3000; fine if the file really
*was* ASCII, but if it's binary, there may be an apparent CR halfway down the
first record, so two records will arrive where only one left (hence you
blowing the target file size). Or apparently redundant trailing space, which
was actually important binary space, may be lost.

And binary, which to FTP is just a bytestring, needs to be laid back down
record by record for the HP3000 to 'see' it correctly.

As you surmise:

> My own  thoughts are that Vfast files really contain binary data
> (have you ever tried to print one?) so the file type is slightly
> misleading - these files really should be "FB".

Yes, they should, but there's really no difference on, or to, an HP3000 in
this area, due to the concept of 'records' which the HP3000 uses. (I vaguely
remember that unused ASCII bytes are space filled, while unused Binary bytes
are null filled, but as they are unused, you hardly ever come across this
difference anyway).

But to a PC, say, where there are no 'records' such as MPE provides, and a
binary file is a bytestring of the requisite length, while an ASCII file has
'records' which are variable length and delimited by CR(LF), and the file is
itself delimited by EOF, it matters very much.

As it starts to do even if you copy a file to a target of the same platform,
when the transport software uses these concepts.....


Roy Brown

Posting with the OEnemy, tamed by OE-QuoteFix 1.17.6
http://jump.to/oe-quotefix

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2