Sticking with Progress...

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

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.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot