Wayback Wed: An Emulator's Partners Enter
Harris School Solutions buys K-12 ISV QSS

K-12 vendor still migrates schools to Linux

Editor's Note: We learned today that Quintessential School Systems (QSS) has been acquired by another school software ISV, Harris School Solutions. QSS has been notable for leading customers from its MPE/iX application suite onto Linux—and QSS was one of the very first to do this in the 3000 world. Here's a replay of our report about the how and why of this migration campaign's roots. It's an effort that began in the earliest days of the Transition Era, according to this report from 2002. In the article below, just swap in Linux for any mention of HP-UX. There's not a measurable benefit to leading anyone to HP's Unix anymore.

QSS outlines pilot move of K-12 apps to Open Source

By John Burke

Rolling deskQuintessential 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 created a set of tools for HP 3000 developers. QSDK was a subroutine library toolkit to network applications. QWEBS was a Web server running on the HP 3000. When QSS talks about migrating 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 intentions about the 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, QSS COO Duane Percox gave a talk titled “Migrating COBOL and IMAGE/SQL to Linux with Open Source.” Percox hoped to share QSS’s pilot project experience for migration approaches.

QSS customers tend to be very cost sensitive, and so an Open Source approach has a lot of appeal for any 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. But there are migration choices here that are useful for anyone moving MPE/iX applications.

Before starting that 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 [in 2002 numbers], 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 and SAP DB (www.sapdb.org). The choice for the pilot project was PostgreSQL.

“This is an ever-changing landscape," Percox said in his presentation, "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. "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 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. One commercial COBOL for Linux became available doesn't require run-time licensing, Fujitsu NetCOBOL (www.netcobol.com).”