I've been meaning to write this down for a while and just decided to leave it here, for posterity, and for whoever may find this helpful.
in 2012 I was at a "Class of '82" highschool reunion (the only one I ever went to), and when it was my turn on stage, people asked me: "what do you do ?" , to which I answered: "I solve problems, in computing of course".
To which one of my old best friends raises his hand and says: "I've got a problem".
OK then, he owns a Hotel, and had (still has) a billing, reservations, and guest management system, running on XENIX 2.3.4 i386 , since 1987 !!!!!!! Called Hotel-Soft, custom-made for him, (and the dude that wrote it, is already dead.) And the computer itself was once changed in 1995 with some random PC i386 33Mhz. And by the noises coming out of it, it was about to die a painful death.
So I flew down there and found myself with something out of a dark forgotten past:
1. Network ? no way
2. Every time you hit the Turbo button, the machine reboots. Fans seized. Bio-chemical dust lab.
3. The disk, 80Mb IDE was humming and chirping away like an outboard engine
But the system still ran, painfully, with its DOT-MATRIX printer connected via some strange looking internal-external serial/parallel expansion card, which was also connected to their phone system (for billing), and old PBX.
4. A root login into the Xenix yielded: Compiled COBOL application running over a proprietary database, which sorta looks like DB2, but it isn't. No sources, no documentation. Zilch. About 300 forms, and the data all inter-related, i.e. if yo u change room price in dollars it calculates pesos, and updates unknown other tables, etc etc.
5. AND THERE WERE ONLY 2MB OF SPACE LEFT OVER !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
So I ask him: why don't you just buy a new system, there may even be open-source systems for this, for free. To which he answers: we purchased 2 of them for like 50k each, tried them, completely unusable. I want to keep this old thing running until I sell the Hotel. LOOOL.
So, how did I solve his "problem" ? .
A. Get all his data out, and rewrite the application from scratch, make it browser-based, in some easy text-based language like PHP, and put the data in Postgres.
B. Migrate this XENIX system out of that Hard Drive, into some Virtual Box or something.
THE WORK, which I did for free, since my reputation was at stake:
#1. We need to get a backup of all his data. At least that is my goal in that first trip down there.
a. I was able to connect to the COM2 port, change the getty in Xenix, and I was able to log in as root using "cu", at 9600baud. And my buddy had an old Toshiba laptop lying around, with a serial connector, in which I immediately installed Fedora, and left under the table, connected to the old Xenix system. That laptop then had a loop with an "xterm" being sent to one of my servers in California, (to which I "vnc" into its Xvfb Desktop, and am able to type directly into the Laptop at the Hotel)
b. Before leaving there (flying back home), I decided to take the "plunge", I took the drive out of the machine, and plugged it into an old i386 PC (win$hit 95) system he had running in some back room; however, I loaded a Knoppix CD into it, booted that, mounted my own Fedora Laptop via NFS, and I was able to at least get a "dd if=/dev/sdb of=full_drive.dd" sent to my Laptop. The Hard Drive complained a couple of times, but it finally did the "dd".
That moment was most definitely a heart-thumping experience. Imagine if all the data was lost, or the drive killed.... But it worked.
#2. So, now I had a "dd" of the full disk, 78Mb in size. Which I passed onto another guru friend of mine called Klaus in Germany, so he could figure something out. We both attacked the data, only to find out (thanks to Klaus) that the XENIX file system definition which is published in Wikipedia is actually WRONG (off by one bit) !!!!!!!!
He figured it out after weeks of testing, during which we could only get folders out, but no files, funny stuff.
So we finally got the full directory structure out, with all files. And I set out to read the data. Months went by, doing this during my spare time, and it was impossible to get a clean copy of the data. All the files were corrupted. REASON ?
SIMPLE, but evil evil: XENIX keeps a mapping of the bad sectors in the Operating System itself. i.e. the information is not on the Disk. So we got all the data, but it was all corrupt !!!!!!!!!!! So, you can't successfully "dd" a XENIX disk without the actual OS running. Of course that was not to be, since I was 6000 miles away, and only talking through "cu" to a system which could crash at any second, and impossible to put a second drive into it, and it would not even work, as the system would crash the second it "does something" heavy on the cpu.
#3. So now I was stuck 6000 miles away , with a "cu" connection running in an xterm which was sent to my California server's Xvfb (also on Fedora I might add), to which I connected via VNC.
Oh dear, then it's back to rewrite the application , but without proper data. So wat I would do, is I would log in as the "hotel" user, and go through all the screens, and run screenshots in my home, so I could go and discuss them with my Hotelier friend. Luckily I flew down to his couuntry for almost 2 months the next summer, and we were able to hash out a lot, however, we had a serious problem.
The system used the "F-KEYS" to navigate sometimes from screen to screen, and we were unable, after weeks of testing, to get the xterm , or konsole, or xfce term, or terminal, or whatever term I tested, so properly pass the F-KEY codes via the "cu" connection into the system.
And that simple but evil problem brought about THE SOLUTION
Reading the "UUCP" documentation (which I hadn't used since 1989 myself), I found out that there are 4 commands: ~p ~t and %p %t (Put and Take), binary is with % , textual with ~ , so I could extract files out of the XENIX system via my "cu" connection at 9600 baud, which actually by that time I had already upgraded to 19200 baud.
Things were progressing slowly, but surely.
#4. So flew back home, and I set out to extract the data, and/or anything I could find that was needed.
Another 3 to 4 months "trying" to extract the data, which was almost impossible, all connections would just drop, as errors were encountered. Say a 20KB binary file would take like 10 or 20 attempts, to properly download...... And there were thousands of files ........
At this time I remembered something I had used back then, to send files across serial connections, with proper error correction, called "KERMIT".
Problem was, XENIX had no copy of KERMIT, and there was only 2MB space left on the HD......
I went searching around the net, and found 2 important things, a Brasilian guy, who had
a. A copy of the old XENIX 2.3.4 i386 install diskettes
b. A copy of Kermit, precompiled, for XENIX 2.3.4 i386
So, what to do ? hmmmmm. Well, the precompiled Kermit executable for XENIX was like 700k if I remember correctly, a massive program.
But, how do I send the actual binary INTO the machine ? Well , after 100's of tests via %p and ~p, I managed to UUencode the binary, and it gave me 2MB , which I also tried 100's of times to send in, to no avail. So I decided to "cut" the file into say 100 small chunks , which slowly but surely started trickling into the XENIX via %p and ~p. I found out that it was best transferring at 4 AM their time, with the least amount of electronic noise, and probably lowest temperature there.
So finally I had it all in there. all 100 chunks , 20KB each. Space was basically "at 100%" on the disk. Even after removing all logs, and whatever I could find that was not really necessary in the OS.
MOMENT OF TRUTH #2: I told mi friend to take the cover of the machine off, and put a powerful FAN next to it, pointing at the CPU, which he did.
I then executed this command:
cat *.cut | rm *.cut | uudecode > kermit.bin
I sweated BULLETS, and it took 10 minutes, but I got a root PROMPT !!!!!!!!!!!
ls -l kermit.bin WOOOORKEEEDD
And the space was back to 98% on the disk, all good. I then put the kermit.bin program in /bin/ , and made a loop with a wait, which would loop 10 times executing kermit, and exit. So I exited the system and tried to connect from the Kermit running under Fedora in the Laptop connected via the serial cable, and IT WORKED !