1 Aug
2006
1 Aug
'06
11:45 a.m.
Sorry for the OT posting, but I figure I'd find some qualified Unix techs
here. I have a client in the Springfield, Missouri area that needs to get
some data off of a very old SCO unix box. The box is not interconnected
with anything else, and the only means to get data off--an old Irwin 60MB
tape drive, went bad. I figure there would be a simple way to get the
data off the hard disk, by either mounting it into a Linux box or adding
an external drive to the SCO box via SCSI (though I'm not sure if it has a
SCSI interface...in fact I know next to nothing about the box currently).
If anyone is interested in this project, please e-mail me directly (I
won't see any responses to the list). Time is of the essence, so please
reply soon.
P.S. VCF 9.0 is November 4-5. Web page going up today.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
1 Aug
1 Aug
12:38 p.m.
Sellam Ismail wrote:
Sorry for the OT posting, but I figure I'd find
some qualified Unix techs
here. I have a client in the Springfield, Missouri area that needs to get
some data off of a very old SCO unix box. The box is not interconnected
with anything else, and the only means to get data off--an old Irwin 60MB
tape drive, went bad. I figure there would be a simple way to get the
data off the hard disk, by either mounting it into a Linux box or adding
an external drive to the SCO box via SCSI (though I'm not sure if it has a
SCSI interface...in fact I know next to nothing about the box currently).
If anyone is interested in this project, please e-mail me directly (I
won't see any responses to the list). Time is of the essence, so please
reply soon.
Not in the area.
You could always try 'kermit' through a serial line.
Slow, but it should work. Might be faster and safer than mucking
about with assorted hardware.
Another serial option might be 'uucp', or related programs.
P.S. VCF 9.0 is November 4-5. Web page going up
today.
3:12 p.m.
Kevin Handy wrote:
Sellam Ismail wrote:
Can't you build a tarball and cat it to the printer port
(there are tools that will let you configure another machine
to *capture* data from the printer port). No, not PLIP, etc.
This would be an open-loop process... you just push the data
and *expect* the other device to capture it all correctly.
Serial port has the adantage of being unattended -- but slow.
I suspect you won't find support for anything above 19.2K (?)
depending on the vintage of the OS.
Another option would be to dd(1) a tarball to a *second*
RAW disk (and hope it numbers blocks the same as the "other"
machine that you later move the drive to). This is quick
and relatively painless to try (1MB at 19.2K will take you
~10 minutes depending on protocol overhead; 60MB will
obviously take even longer :> ). Swapping a drive in and
out should take less than an hour start to finish
(been there -- too often! -- done that...)
Sorry for the OT posting, but I figure I'd
find some qualified Unix
techs here. I have a client in the Springfield, Missouri area that
needs to get some data off of a very old SCO unix box. The box is not
interconnected with anything else, and the only means to get data
off--an old Irwin 60MB tape drive, went bad. I figure there would be
a simple way to get the data off the hard disk, by either mounting it
into a Linux box or adding an external drive to the SCO box via SCSI
(though I'm not sure if it has a SCSI interface...in fact I know next
to nothing about the box currently).
You could always try 'kermit' through a serial line.
Slow, but it should work. Might be faster and safer than mucking
about with assorted hardware.
Another serial option might be 'uucp', or related programs. 
4:28 p.m.
Don Y wrote:
Can't you build a tarball and cat it to the printer port
(there are tools that will let you configure another machine
to *capture* data from the printer port). No, not PLIP, etc.
This would be an open-loop process... you just push the data
and *expect* the other device to capture it all correctly.
I would try cpio (find . -print|cpio -ov > /dev/tty) rather than
the tarball, as it will transport sym links better than a tarball,
and the sco tar will probably not be up to snuff to deal with
it line gnu tar is now days. if space and functionality permit,
one could create a cpio file and checksum it in some way
to be sure it transfered with all the data. if nothing else, wc
the thing.
Jim
6:22 p.m.
jim stephens wrote:
Don Y wrote:
Ah, good point! I am spoiled by gtar... :-(
(though my point was to use /dev/lpt for bandwidth reasons)
Can't you build a tarball and cat it to the printer port
(there are tools that will let you configure another machine
to *capture* data from the printer port). No, not PLIP, etc.
This would be an open-loop process... you just push the data
and *expect* the other device to capture it all correctly.
I would try cpio (find . -print|cpio -ov > /dev/tty) rather than
the tarball, as it will transport sym links better than a tarball, and the sco tar will probably not be up to snuff to
deal with
it line gnu tar is now days. if space and functionality permit,
one could create a cpio file and checksum it in some way
to be sure it transfered with all the data. if nothing else, wc
the thing.
Jim
9:19 p.m.
What I was thinking....
I did contact Sellam on this since I'm only a few hours away. But just for
the lists discussion...
I was pondering approaching this with a QIC-80 (DC2120) drive that sits on a
floppy controller. Those are quick to hook up, and if my really feeble
memory serves me even REALLY old SCO unix supported QIC-80 type drives. I
still have a working Colorado Jumbo-250 tape drive (and FC10 controller!)
from my BBS-running days. This would seem to be the
least disturbing option
to the SCO box to add. I can't remember if SCO
supported the drive only on
the standard floppy controller, or if it only supported it on the FC10. Ah
well. Maybe an option.
Jay West
11:01 p.m.
On 8/1/2006 at 8:19 PM Jay West wrote:
I was pondering approaching this with a QIC-80 (DC2120)
drive...
Ick. Floppy-tape--slow and unreliable.
Surely the SCO box must be capable (or already have) a SCSI controller to
hang a DLT or DAT from! If you're going to be spending your valuable time,
might as well use something that's reasonably fast and has read-after-write
verification. Since SCSI tape is a pretty well standardized item, it
should work okay with a minimum of fiddling.
Cheers,
Chuck
11:14 p.m.
Chuck wrote...
Ick. Floppy-tape--slow and unreliable.
Surely the SCO box must be capable (or already have) a SCSI controller to
hang a DLT or DAT from!
I only need the floppy tape to get the data across once, speed is not an
issue.
But moreover, it all depends on what is already built in to the kernel, and
as I recall, SCO has the QIC-80 driver built in by default. That tape drive
on the machine that died may well be QIC-02 and not SCSI.
Jay
11:29 p.m.
On 8/1/2006 at 10:14 PM Jay West wrote:
But moreover, it all depends on what is already built
in to the kernel,
and as I recall, SCO has the QIC-80 driver built in by default. That tape
drive on the machine that died may well be QIC-02 and not SCSI.
Good point. Maybe a Travan TR-1 might be a little more reliable. I still
shudder when I think of the nighmare of the DC-2000 floppy tapes. If it's
a really old box, it probably expects something like Cipher 525 drives.
Cheers,
Chuck
6640
days inactive
6641
days old
8 comments
6 participants
participants (6)
-
cclist＠sydex.com -
dgy＠DakotaCom.Net -
jwest＠classiccmp.org -
jwstephens＠msm.umr.edu -
kth＠srv.net -
sellam＠vintagetech.com