Sticking with Progress...
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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
| Android's Limits | Jun 04, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- Senior Perl Developer
- Technical Support Rep
- Weechat, Irssi's Little Brother
- UX Designer
- One Tail Just Isn't Enough
- Android's Limits
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




29 min 54 sec ago
46 min 14 sec ago
1 hour 34 min ago
1 hour 34 min ago
3 hours 59 min ago
8 hours 10 min ago
8 hours 13 min ago
1 day 3 hours ago
1 day 4 hours ago
1 day 5 hours ago