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 companys
application out of the MPE world for several years, and his
companys 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
Minisofts 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 Smiths AMS app didnt 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 HPs news. Smith had
already seen this coming, and so had begun to research moving his
application to Windows to use less costly Intel-based
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 hasnt been sealed yet,
Pervasives 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 hes leading his customers and company away from MPE
with some reluctance but not a lot. We found a technically
adept company leader whod grown up with the 3000, one
whos 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
Smiths 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
its been like to adopt a Windows view after seeing the world
from IMAGE-MPE eyes.
How long have you been working on moving your
Weve 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 HPs decision to drop its 3000
I suppose HP did us a favor. I dont want to speak
heresy, but were seeing so many capabilities out there that go
beyond what we were offered on the HP 3000. Its always been
difficult to sell HP 3000s, but the HP announcement made it even more
difficult. Its pretty much impossible when the creator of the
machine says We dont 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
Microsofts stuff has really matured a lot. Its
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 its 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
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 were moving this code to. Sure, it could run
faster on the newer 3000s, but they cost $25,000. The box were
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?
Its too expensive compared to what else is out there.
Its cheaper than MPE, perhaps, but thats not the
comparison I was making: Windows has become a stable operating system
thats mainstream. We think its reliable if you treat it
Since youve chosen Microsoft as the new platform, a
more obvious choice of database would have been SQL Server. Why did
you decide to use Pervasives Wintel-based database
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 dont change
a line of code in the business logic if you can avoid it. You
cant 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?
Its 1.5 million lines of COBOL, and we had MicroFocus
COBOL in mind. But MicroFocus has run-time fees, and that means
theyre getting a piece of my pie [as a software vendor], and I
dont like that. Its more expensive than the one I chose,
Fujitsus 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 theres some
baggage around that concept if you dont need it. We know that
Fujitsus 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.
Whats the unique value in using Pervasive, in your
The underlying technology is 10 or 15 years old and is
stable. It started out as an ISAM system. Theyve 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 wed 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
What were getting out of this is phenomenal
performance, and Im quite certain its faster than a SQL
wrapper. While you could probably wrapper KSAM with SQL Server, good
luck. It wouldnt be with standard COBOL reads and writes, and
its 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 its 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 havent 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 arent 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
doesnt have a mature documentation set, not as complete as
youd find in a mainstream product. Eloquence wont support
KSAM, and two-thirds of our product is in KSAM.
So you think theres a connection between IMAGE and
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