OT: Need Unix tech in Springfield, Missouri area

[Don Y]

Chuck Guzis wrote:
> On 8/2/2006 at 11:32 AM Don Y wrote:
> 
>> Unfortunately, you then need *one* box with hardware suitable
>> to capture the incoming bytestream (i.e. *not* an SPP).
> 
> I know this is a vintage list, but at a minimum, PS/2-style bidirectional
> parallel ports have been around for a very long time, so this shouldn't be
> a problem.  Even if you had an old XT, printer and monochrome adapter cards
> can usually be modified to operate in bi-directional mode.
> 
> After that, it's just the cable and a bit of software on the receiving
> side.

Or, a small bit of hardware to mux the 8 data lines onto the
incoming status lines (SPP).  I.e. you only need *one* of
these and *one* machine with this capability to handle
a variety of "source" machines.

>> Ideally, the source box would have MD5 or some other hash
>> available so you could gain some reassurance that the
>> received image agreed with the sent image.
> 
> CRC-32 would probably do if MD5 wasn't available, and it's short enough
> that if you had to key the C source in (assuming that the SCO box has a C
> compiler), it wouldn't be an onerous job.   You could probably do that
> while the transfer was running.

Yes.  Anything that provides a reasonably unambiguos "signature"

> Failing that, you could transfer the tarball twice and compare the two
> files.  A miscompare wouldn't tell you which was bad, but it would at least
> indicate that something had gone wrong. 

I'd shy away from that.  In addition to the issue of
"what happens if you get N different results (N>2)",
you are also vulnerable to any problems in the *mechanism*.

E.g., if the I/F was not 8 bit clean, you would *think*
you had a successful transfer and actually lost all the MSB's.
Likewise if a signal is shorted in the cable, it will
consistently yield the same (wrong!) results.