HP3000-L Archives

October 2002, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
[log in to unmask][log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, October 10, 2002 10:39 AM
Subject: Re: [HP3000-L] FW: Fiorina dings Dell. And Sun. And EMC (Tech
Update Alert)

> In a message dated 10/10/2002 9:59:40 AM Pacific Daylight Time,
> [log in to unmask] writes:
>
>
> > H-P is a zombie, it
> > really is dead, it just won't lie down and stop moving.
>
> Very harsh words, but you know what? I agree with you! I said the same
> [...]50_10Oct200212:57:[log in to unmask]
Date:
Tue, 8 Oct 2002 14:38:26 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
Tom writes after Gavin:

> >Interesting.  I would have expected this sort of customer to be precisely
>  >the sort that the migration providers would see as their target market.
>
>  These customers are being aggressively targeted by the migration providers,
>  but the customers aren't buying what they are selling because
>
>  >it seems that replacement would be a much simpler and more cost
>  >effective solution [than migrating] for the majority of customers.

Tom recapitulates my observations and prejudices as well. Indeed, I never
believed that many people would actually "migrate," even among those who had
wholly home-grown applications.

The problem with the home-grown applications is that they were developed over
many years, if not decades, and they are extremely well-smoothed to the
current situation, yet everyone remembers the "smoothing" problems. Worse,
the people who developed those applications long ago left the organization,
and no one wants to go through those developmental problems again.

I have believed from the beginning that the number of organizations that
would "migrate" their applications would be a very small number.

Those organizations that are running applications still supported by an
active vendor have the least to worry to about and will have the easiest
times in the near-term future. Their applications vendors will do everything
they can to make their "migration" as painless as possible -- but not
necessarily inexpensive :-).

For everyone else, the easiest, safest thing for them to do is simply to take
their time, look around, and select an existing application that is as close
to what they're currently now using as they can and simply migrate their
business onto the new application over a weekend, a week, a month or even a
year. This solution has the advantage of being already well-smoothed, and
most importantly, having someone standing behind it -- without even
mentioning that its price will only be a tiny fraction of the cost of
"migration." Without the evolution of an MPE emulator, I believe that this is
the path that most of the "homesteaders" will choose.

What I hear from our customers are two things: The first is, "I just want to
keep the HP3000 alive long enough (five to ten years) for me to retire,"
obviously meaning, "Let it be someone else's problem." The second is,
"There's no way that I can go to my boss and tell him that because HP screwed
us over we need to spend one to two million dollars migrating our code over
to a new box and have me look good."

But with the emulator, the world changes a bit -- or perhaps even
drastically. I continue to estimate that with an existence of an emulator
somewhere between 10 to 20 percent of the HP3000 user base will not move, if
for no other reason than cost and human inertia. A supported emulator would
solve their problems in way that no other path does. And if the emulator is
well enough done, and inexpensive enough, and without onerous restrictions
imposed on it by HP, it could actually spread quite quickly. MPE still has a
great deal of value to a business organization, especially if they are faced
with the complexity of UNIX/Linux.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2