ISV journeys down Linux migration road

QSS outlines pilot for moving its education apps to Open Source

By John Burke

First of two parts

Quintessential School Systems (QSS), founded in 1990, is an HP 3000 ISV providing software and consulting services to K-12 school districts and community college systems. While developing, supporting and providing administrative and student records management computing solutions for these public school districts, QSS has also created a set of tools for HP 3000 developers. QSDK is a subroutine library toolkit for HP 3000 programmers who wish to develop network applications for their HP 3000 without the hassle of learning network programming. QWEBS is a Web server written by QSS that runs on the HP 3000.

When QSS talks about migrating its HP 3000 applications to Open Source, we all need to pay attention to what they are doing and how they are going about it.

Public school systems are understandably very cost conscious, so for competitive reasons QSS had already started investigating migrating its software to an Open Source solution before HP even announced on November 14, 2001 its intention to EOL the HP 3000. This put QSS ahead of most ISVs and non-ISVs in determining how to migrate traditional HP 3000 COBOL and IMAGE applications. At HP World 2002, Duane Percox, a principal in QSS, gave a talk titled “Migrating COBOL and IMAGE/SQL to Linux with Open Source”, presenting QSS’s pilot project experience. With his talk, Percox hoped to share some of QSS’s experiences in order to help others choose a migration approach. Since HP World, I have had the opportunity to interview Duane about his presentation. This article combines information from his presentation with the questions and answers from my interview.

In this first of two parts we look at the project goals and objectives, the project plan and the initial decisions. Next month, we will look at how the test migration worked and what was discovered along the way.

It is important to keep in mind that as an ISV, QSS’s focus is necessarily different from a non-ISV looking to migrate or replace homegrown applications. After all, for QSS, buying a new package is not an option. Also, QSS customers tend to be very cost sensitive, thus an Open Source approach has a lot of appeal for an ISV providing a complete packaged solution. Non-ISVs looking to migrate homegrown applications to other platforms might want to stay with commercial operating systems, databases and compilers for the vendor support.

Before starting the pilot project QSS had to choose a target OS, database and compiler. For the OS, QSS chose SuSe Linux. I asked Percox why Linux and why the SuSe distribution. “Our migration target is an Open Systems and/or Posix-compliant OS,” he said. “We chose Linux and HP-UX as the target platforms with Linux for the pilot project. With the cost of Linux development systems being so low, doing the pilot on Linux was a natural. We believe that Linux is a wonderful choice for ISV solutions. However, we have large customers who might feel more comfortable with an HP-supported OS. That is why we are targeting both.

“As for the SuSe distribution, we basically had seen good things about it on the Internet and so we chose it for our pilot project. QSS is currently working out business arrangements with SuSe and Red Hat. It will all come down to the business side of things. We are pleased with both distributions, and given that Red Hat owns 52 percent of the market, we are certainly not discounting them.

“Our goal is to be a TSP (total solution provider) and essentially build a custom sub-distribution from one of these two. We will then host a patch-site with approved patches from the source company. We don’t think our customers will care which we choose because we are basically going to say that ‘we own the installation’ of the Linux box. We won’t want anything other than QSS applications to be installed on the application server.”

I asked if QSS had considered system management issues in choosing an OS. Percox replied, “We are building an application environment that will provide for the job scheduling, spooling, etc. The specific library and toolset layer we provide will insulate the application from the particulars of each OS. However, choosing to be Posix-compliant is what will help us be very similar.”

With the choice of an OS platform out of the way, QSS next turned to the database. Percox said, “One of our goals was to migrate to a SQL-92 compliant RDBMS. Within that goal, we wanted to evaluate whether any Open Source RDBMS was sufficiently capable to support a commercial grade application.” QSS evaluated MySQL (www.mysql.com), PostgreSQL (www.postgresql.com), Interbase (info.borland.com/devsupport/interbase/opensource) and SAP DB (www.sapdb.org). The choice for the pilot project was PostgreSQL.

As Percox said in his presentation, “This is an ever-changing landscape, but one which is moving in a reasonably consistent manner. High performance data access (Web-based, read-only systems) favors MySQL. Bulletproof commercial quality with transaction support favors PostgreSQL and SAP DB. Interbase has not established a good open source community. PostgreSQL, Interbase and SAP DB have support for transactions and lock isolation. Version 4 (future) of MySQL is supposed to support transactions. A number of good books have been written about PostgreSQL, making it the easiest to learn. SAP DB is coming on strong and is worth considering down the road.”

I asked whether QSS had considered HP Eloquence and if so, why it had chosen not to use it. Percox said the issue was cost.

“Our customers are public education and they are not just sitting around with spare money waiting to be spent on a database,” he said, “even one as reasonably priced as Eloquence. Since we are doing the migration and spreading the cost over our installed base and future sales we can take the hit on converting the COBOL code from TurboIMAGE to SQL. To help keep the migration cost down for QSS we are developing the SQL abstraction layer that we believe will give us both the ability to drop in replacement calls and the ability to tune for performance when needed without having to re-write the entire COBOL code library.”

The third and final decision was which COBOL compiler to use for the pilot project. QSS already used Whisper Technology’s Programmer Studio so it did not need an IDE. As Percox said, “Because we use WT-PS, we can focus on command-line/script compiling. We don’t need fancy IDEs and, in fact, having a common IDE regardless of language can be very helpful and improve productivity for those developers who code in multiple languages on the server.”

QSS chose to use TinyCOBOL (www.tinycobol.org) for the pilot project. Percox explained, “The principal reason for choosing an Open Source COBOL was that at the time the project was planned, all the commercial COBOL compilers for Linux required run-time licensing on a per-user-execution basis. As an ISV that serves a cost-sensitive end-user vertical market, we must deploy our solutions with minimal (or no) run-time fees. Gnu COBOL is moving along very slowly and is not yet ready. TinyCOBOL was the only Open Source COBOL we could find that generated IA-32 code for Linux and that supported most of the COBOL-85 constructs. Once we got going, two commercial COBOLS for Linux became available that did not require run-time licensing, Fujitsu NetCOBOL (www.netcobol.com) and theKompany Kobol (www.thekompany.com/products/kobol/).”

Next month: The project, what was learned, and how it affected the actual migration plan.