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.