At work we are in the process of migrating from a legacy accounting system to Microsoft’s Navision Attain. The legacy app is running on a SCO OpenServer 3.2v2 box. The guy supporting the app wrote a dump utility that creates ASCII files of the data. The trick to get the data from the box.
The box has no NIC. It works completely with serial boards. Do you know how long it takes to cat a 5MB file over a 19.2k serial link? To long to even figure it out. Anyway, I needed to compress the data before I moved it off the box. Um, ok, then WTF do I do with it then? Can’t cat a .tar.Z file. Kermit!
The SCO box has nothing installed for any sort of file transfer (XMODEM, YMODEM, ZMODEM, or Kermit). Fortunately after spending an inordinate amount of time Googling, I found that the folks behind Kermit, Columbia University (in nYc, boyeee!) had a compiled binary for my version of SCO (!). No shit, right? Yes shit!
Ok, so I now have the Kermit binary on my Windows XP box. If you remember the aforementioned problem; no file transfer protocol implementations on the box. Now, how do I get the file to the SCO box? The SCO box has a command, doscp, that allows me to copy a file from a DOS floppy. Therefore, via sneaker net, I marched into the computer room and slipped that 3.5″ floppy from my PC into that bad-boy. Well, long story short, it fuckin’ worked! Oh yeah, pimp status +1. Furthermore, SecureCRT has fair Kermit support. But, um, we have a problem.
The files seemed to be corrupt. Back and forth I went with moving files from the SCO box to my machine. I was able to ruleout any corruption from Kermit because I was able to move raw text files, and an uncompressed tar archive across the link and they worked just fine. Now, WTF is going on? This is where RTFM is actually your friend (yes, you actually heard me say that).
SCO’s compress command is a little left of center when it comes to the standard, or so it seems to gzip. I noticed in the compress man page a -H switch, which changed compress to the use the LZH compression algorithm. Furthermore, the gzip man page says that it works with compress with the -H switch. When I used this switch, gzip’s -d output changed. Acha! We are on the path to ritcheousness. The error that gzip barfed out was “invalid compressed data -- Huffman code > 32 bits“.
Well, back to the compress man page. Compress also takes a -b switch, which allows you to specify the bit size used in compress. By using compress with -H and -b 32, I was able to get a good decompress from gzip. Pimp status +2! You must also provide the -i switch to Kermit, which lets Kermit know that you are transfering a binary file. Othewise, you get sporatic results. Now I am moving the full tar from the box as we speak. It’s over 4 megs so it’ll take close to an hour to move.
Anyway, for posterity, here is the command I used to build my tar:
tar cf - filedump | compress -H -b 32 > filedump.tar.Z
And the Kermit command:
kermit -i -s filedump.tar.Z
Is Joey still single?