HP3000-L Archives

February 2001, Week 4

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:
Charles Finley <[log in to unmask]>
Reply To:
Date:
Wed, 28 Feb 2001 12:05:47 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (79 lines)
It is not risky to port 4th generation languages like POWERHOUSE.  The best
path is to translate the code into C++, JAVA or some other object oriented
language.  In essence what you do is create a model of the source language
using a combination of classes and libraries.  You then translate the
POWERHOUSE code to your the represntation of POWERHOUSE and off you go.
What you end up by using compilers and run time libraries is in essence, a
POWERHOUSE translator and emulator. The rest of the MPE stuff that you need
to emulate includes IMAGE (using HP Eloquence or an RDBMS with some c
libraries that we have), HP Intrinsics, a job scheduler, a spooler and an
MPE shell.  We have all of this.

The technical problems are not difficult to overcome.  The business issues
can be more difficult.  First, you may not be able to continue to develop
using POWERHOUSE.  If you still pay fees to COGNOS, they may allow you to
continue to development on the licensed computers, you could then translate
the code and off you go.  We would not advise you to do this but it is
possible.  After such a migration, you would be able to develop in C++,
JAVA, FORTE' (which, I believe generates C++), etc.  This is what you should
do.

This is not risky, because you are not changing business logic or data.  I
think it is more risky to move to a new package or to rewrite.  Please note
that I believe these are both good options and are more often the best
option. However, we do 100% migrations.  When we're done, you know what you
have.  Moreover, we do not require you to change your busines processes or
retrain most of the non-technical people.  Also, your programmers already
know what the programs do.  They, in one sense, haven't changed all that
much.

Charles "plug 'em if you got 'em" Finley
[log in to unmask]


> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of COLE,GLENN (Non-HP-SantaClara,ex2)
> Sent: Wednesday, February 28, 2001 10:36 AM
> To: [log in to unmask]
> Subject: Re: Q: Powerhouse-Migration
>
>
> Andreas Schmidt writes:
>
> > I was asked by a colleaugue in Australia:
> >
> > We currently support a manufacturing application written in POWERHOUSE
> > (1Tree) and I am wondering if any-one knows where we may have migrated
> > this technology (POWERHOUSE) to a newer toolset and database.
>
> This sounds more like a tool-driven update rather than a business-driven
> update.  Kinda like switching out Macs for PCs even when the Macs
> work fine.
>
> And it's not like either PowerHouse or Image/SQL has languished.
>
> While there may well be business reasons to update, they need to
> realize that the newer toolset and database will require greater
> manpower to maintain, with a greater chance for breakage due to
> the increased complexity of the system.  (And yes, both are a given.)
>
> Also, the industry is rife with stories of staggering costs associated
> with attempted migration to a "newer toolset and database."  There are
> anecdotal stories even on hp3000-L about nightmares when trying to move
> to an Oracle/UN*X solution.  And even after a successful migration,
> greater costs remain, for both the people and the products.
>
> This is not to say that such migrations are doomed before they begin.
> I'm sure Charles Finley can share plenty of success stories.
>
>    http://www.xformix.com/
>
> All this to say that it's clear to me that such a migration requires
> a concrete understanding of the specific goals of the project, a plan
> for how to accomplish these goals, a plan for when to "cut bait," and
> a healthy budget.
>
> --Glenn, who, rather than lecturing, is merely wary of such projects
>

ATOM RSS1 RSS2