HP3000-L Archives

October 1996, Week 5

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:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Wed, 30 Oct 1996 01:08:21 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (53 lines)
I find it most notable that Jeff Vance doesn't find FTP/iX intuitive;
maybe he will file an SR (like the rest of us have been told :-) ).  But
anyway...

Jeff Vance wrote:
> On Oct 29,  3:00pm, [log in to unmask] wrote:
> > In transferring ASCII files from the 3000 to a PC, we notice two
> > differences between using FTP and downloading with Reflection: speed
> > and the resulting byte count.

to be addressed after Jeff V's comment...

> I don't know if this is at all related...but when I transfer bytestream
> files from my hp-ux worrkstation to jazz (on MPE/iX 5.0) I get byte
> counts on jazz that are greater than on my workstation.  Mike Yawn told
> me about the ftp "tenex" command, which I used in place of "binary" and
> now the byte counts all match!

Two issues are at play - actual file "data" and platform-dependent
representation of that data.  Let's take binary data.  If you say binary
on both ends, then nothing in the "data stream" is altered.  If you say
ASCII, then there may be some conversion to accomodate "end of line" or
"character set" adjustments.  For "end-of-line" we have the concepts of
an MPE/Vax/IBM-big-iron "record" (non-bytestream file), Unix "LF", DOS
"CR-LF", etc.  For "character set" IBM big iron translates EBCDIC/ASCII.

Next, relative to "byte count" on MPE, we must consider fixed, variable,
undefined, and bytestream file formats.  For fixed, we have record
length * numrecs = bytecount, and numbers will go high.  For variable,
some estimates of "bytecount" may include the record length field in the
variable length record format.  For bytestreams, MPE stores text with a
Unix-style LF.  For binary files, we again have options of fixed,
variable, undefined, and bytestream.

The "tenex" format is an old carryover from non-8-bit-byte machines like
the PDPs, DEC-10's, etc; this transmits a "byte" in a universal format
which is padded on either end.  MPE stores these as bytestreams (if I
recall correctly) so the bytecounts match; if you use binary, it stores
as variable-length binary (I think).  At any rate, it is "how you look
at the data".  The data is correct, in most respects.  Unfortunately,
FTP/iX was written prior to bytestream files, so it tries to accomodate
bytestreams in traditional MPE formats, and it has become more of a
hinderance than a help.  For example, you cannot transfer an ASCII
bytestream text file to a PC-compatible machine and get a proper text
file; transfer ASCII and it sends you single-bytes with a CR/LF between
each byte.  Transfer binary and get no CR, just an LF.  You're hosed.

It works wonderfully transferring MPE files from MPE to MPE; it has it's
limits transferring Posix-domain files in or out, especially ASCII which
is absolutely impossible without intermediate conversions.

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2