this seems like a wan/lan network issue ... if there is a way you can get both boxes on the same subnet, you might get the transmit speed to go much higher ...

if both boxes are already on the same subnet, check the settings on the network switch ports themselves to make sure they are not on auto ...

if the NICs and ports for both boxes are already set correctly and there are no issues with any of the network devices connecting the SCO box to the Linux box, try a "temporary enhancement" if possible ...

Code:

1. power-off both boxes
2. remove older box's smaller drive and add it to an empty slot on the newer box
3. boot up newer box
4. if newer box can read data on "new" drive, copy data
5. power-off new box
6. remove "new" drive and return to older box
7. boot up both boxes normally

BTW, I've used the procedure listed above on Sparc boxes running Solaris but I've never done it on Intel-based boxes or with Intel-compatible *nixes ... I vaguely remember doing same procedure on HP-UX and AIX but I'm still foggy from the anesthesia so ...


if there is no way you can do a "temporary enhancement" and everything looks like they are supposed to, then I would suggest running the job right before you leave for the day ... check on the file transfer the next day ...

if you are allowed to setup a rsh/ssh connection between both boxes without being prompted for a password, I suggest you try a remote transfer that way and see if it helps the speed ... try transferring a 1 MB file to test ... see "man rsh", "man ssh", "man tar" ...

Code:

cd /data/dir
tar cvfp - [file|dir] | rsh linuxbox "cd /data/dir; tar xvfp -"  # could also use ssh

when setting up the rsh/ssh connection, make sure that it is setup for the user who owns the data being transferred unless you can set it up for root on both boxes ... search forums on tips to setup remote rsh/ssh connection ... good luck!