Throwing Open A Window to Low-Cost Power

Steve Smith has cleared the path from HP 3000 to Windows as patiently as any winemaker, and he will see his vines grow ripe in a season soon. The owner and development leader of vineyard application provider AMS, Smith has been moving his company’s application out of the MPE world for several years, and his company’s work should bear fruit by this fall.

Smith has been looking for a cost-competitive future for his firm for some time. We first spoke with him in 1999, when Minisoft’s Doug Greenup identified AMS as one of the smaller 3000 app providers that HP was overlooking. One reason that the 100 or so customers using Smith’s AMS app didn’t appear on the HP radar might have been a paucity of sales. Well over four years ago, AMS was dealing exclusively in used HP 3000s for its customers, and providing its own support. Even then HP was no longer a part of the AMS business plan, and his business was surviving.

Then, as Smith tells the story, HP announced it was dropping its 3000 business in 2006, and AMS competitors started carrying that news to his customers as well as prospects in the wine industry. AMS serves the small to midsize wineries that make up the vast majority of American vineyards, and these businesses have price pressures on their IT spending. New HP 3000s had been beyond the wineries’ budgets — and last year the affordable used systems then became suspect as result of HP’s news. Smith had already seen this coming, and so had begun to research moving his application to Windows to use less costly Intel-based hardware.

We heard of Smith once again this spring, when database provider Pervasive Software offered him up as a success story of a conversion from IMAGE to the Wintel-based Pervasive database. While that deal hasn’t been sealed yet, Pervasive’s product looks good to Smith, a man not easily swayed by marketing enthusiasm.

Smith has been with the HP 3000 and MPE since the 1970s, so he’s leading his customers and company away from MPE with some reluctance — but not a lot. We found a technically adept company leader who’d grown up with the 3000, one who’s now gathered experience in the move to the Microsoft alternative, and we were hooked. As a significant part of the 3000 community looks over the platforms outside of MPE and IMAGE, we felt Smith’s experience could shed light on where the pitfalls may lie on the path to the promised Redmond rewards. We spoke with him just after the latest Solutions Symposium by phone about what it’s been like to adopt a Windows view after seeing the world from IMAGE-MPE eyes.

How long have you been working on moving your applications?

We’ve been working on it off and on for years, since 1998, but we picked up the pace about a year ago and have been working on it pretty steadily. Now I have pretty much the whole staff, six people, on it. We hope to have something to sell by the third quarter of this year.

How do you feel about HP’s decision to drop its 3000 business?

I suppose HP did us a favor. I don’t want to speak heresy, but we’re seeing so many capabilities out there that go beyond what we were offered on the HP 3000. It’s always been difficult to sell HP 3000s, but the HP announcement made it even more difficult. It’s pretty much impossible when the creator of the machine says “We don’t believe in it anymore.”

But we had already been working on a transition before the announcement. It pushed us down the road a little bit. We had a desire to offer a world-class product to people again. Ten or 15 years ago we had that.

Where did you decide to take your application and your customer base?

Microsoft’s stuff has really matured a lot. It’s still something I love to hate, but Windows XP and Windows 2000 are very capable operating systems. With the combination of HP saying goodbye to the 3000 and Microsoft technology becoming more dependable and robust, I really think it’s possible.

The price of used HP 3000s is bound to drop over the next few years. Why not stay with a hardware choice that will get more cost effective?

We have a benchmark we love to quote, a sales report that runs in a little over an hour on a Series 927. It runs in 45 seconds on a Windows box we’re moving this code to. Sure, it could run faster on the newer 3000s, but they cost $25,000. The box we’re moving to has twin 2.4Ghz processors. I can buy that for three grand. Even if the price of used 3000s go to zero, we still have an image problem with processing power.

And why not move to HP-UX?

It’s too expensive compared to what else is out there. It’s cheaper than MPE, perhaps, but that’s not the comparison I was making: Windows has become a stable operating system that’s mainstream. We think it’s reliable if you treat it right.

Since you’ve chosen Microsoft as the new platform, a more obvious choice of database would have been SQL Server. Why did you decide to use Pervasive’s Wintel-based database instead?

SQL Server and Eloquence appear to be the front runners in the community doing migrations. But there are curious issues. I sat through the HP Webinar on the databases. What you hear about are nothing but problems with the concept of wrapper-ing SQL Server to emulate IMAGE. The truth is that it causes you to restructure quite a bit of code, or suffer performance problems, or both.

One of our rules in this migration is “don’t change a line of code in the business logic if you can avoid it.” You can’t do a SQL port and follow that rule. You have to make logic changes to the programs and test them all over again.

What was the AMS application written in, and where did you move it?

It’s 1.5 million lines of COBOL, and we had MicroFocus COBOL in mind. But MicroFocus has run-time fees, and that means they’re getting a piece of my pie [as a software vendor], and I don’t like that. It’s more expensive than the one I chose, Fujitsu’s NetCOBOL. MicroFocus also has as its underlying tenet that it should run on many different platforms, and while that was maybe a great idea for some, we have no intentions of running on more than one platform.
MicroFocus uses intermediate code, which you can compile and take to Unix or Windows. You realize there’s some baggage around that concept if you don’t need it. We know that Fujitsu’s product is a dark horse, but I like to see what other people are doing and then make up my own mind. So far we are going just fine with it.

What’s the unique value in using Pervasive, in your view?

The underlying technology is 10 or 15 years old and is stable. It started out as an ISAM system. They’ve layered a SQL interface over it. If you want to use the ISAM layer, you can. PC COBOL vendors have built a bridge to that ISAM layer, and the beauty of that for us is that all the KSAM stuff we’d built automatically ended up in this product. And we found a reasonable way to emulate IMAGE in this product. The few calls we had to KSAM intrinsics were converted to corresponding calls into the Pervasive product. When the day comes to SQL-enable the product, we can do so without an across-the-board performance problem, on a program-by-program basis.

What we’re getting out of this is phenomenal performance, and I’m quite certain it’s faster than a SQL wrapper. While you could probably wrapper KSAM with SQL Server, good luck. It wouldn’t be with standard COBOL reads and writes, and it’s not likely to be a simple process. Because we have developed our own COBOL pre-compiler, we can automatically make some changes to the COBOL code when targeting the Windows platform. We have used the pre-compiler to assist with the migration to Pervasive. With Pervasive, if you own your own precompiler you can handle almost any issue that comes up.

You mentioned some distinctions in price. What did the Pervasive choice total out at for you?

They have a workgroup engine which they cap at five users, and it’s around $150. I have a few clients that can live within that constraint, but not very many. Most would need 10-30 users. On the Web I have found a 10-user license selling for $975 and a 20-user license selling for around $1,900. I haven’t finished negotiations with Pervasive, but they have hinted there are steep discounts for bundled purchases. I have to get a little further along in my conversion before I can find out when my clients want to migrate. At that time I will have quantities and so will be ready to negotiate price with Pervasive.

My guess is that these prices aren’t wildly different from SQL Server. But I need the functionality Pervasive offers over SQL Server. I want my KSAM and IMAGE data in the same database. Eloquence is an excellent product to replace IMAGE. But it doesn’t have a mature documentation set, not as complete as you’d find in a mainstream product. Eloquence won’t support KSAM, and two-thirds of our product is in KSAM.

So you think there’s a connection between IMAGE and ISAM?

Depending on how you have used IMAGE, you may find that IMAGE and ISAM are closer than IMAGE and SQL. Generally you do things in IMAGE a record at a time. You walk down datasets and chains a record at a time; you also do that in ISAM. In most cases an IMAGE chain can be reasonably emulated in an ISAM file. When accessing a SQL table, the data is retrieved from the database in chunks called record sets. You are actually working with a copy of the data. This concept is not bad if you are starting from scratch, but it can create a number of problems in the areas of locking and performance if you are trying to “wrap” SQL to make it look like IMAGE.

I should point out that we analyzed our specific use of IMAGE before making the choice to migrate to the Pervasive product and proved to ourselves that this would work for us. Others may have used IMAGE in a way that would make this migration much more difficult. One important factor for us was that all of our IMAGE database calls are in COBOL copy libraries. We have been able to use the conditional compilation feature of our COBOL pre-compiler to substitute appropriate calls to the Pervasive database in place of the calls to IMAGE.