Options for HP 3000 Transformation
April 2, 2018
By Bruce McRitchie
VerraDyne
Time — it marches on. We can measure it, bend it and try to avoid it. But in the end the clock keeps ticking. This is true for owners of the venerable HP 3000. In its day one of the top minicomputers ever manufactured, it went head-on against IBM (mainframes, AS/400, and System 36), Wang and Digital - and won many of those battles. And many HP 3000s are still running and doing the job they were designed to do. They have been upgraded, repaired and tinkered with to keep them viable. But when is it time for them to retire?
There are options. Many vendors have been working diligently to provide a transformation path to move from the HP 3000 to a modern platform and language. By making such a move these organizational risks are reduced:
- Hardware failure.
- Personnel failure - aging programmers.
- Software failure.
So why aren't the remaining HP 3000 owners flocking to newer technology? Is it because they know the technology so well — and it works? Have they been through large ugly development projects and never want to go through the pain again?
Whatever the reasoning, the arguments for staying with HP 3000 must be wearing thin. There are options, and to a greater or lesser extent, they all do the transformation job. Today's technology will allow companies to move their whole HP 3000 environment to a new modern environment, with or without changing language and operating system elements. Of course, with the different paths there are trade-offs that must be considered. This article briefly explores some of the options available to transform your HP 3000.
Emulation
At first glance this can appear to be the cheapest and easiest solution. A company picks the supplier of the emulation software, installs it, then puts their code on top and voila—their system is running as it always did.
But is it? You may now have an emulator interpreting instructions from your HP 3000 and the new operating system you'll use to run the emulator. Is that interpretation always correct?
And what about the cost of emulation? Of course, there is the initial cost. But what of the ongoing costs? You now have to pay for the emulator and the native OS that drives it.
Here are some of the deficiencies we have noted over the years:
• Being an emulation of the existing system, it still requires continued use of old skill-sets. Add that to the new skill-set required to be learned for the emulation layer. Some emulation designs will also require new skill-sets for the target open systems platform and COBOL. You can now have a highly complex skill-set requirement for the IT staff and potentially a new OS to contend with.
• Some emulators only support certain parts of the current system; they do not support all the components that are currently used.
• If the application has to sit on top of the emulation layer, then access to the native operating system is restricted.
• Interoperability with other applications or services on the platform can sometimes be severely restricted.
• Emulators mimic the data structures of the legacy system. This is great for running the current system as is, but does nothing to make the data accessible outside to other systems, inquiry or reporting tools.
• Running emulation renders the customer completely dependent upon the emulation vendor for ongoing support and upgrades, which in itself is a sizable risk factor.
In other words, emulation can bring its own new set of problems.
Redevelopment
The specter of re-development haunts most people (especially those who have been large development projects and cannot forget the late nights, long days, and missed vacations). Defining the business requirements, architecting the new solution, finding business analysts, programmers and project managers. Persevering through a long and drawn out process with hundreds of meetings, thousands of decisions — and finally— testing!
Hours and hours of trying to figure out if it can work well enough for the business needs. And then the bill comes. In some cases, millions of dollars, years of effort—and believe it or not, after all the years of improving —many development projects still fail.
These considerations are even more important today, when business needs are quickly changing and the underlying technology is changing to keep up. The whole platform on which the system is developed will change during the project.
Companies have spent years injecting their business intelligence into their software. Re-developing is a sure way to erode that valuable asset.
Migration
Migration offers a lower risk, lower-cost solution than re-development—so that you can end up with the functionality you need, in a language and operating system that is modern and supported by many resources.
Maybe you are running COBOL on your HP 3000 under MPE/iX but would like to be running VB on Windows. VerraDyne can do such a migration. And we can do it at a reasonable price in a reasonable time frame.
Simply put, migration is the process of moving the current applications onto a new open system platform so that they run in 'true native' mode on that new platform. However, after migration, the application and core business logic are still the mature proven systems that they were on the old legacy platform. The old proprietary legacy components are removed and are replaced by the modern components of the new open system platform.
These are the main points when considering automated conversion with no use of proprietary middleware:
• Migration removes the old legacy skill sets but it does not affect the core business logic, so the customer's systems and existing programming staff can quickly retake ownership of the converted code and continue maintaining it with very little retraining. The converted system can be deployed on the new open system with the same screens and processes that existed on the legacy platform, so user department retraining is virtually eliminated.
• Since the converted applications operate on the new open system identically as they did on the HP 3000, determining successful migration is black and white. The converted system either runs the same or it doesn't — if it doesn't, it is fixed until it does. There is no gray area, there is no 'maybe' — obtaining successful project completion is a clear and concise process.
• By minimizing manual intervention, automated conversion provides an extremely low risk, short timeframe solution. The majority of the project cycle is devoted to the most important task of testing.
• The converted system runs as a 'true native' application on the targeted open system, so there are no roadblocks to gaining the full benefits of the new open systems platform: GUI screens, Web functionality, databases and more
• Conversion provides all the benefits a company seeks without any trade-offs. It absolutely minimizes intrusion into the company's operations. The entire project is performed at very low risk.
• After conversion, the customer has full ownership of its code. There is no dependence on the migration vendor after conversion.
VerraDyne has spent 25 years developing converters that move language and OS code from one platform to another. We have done it with hundreds of systems. At the end of a project you have a system that looks, feels and behaves like the old system, but is able to take advantage of new technologies. This is our claim to fame and our intellectual property, and we are very good at it.