Developing Intelligence About Migration

Jim Kramer is developing a migration practice at Lund, working from the experience of a life’s work in development. The head of R&D at Lund Performance Solutions, Kramer is on the move this month with HP’s migration road show, visiting cities across the US to describe the future to several hundred customers curious about migration. But Kramer’s long background stretches far back into the HP 3000’s history, to times when line editors were commonplace tools and a 2645 terminal was, in his words, “the spiffiest thing we’d ever seen.”

Kramer is probably best known among HP 3000 veterans for writing QUAD, a contributed software editor that was ubiquitous among sites that couldn’t afford a commercial programming editor and couldn’t stand HP’s software. He said he wrote the program, which he called QUAD to represent its “Quick And Dirty” keeps of files, while working at HP “because HP’s EDITOR/3000 was just too slow.” Kramer worked for Hewlett-Packard for 12 years, but encountered his first 3000 earlier using a Series II 3000 at a Citicorp subsidiary. The 3000 exposure came after experience at corporations such as McDonnell Douglas and General Electric, developing for minis and mainframes from Control Data, GE and Varian. After leaving HP in 1990 he moved to Quest Software, using QUAD as his reference to get a job developing Netware for MPE/iX. Later he managed a Unix replication project and did kernel programming for Quest in the era of HP-UX 10.10.

In a two-year hiatus from Quest, Kramer did what he called “the best work of my life” for CDB Infotek using the HP 3000 — redesigning a searching application that used a high-level language to glue searches together and simplify the placement of user interfaces.

In 1997 Kramer joined Lund “as a developer at heart,” leading its technical teams in creating Performance Gallery Gold, revamping its SOS performance product, and finally creating its new Meta-View Performance Manager. This year he’s extended his work as Director of Research and Development into the company’s migration professional services, researching tools and practices that Lund recommends for customers on the move away from the 3000. Given Kramer’s lengthy resume in servers of all sizes and pedigrees, varied software environments, and developing for MPE, we wondered why he’s stepped into migration for Lund and what technical challenges he sees ahead. Just before Kramer was leaving for this fall’s HP road show, we spoke in a conversation where he expanded on the answers he’d sent via e-mail.

In the HP 3000 community there aren’t too many people who can work in both systems and application development. Which do you prefer?

I’m certainly more on the systems side. The work at CDB Infotek was more of a system environment for the application to run in.

Your experience with MPE and IMAGE is long. What makes other environments interesting to you now?

I assume you are asking me this because of the migration services we are now offering. Actually an interest in other environments is not new either to me or to Lund. I have worked on many platforms and investigated many others, though certainly MPE has been the main one.

Even before I joined the company, Lund was offering its SOS product on HP-UX, and also had two performance products on Windows. Since I manage the development here I am naturally interested in these environments.

I’d like to make it clear, though, that we have not turned our back on MPE, and we continue to maintain and enhance our MPE products. We have recently released file replication for Shadow D/R, and will soon release Image statistics for SOS/3000. We have also just announced Meta-View Performance Manager, which provides new graphical interfaces for SOS/3000 and our other SOS products.

I still head up all of our development, though I have a very strong guy who’s heading up the Unix side of the house, Chris Reimer. He takes quite a burden off me so I can concentrate on migration.

What’s the scope of that work?

Helping the customers be aware of what’s out there and how they can get their application migrated. I’m personally learning the tools and helping with the sales effort.

Is there anything technically wrong or outdated about the HP 3000’s architecture? Something that makes it a less than superior choice for a customer needing a highly reliable enterprise environment?

There is certainly nothing wrong with the e3000 technically. Instead there is so much right with it, including its cost-effectiveness and its reliability. If there is a technical problem, it is the lack of a good relational database, which many customers want.

Your experience until recently was fixed in development. Why did you want to branch out into the work of customer migration and new environment implementation?

Migration fits very naturally with our expertise and business activities; i.e. with the consulting we do, and with the multi-platform development we do. For me it is not really a departure from development, just another aspect of it. Some of my more enjoyable and rewarding development projects in the past were migration activities.

The challenge in migration is to avoid changing things in the code that’s being migrated. Rather one should try to provide an environment that fits the code.

One of my migration activities for a former employer was to get a mass of Unix code working on MPE. I was hired at Quest to port what Novell was calling Portable Netware to the 3000. We provided a Unix environment on MPE, including Streams networking, before HP did! Of course it was a restricted environment, not a general-purpose one.
The other factor in our decision in doing migration work is that it is something that customers need now, and we are always trying to meet customer needs.

Were there lessons in that Quest project for you about creating an emulated environment on another platform? That’s a strategy some migrating customers may be following at first. You’ve said using an emulator like one from Denkart or Neartek is a place customers can be slow to leave.

It’s a point. That work was exactly the same thing a lot of people are doing to get HP 3000 code running on Unix or Windows. If you can’t find a reason to leave [emulation], that’s a good thing. The Novell had lots of Unix calls embedded in it, just like with the Neartek and Denkart software we want to be able to handle a bunch of TurboIMAGE calls.

Do you find that budget considerations top the list of what customers are reviewing while making a decision about their future on the HP 3000?

Of course the item at the top of the customer’s list is creating a viable information environment to replace what the e3000 is currently doing.
Budget is probably next on the list, and this is natural. In business one analyzes both benefits and costs. It is especially important with migration, since the costs are large, probably far larger than Y2K costs for most customers.

Another important consideration is the nature of the environment being created. For instance, will it be easy to support and enhance going forward? There are many aspects to this: ease of migrating again if necessary, availability of modern development tools, the strength of the hardware and software vendors, etc.

Is there a natural implementation process that requires two sets of hardware running parallel in migrations? Does today’s HP 3000 have a future as a system converted to a 9000?

Almost certainly you’re going to have a 3000 and the target 9000 platform running concurrently. I don’t see any way around that. I don’t see somebody coming in over the weekend and changing a production 3000 to a 9000. I’d never suggest that. There are options on whether you throw the switch one day, or gradually migrate it.

What’s the coolest thing, from a tech standpoint, that you see a non-MPE environment offering?

I’m glad you asked me this question, since I am still a techie at heart. Of course Unix is a solid platform, but it is just another 30-year-old timesharing operating system like MPE. From a user’s viewpoint and an administrator’s viewpoint it is less elegant than MPE. However a lot of the software action is there, and I’ve always admired the programmer interface, the system calls. This is the elegant aspect of Unix. Unfortunately MPE has become somewhat ugly over the years in this area: too complex, too many different ways to do things.

Windows is a fairly ordinary OS also, but it is nice in that the GUI is well integrated into the OS, not just pasted on as it is with Unix. The best user applications are on Windows also, which is why it has been so successful. And I must say it pleases me that I can install patches with a few point-and-click operations. With MPE there is a 500-page manual that one must learn to use. I still face an MPE patch or update with a bit of fear.

An interesting defect in Windows is the lack of scripting capabilities. With MPE and Unix, since they are text based, one can almost always do in a script what one can do interactively.

What I think would be really cool is a good object-oriented operating system. [Niklaus] Wirth showed some of what was possible with his work on Oberon, but our commercial operating systems haven’t advanced much. Microsoft’s doing a lot of nice things with .NET. All of the libraries are shared among languages, so Visual Basic calls the same routines as C#, for example. It would be nice if the operating system would use the same class structure, which makes the operating system more reliable and useful. If I’m excited about anything, it’s .NET.

Do you see HP-UX as delivering unique value in the Unix marketplace?

I don’t have any impression that there are strong technical reasons for buying HP-UX over anything else, but I’m not strong in this area. People do love the HP hardware.

Has it been difficult for Lund to find MPE expertise since HP’s end of 3000 support announcement?

No, this hasn’t been an issue. I suppose it could be when many shops start their migrations. We’ve found that people are available, and that it is possible still to train people to do MPE work. We have had success with that. We’ve taken a young guy right out of college and a more experienced engineer and made MPE engineers out of them. They find MPE to be very interesting, and even if a programmer might not want to make a career of being an MPE programmer, he or she may still find it to be enjoyable work for many years. The guy right out of college is doing as advanced MPE programming as almost anybody: mapped files, procedure exits, semaphores. When you get talented people, they can amaze you.

Would you say it’s any more difficult to learn MPE and the 3000’s technology than any other environment’s?

No, it’s probably easier. When you compare learning Unix, and if you’re going to be a programmer, a language like C++, with tons of class libraries, it’s a really steep learning curve for the modern programmer.

What does IMAGE bring to a company’s database resources that SQL-based databases cannot match?

I am far from expert in this area, but I believe TurboIMAGE’s strength, aside from reliability, is price-performance. I have often asked myself how the life of the e3000 might have been extended, and the answer I always come up with is to position it as a database server for very large applications. This would mean making it a transparent or near-transparent replacement for relational database servers, and aggressively marketing it in that way. I don’t know if it would have worked, but I think the e3000 would have had a better chance for a longer life as a great database machine than as a mediocre Unix machine. You want to try to build on strength.

What’s the most costly investment a company is likely to see while making a transition away from the HP 3000? Why is that expense worth it?

I think this question gets to the heart of why so many people are so unhappy about the planned demise of the e3000. There will be a lot of money spent just to stay where you currently are on the e3000. The money will be spent on project leaders and programmers to do the migrations, on new machines, on training for IT staff and users, on relational databases, on licensing fees for compilers and emulation environments.

The cost is worth it only because you must continue to have the capability you currently have.

There is a lot to be said about migration and about how to do it efficiently to minimize costs. Generally, for applications that a company wants to retain, we advocate an emulation approach that requires minimal changes to code and scripts. We consider this the low-cost, low-risk approach. It minimizes programmer and user effort, keeping costs and bugs down. There is a lot of good software available now to recreate most aspects of an MPE environment. We have set ourselves the task of becoming experts in this area, and we are getting there.

You’ve spent more than two decades learning about the HP 3000’s technology. How much value do you expect your own MPE expertise will hold over the next five years?

MPE expertise will continue to have value for quite awhile. MPE is not disappearing for many years, certainly many more than five. This expertise will continue to be valuable, especially as people do their migrations.

Also, good people can learn new things. In my hiring I have always tried to find the good people, the good programmers, without too much concern for the specific knowledge. I have hired a Unix programmer and a Foxpro programmer to do C programming on MPE. My best COBOL programmer went on to become my best Visual Basic programmer, then my best Powerhouse programmer, then one of my best C programmers.

There are other examples. People who excel in one technical area will usually excel in others also, so try to get them working for you.

Is it possible that MPE experience may become more valuable in the years to come, like the COBOL experience during the Y2K era?

It’s possible, and there might be a real peak in demand when people get serious about migrating their boxes. Y2K occurred to me, when the COBOL programmers came out of retirement to make $100 an hour. You could say, “Why not use the Unix people to do the migration?” My early impression is that in the kind of work we will be doing, using the emulators, the MPE knowledge is going to be far more valuable than the Unix knowledge. If you go to an emulation approach, which we’re advocating, you’re still calling IMAGE and VPlus. In many of the cases I’ve seen so far, companies are using their MPE people and helping them become knowledgeable on the platform.

And what about the homesteading, OpenMPE options for customers who don’t want to migrate?

The approach that Gavin Scott and Allegro are taking is absolutely the right one. If you’re going to make something succeed, you’ll take the point of view of creating an environment where MPE/iX 7.5 can run, boot off the 7.5 tape, with no bits changed. That’s the way people like to do these things, like when running Windows under Unix. You don’t want to have to change the software that’s using the emulator.

Does the ability to enhance the MPE operating system seem as important as crafting a 3000 hardware emulator? Some are concerned that MPE looks pretty static in a hardware emulator environment.

I would say that’s not a problem. Once the Posix environment was there in MPE, the software that was brought in didn’t require changes, as far as I know. Clearly, the current MPE environment supports a lot of software. In the emulated environment, new hardware will be handled by the emulator. You may have to break a large disk down in many smaller disks in the future, but it will support new hardware.