June 2003
Throwing Open A Window to Low-Cost Power,
continued
What about operating environment stability? There’s
always been concerns about the Windows choice in that area.
I’m a Microsoft hater, so I’ll start off with that.
I certainly approached it with some skepticism. But what I realized
about my complaints with Microsoft’s operating system stability
is that Windows is its own worst enemy. You can walk up to a Windows
2000 server, grab a mouse and just start clicking around in there.
There’s no audit trail of what you did and no way to put it
back. The user-friendly nature of the operating system lends itself
to tinkering and de-stabilization.
When an individual walks up to a 3000, they are not as likely
to just idly explore its utilities and tweak things. It’s just
not that easy. I also believe that some of the mystique of the
3000’s reliability has to do with discipline. I started working
with computers in an era where the server was somewhat sacred, and
you don’t tinker with it without some trepidation. It’s my
experience with Windows 2000 servers that you can create a stable
environment if you treat it with the respect that you would a 3000
box. I think it is also important to avoid using the raft of new
features that Microsoft throws at you constantly. They sometimes do
not work perfectly.
How do you keep the users of the systems from doing damage
to the system inadvertently?
I think that’s an issue. We are telling our customers
that our software has to be warehoused on its own Windows server.
We’re going to ask that they not play with it, and of course I
believe we’re going to be allowed to password protect the
machines, so a supervisor has the password and we have the password.
Today on our 3000 servers at our installations a lot of people
don’t even know they have a system manager password. For the
most part we have established a pattern of “let AMS take care of
the server.” There’s no doubt that a Linux box or a Unix
box would have many of the unfriendly attributes that they’re
reputed to have, and that would keep people away from it.
How will you protect these servers from the outside
world?
They’re always behind firewalls. One should acknowledge
that one of the main things that protects the 3000 from attack is the
ignorance of the person attacking. In some ways the 3000 is not that
secure. You can hack at the 3000 all day to find the password and it
won’t lock you out, unless you buy add-on third-party software
to protect it. The simple nature of the sign on process makes it an
easier target for hacking.
Windows boxes have policies you can set to lock people out
after the third try. To the extent that people insist on using a
Windows server that they have, they are agreeing to supply the
security for it.
Microsoft puts out a lot of patches for security, and
you can read that either way: they have a huge problem, or they are
very responsive. It should be noted that many of the patches are not
for the core Windows operating system. If you don’t load a lot
of things on the server that you don’t need, you can mitigate
the risks somewhat.
Do any of the wineries need 24x7 availability?
Not now, though we’re hoping to Web-enable the
application which will increase the need for uptime. I don’t see
anything in Windows that would critically limit our uptime. I’ve
had Windows servers we haven’t rebooted for months at a time.
Sure, I know of 3000s that have not been rebooted in years, but the
distinction between years and months is not important in our
environment.
What do you think you’ve expended in resources on
moving your application so far?
Well there is what it cost, and what it should have cost.
It’s hard to estimate what the true costs should have been.
There’s been some wasted motion. We’ve changed our minds on
some things several times. I’d say our approach has been pretty
expensive. We have developed quite a few tools in-house.
For example, we’ve written our own database locking
tool, because nothing locks like IMAGE, not SQL Server, not Pervasive
either.
We have written our own COBOL pre-compiler, so that
individual programs need not be changed by human fingers. The most
expensive development was our Formspec/Reflection replacement, which
was very expensive but key to our future. This tool automatically
converts Formspec form files to Microsoft Visual studio .NET DLLs,
supports form families, preserves Formspec field editing
specifications and produces resizable screens like Reflection has. It
also allows us to add calendar controls, calculator controls and
lookup boxes to our application.
To answer your question, I would say I’ve spent between
a third and a half-million dollars on the migration. If I could do it
over with what I know right now, I could probably cut that in half
easily. It’s a lot of money, but I don’t know that it is
out of line when compared to the other options. I talked to companies
who claimed to be able to convert the entire system automatically.
Their price tags were not all that palatable and involved on-going
run time fees, too. The approach we have taken gives us the most
flexibility, perhaps at a cost.
Doing the work yourself, how many people have been
involved?
Three full-time in-house COBOL programmers, a COBOL
contractor, a full time in-house Visual Basic programmer and a full
time VB contractor. The burn rate’s pretty ugly.
What’s the justification to spend that money?
This move was justified on the basis of extending the life of
the product, in the hopes of picking up new customers. But we
don’t have to pick up new customers to justify the cost.
What about replacements for the third party software your
customers use on their HP 3000s?
That’s the miracle of being a cheapskate, I guess. Our
product doesn’t have any third party stuff in it. We use only
what comes with the 3000’s Fundamental Operating System, like
STORE, which we’ve wrappered with a menu. Most of our clients
have data that fits on a 2Gb disk drive.
How have you replaced MPE’s batch processing in
Windows?
There’s absolutely nothing like a real job handler quite
built into Windows. We have written a job file converter which
produces “DOS” command files. We have written our own job
queue manager in COBOL that runs as a service under Windows. One
amazing thing to watch is how we test our jobs that produce reports.
When testing these we are able to request a job on the 3000 the way
we always have; the job is streamed on the 3000 and at the same time
it is downloaded to the Windows server, converted on the fly to a
“DOS” command file and “streamed” under our
Windows system. The finished reports are both delivered to the
tester’s desktop for review in our Windows-based spool-file
viewer (developed in-house in VB and COBOL). The Windows server
always finishes long before the 3000 – no contest – not
even close. Of course our HP 3000 is only a 967.
You’ve made choices in design that require some
sophisticated programming. Do you think this approach would be
cost-justified for a small shop?
The way I look at it is that we’re building a new
sandbox. I don’t want to touch the business logic. Our HP 3000
app is going to land in a new sandbox, and work the way it always did
— but it will look much nicer, run much faster and have a new
life. I’m not sure it’s cost-justified for a small shop
with custom code to go through this process.
If I only had a single installation of this application to
migrate I believe I would come up with a different solution. I might
be inclined to stay on the 3000 as long as possible if the
application was meeting my needs. It is possible to extend the life
of software on the 3000 and improve its look and feel. For a while we
were planning to offer our clients our new Windows look on the
good-old 3000 but in the end that did not seem like the best business
decision for us.
Now that you’re almost ready to send code out to a
customer, what would you change about your design choices?
It turns out that the newest version of Fujitsu COBOL is
quite capable of building compelling Windows user interfaces. This
was not the case when we started out on this project. If I were
starting out again I would not introduce Visual Basic into the mix.
The staff I’ve had for many years has learned the WIN32 API
easily. My COBOL programmers have adapted very quickly to the new
technology available to them, and they’re more productive than
the VB programmers. If I had to do this all over again, I’d do
the whole thing in COBOL, including the front end. I know this is
heresy on the Windows platform.
We also made a failed attempt to use SQL Server which wasted
several man-months of time; don’t go there. Another thing I
might do differently is to use Adobe Acrobat reader as our report
viewing tool. We have developed our own report viewing tool which
works with both 3000 spool files and those we get from our new
product. The cost of this tool was very high. Although it works
better than Acrobat and integrates better into our product, Acrobat
is also a capable tool. Of course you must convert spool files into
PDFs, but that is much simpler than producing a full-blown report
viewing tool.
How much of the work is in making choices?
We spent many months working with various technologies,
including even a bit of Linux tinkering. I suppose we spent between
six and 12 man-months probing and playing with the options available
to us. While it is exciting to play with new things, it is also a
sobering experience when you realize what is at stake.
It’s very frightening to pick a database product and
wonder if it’s going to do the job, or a COBOL compiler and
wonder if it’s going to do the job. What if you pick the wrong
tools? The consequences of making a mistake are enormous! On the 3000
you didn’t have to think about that, because you didn’t
have as many choices. It’s kind of a high-wire act to go through
this process. Now we’re far enough along that I know we’re
going to make it. But there were times when I wasn’t so sure
because the number of obstacles seemed nearly insurmountable.
It has been important during this project to be flexible and
innovative while staying true to the goal, which for us is migrating
a valuable asset that is both proven and reliable to a new
environment. I will always respect what the 3000 gave us; a
dependable cost-effective platform on which to offer solutions.
However, I believe there are bright exciting things ahead
waiting to be discovered on other platforms. I can say without
reservation and from personal experience that a well-built and
properly maintained Windows 2000 server can be very reliable,
certainly more reliable than the HP 3000 I started out on in 1976.
|