As the publishers of LJ, SSC is committed to the use of the Linux operating system throughout our offices. Many of SSC's operations revolve around our Progress database server which still ran, until recently, on a difficult-to-maintain At&T SVR4 486 tied into our Linux network. In this column we outline how we made the conversion to an ELF-based Linux system running the SCO Unix version of Progress 6.3F08.
At SSC, we've been using Progress for years (since 1985), and a Linux port of Progress is not, and, as far as we know, will not, be available from Progress Software Corporation. We decided to investigate the feasibility of using the iBCS emulation package together with the well-supported SCO Unix version of Progress.
SSC's database is used throughout the office for order processing, subscriptions, sales reports and plots, marketing, advertising, billing statements, label printing and shipping. Integrated with the database is the authorization and settlement of credit card orders by means of a certified external program developed in-house. Future plans for the database include automatic ordering from our web site and address matching software with CASS (Coding Accuracy Support System) certification. SSC prefers to stay with Progress, rather than change to another database specifically ported to Linux, such as Postgress, since we have invested considerable time customizing the database for SSC's growing needs. Progress also has a proven track record of being very stable and reliable. That is all very well, but what is iBCS? iBCS stands for the Intel Binary Compatibility Specification, which specifies the interface between application programs and the surrounding operating system environment for i386-based systems. This allows a number of binaries developed and compiled for other Unix OSs to run on Linux. The freely available package is still being developed but a recent version of iBCS compiled and installed without a hitch under Linux kernel 1.2.13. The demo version of SCO Progress we ordered arrived in a black box with manuals and a DAT tape. Installation did not go flawlessly; following the prescribed procedure worked only up to the point where the remaining archives were supposed to be read from the tape. I ended up reading them “by hand” using cpio and tweaking the installation scripts to look on the disk instead.
After that it turned out the file permissions and group/user IDs were set incorrectly and the standard shell scripts had the wrong directory paths in them. It helps to have an existing Progress v6 setup, although it's certainly possible to fix this without one. At this point, I was able to run the db server in single- and multi-user mode—time to start looking for other, more sneaky problems. It turned out that setting the TZ environment variable and using a local password file is required for SCO Progress; otherwise, you get a lot of memory violations. An invaluable tool to help you solve this kind of problem is itrace, and it is included in the iBCS package. It took some preparation to adapt our custom Progress code for the move, but after that the transition was mostly just a matter of copying all the SSC database-related files over to a new system. I didn't even have to do a time-consuming dump and reload of the database, because both architectures were x86-based. After several more days of testing, we were confident enough with the setup to go ahead and order the “real” version of Progress for SCO Unix. For reasons not entirely clear, the program arrived on floppy disks, which seemed more of a pain than the tape at first but it was actually easier to adapt the install scripts to work correctly, requiring only patience and lots of disk swapping. The server wouldn't run in “raw” mode, a major problem with the standard SCO version. That is, database consistency couldn't be guaranteed. This turned out to be a bug in the SCO version and after requesting and applying the latest patch (6.3F08), this was fixed.
Switching from the old server to the new was a pleasant surprise for everyone (except me) and consisted simply of logging on to a different computer—everything else looked and worked the same. We all were prepared for some multi-user glitches, but none occurred.
There are few disadvantages to running SCO Progress under Linux, other than some minor installation incompatibilities and no “official” Linux support (although Progress SCO technical support is quite helpful). I can't think of any others, aside from the fact that Progress v6 under Linux shows the same bugs as under SCO!
On the contrary, there are quite a number of advantages for SSC or any office environment already using Linux. Firstly, over the last few months, the new system proved to be just as stable. Most of SSC's operations revolve around the Progress database server, and without it, business grinds to a costly halt. It now fits well with the rest of the network; there are no more problems with shared directories or slightly different commands and environments. It's faster and more responsive; record searching and scanning is much faster. One reason for that is Linux has dynamic buffering (using free memory), which speeds up the overall system I/O. And of course, it's cheaper—Linux is free—SCO is not.
But what better proof than to let one of SSC's employees and a long-time user of Progress, Lydia Kinata, rave about the virtues of the new system in her own words.
I've been using the Progress database since April 1994. SSC was a much smaller company when I started, and my job description included a wide range of responsibilities from shipping and order entry to accounts receivable and marketing. I have been in a position to regularly use most, if not all, of the end user capacities of the database. As a user, I waited with bated breath for the transition of the database from AT&T SVR4 Unix to Linux. I was involved in the testing phases of the new database, but I've been around long enough to know that a transition this massive usually does not go smoothly. Phil Hughes, publisher of Linux Journal and chief pesterment of SSC, prepared us all for a bumpy ride by announcing repeatedly that Peter and our systems administrator, Liem Banneman, would be working all night on the transition. I was prepared to believe him.
By 5 pm Wednesday night, we had all cleared out our home directories on the computer that was home to the SVR4 version of Progress. I came in the next morning ready to find Peter and Liem bleary-eyed and cranky. I telnet-ed to the computer with the SCO version of Progress installed and settled down to what I thought would be a long day of bugs. I was overjoyed to discover that everything worked! In fact, the database functioned almost exactly the same as before, with a few pleasant exceptions. Under SVR4, vi worked very poorly. New users often were left with the impression that they were hitting capital letters accidentally at the command line or that vi was just “weird”. Whole lines would repeat erratically, or the cursor would not really be where it appeared to be. Under Linux, this problem went away. Certain time-consuming database operations, like global key searches, are faster under Linux; having the same home directory files accessible on all computers is also an advantage. Formerly, we would have to rcp files to have them on the SVR4 system and our personal workstations, which was a mild annoyance.
For most purposes, the database looked and acted at 8 am on Thursday just as it had at 5 pm on Wednesday. To date, we have not experienced any database crashes, neither have we discovered any bugs that could be traced to Linux. In all cases, bugs could be traced to SCO Progress itself or to temporary bugs at the programmer's level.
SCO Progress running under Linux works.