Intelligence About Migration
Jim Kramer is developing a migration practice at Lund,
working from the experience of a lifes work in development. The
head of R&D at Lund Performance Solutions, Kramer is on the move
this month with HPs migration road show, visiting cities across
the US to describe the future to several hundred customers curious
about migration. But Kramers long background stretches far back
into the HP 3000s history, to times when line editors were
commonplace tools and a 2645 terminal was, in his words, the
spiffiest thing wed ever seen.
Kramer is probably best known among HP 3000 veterans
for writing QUAD, a contributed software editor that was ubiquitous
among sites that couldnt afford a commercial programming editor
and couldnt stand HPs 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
HPs 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 hes
extended his work as Director of Research and Development into the
companys migration professional services, researching tools and
practices that Lund recommends for customers on the move away from
the 3000. Given Kramers lengthy resume in servers of all sizes
and pedigrees, varied software environments, and developing for MPE,
we wondered why hes stepped into migration for Lund and what
technical challenges he sees ahead. Just before Kramer was leaving
for this falls HP road show, we spoke in a conversation where
he expanded on the answers hed sent via e-mail.
In the HP 3000 community there arent too many people
who can work in both systems and application development. Which do
Im certainly more on the systems side. The work at CDB
Infotek was more of a system environment for the application to run
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
Id 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 whos heading up the Unix side of the house, Chris
Reimer. He takes quite a burden off me so I can concentrate on
Whats the scope of that work?
Helping the customers be aware of whats out there and
how they can get their application migrated. Im personally
learning the tools and helping with the sales effort.
Is there anything technically wrong or outdated about the
HP 3000s architecture? Something that makes it a less than
superior choice for a customer needing a highly reliable enterprise
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
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
The challenge in migration is to avoid changing things in the
code thats 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
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? Thats a
strategy some migrating customers may be following at first.
Youve said using an emulator like one from Denkart or Neartek
is a place customers can be slow to leave.
Its 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 cant find a reason to leave [emulation], thats 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 customers 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
todays HP 3000 have a future as a system converted to a
Almost certainly youre going to have a 3000 and the
target 9000 platform running concurrently. I dont see any way
around that. I dont see somebody coming in over the weekend and
changing a production 3000 to a 9000. Id never suggest that.
There are options on whether you throw the switch one day, or
gradually migrate it.
Whats the coolest thing, from a tech standpoint,
that you see a non-MPE environment offering?
Im 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
users viewpoint and an administrators viewpoint it is
less elegant than MPE. However a lot of the software action is there,
and Ive 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
havent advanced much. Microsofts 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
Im excited about anything, its .NET.
Do you see HP-UX as delivering unique value in the Unix
I dont have any impression that there are strong
technical reasons for buying HP-UX over anything else, but Im
not strong in this area. People do love the HP hardware.
Has it been difficult for Lund to find MPE expertise
since HPs end of 3000 support announcement?
No, this hasnt been an issue. I suppose it could be
when many shops start their migrations. Weve found that people
are available, and that it is possible still to train people to do
MPE work. We have had success with that. Weve 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 its any more difficult to learn MPE
and the 3000s technology than any other
No, its probably easier. When you compare learning
Unix, and if youre going to be a programmer, a language like
C++, with tons of class libraries, its a really steep learning
curve for the modern programmer.
What does IMAGE bring to a companys database
resources that SQL-based databases cannot match?
I am far from expert in this area, but I believe
TurboIMAGEs 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 dont 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.
Whats 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
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
Youve spent more than two decades learning about the
HP 3000s 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
There are other examples. People who excel in one technical
area will usually excel in others also, so try to get them working
Is it possible that MPE experience may become more
valuable in the years to come, like the COBOL experience during the
Its 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 were advocating, youre still calling
IMAGE and VPlus. In many of the cases Ive 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 dont want to migrate?
The approach that Gavin Scott and Allegro are taking is
absolutely the right one. If youre going to make something
succeed, youll 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. Thats the way people like to do these things,
like when running Windows under Unix. You dont want to have to
change the software thats 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
I would say thats not a problem. Once the Posix
environment was there in MPE, the software that was brought in
didnt 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.