PowerHouse users study migration flights
May 6, 2014
A sometimes surprising group of companies continue to use software from the PowerHouse fourth generation language lineup on their HP 3000s. At Boeing, for example -- a manufacturer whose Boeing 737 assembly line pushes out one aircraft's airframe every day -- the products are essential to one mission-critical application. Upgrade fees for PowerHouse became a crucial element in deciding whether to homestead on the CHARON emulator last year.
PowerHouse products have a stickiness to them that can surprise, here in 2014, because of the age of the underlying concept. But they're ingrained in IT operations to a degree that can make them linchpins. In a LinkedIn Group devoted to managing PowerHouse products, the topic of making a new era for 4GL has been discussed for the past week. Paul Stennett, a group systems manager with UK-based housebuilder Wainhomes, said that his company's transition to an HP-UX version of PowerHouse has worked more seamlessly -- so far -- than the prospect of replacing the PowerHouse MPE application with a package.
"The main driver was not to disrupt the business, which at the end of the day pays for IT," Stennett said. "It did take around 18 months to complete, but was implemented over a weekend. So the users logged off on Friday on the old system, and logged onto the new system on Monday. From an application point of view all the screens, reports and processes were the same."
This is the lift-and-shift migration strategy, taken to a new level because the proprietary language driving these applications has not changed. Business processes -- which will get reviewed in any thorough migration to see if they're still needed -- have the highest level of pain to change. Sometimes companies conclude that the enhancements derived from a replacement package are more than offset by required changes to business processes.
Enter the version of PowerHouse that runs on HP's supported Unix environment. It was a realistic choice for Stennett's company because the 4GL has a new owner this year in Unicom.
The discussion began with requests on information for porting PowerHouse apps to Java. The 4GL was created with a different goal in mind than Java's ideal of "write once, run anywhere." Productivity was the lure for users who moved to 4GLs such as PowerHouse, Speedware, and variants such as Protos and Transact. All but Protos now have support for other platforms.
And HP's venerated Transact -- which once ran the US Navy's Mark 85 torpedo facility at Keyport, Wash. -- can be replaced by ScreenJet's TransAction and then implemented on MPE. ScreenJet, which partnered with Transact's creator David Dummer to build this replacement, added that an MPE/iX TransAction implementation would work as a testing step toward an ultimate migration to other environments.
Bob Deskin, a former PowerHouse support manager who retired from IBM last year, sketched out why the fourth generation language is preserving so many in-house applications -- sometimes on platforms where the vendor has moved on, or set an exit date as with HP's OpenVMS.
Application systems, like many things, have inertia. They tend to obey Newton's first law. A body at rest tends to remain at rest unless acted upon by an outside force. The need for change was that outside force. When an application requires major change, the decision must be made to do extensive modifications to the existing system, to write a new system, or to buy a package. During the '90s, the answer was often to buy a package.
But packages are expensive so companies are looking at leveraging what they have. If they feel that the current 4GL application can't give them what they need, but the internal logic is still viable, they look for migration or conversion tools. Rather than completely re-write, it may be easier to convert and add on now that Java and C++ programmers are readily available.
Deskin added as part of his opinion of what happened to 4GLs that they were never ubiquitous -- not even in an environment like the HP 3000's, where development in mainstream languages might take 10 times longer during the 1970s.
There weren't enough programmers to meet the demand. Along came 4GLs and their supposed promise of development without programmers. We know that didn't work out. But the idea of generating systems in 10 percent of the time appealed to many. If you needed 10 percent of the time, maybe you only needed 10 percent of the programmers.
The 4GL heyday was the '80s. With computers being relatively inexpensive and demand for systems growing, something had to fill the void. Some programmers caught the 4GL bug, but most didn't. There was still more demand than supply, so studying mainstream languages almost guaranteed a job.
Now even mainstream languages like COBOL and FORTRAN are out of vogue. COBOL was even declared extinct by one misinformed business podcast on NPR. The alternatives are, as one LinkedIn group member pointed out, often Microsoft's .NET or Oracle's Java. (Java wasn't considered a vendor's product until Oracle acquired it as part of its Sun pickup. These days Java is rarely discussed without mention of its owner, perhaps because the Oracle database is so ubiquitous in typical migration target environments.)
Migration away from a 4GL like PowerHouse -- to a complete revision with new front end, back end databases, reporting and middleware -- can be costly by one LinkedIn member's accounts. Krikor Gellekian, whose name surfaces frequently in the PowerHouse community, added that a company's competitive edge is the reward for the lengthy wade through the surf of 4GL departures.
"It is not simple, it takes time and is expensive, and the client should know that in advance," Gellekian wrote. "However, I always try to persuade my clients that IT modernization is not a single project; it is a process. And adopting it means staying competitive in their business."
Deskin approached the idea that 4GLs might be a concept as extinct as that podcast's summary of COBOL.
Does this mean that the idea of a 4GL is dead? Absolutely not. The concept of specifying what you want to do rather than how to do it is still a modern concept. In effect, object-oriented languages [like Java] are attempting to do the same thing -- except they are trying to be all things to all people and work at a very low level. However, it takes more than a language these days to be successful. It also requires a modern interface. Here's hoping.