Sparks powers down 3000, opens Windows
3000's cells seem simpler to retrained vets

COBOL You Know, vs. COBOL You Don't

DevilMigrations are in play all over the world between HP 3000 systems and Linux environments. Nobody seems to be reporting very many at the moment, but the Little OpenSource Environment That Could is a regular replacement when a 3000's futures go a-wanting.

All well and good, in many instances. Hiring Linux help is never an issue, but the know-how and replacements for the rest of the 3000 ecosystem are more complex. For example, a customer who's been using scripts in their HP 3000 ops needs a replacement. MB Foster's created one for Windows in UDAXpress, which the company has been demonstrating this year.

COBOL, however, becomes an element that might be integrated tighter than you'd imagine in a 3000 program suite. For example, one recent migration project we heard about included a 4GL-to-4GL Powerhouse.

The decision was made to move the application largely as is, to Powerhouse on Linux, and to Oracle. Porting Powerhouse is not too onerous; apart from a few limitations and differences, you just port the code across and recompile it with Oracle as the target database, and off you go.

There was one catch, and it might become one in a migration near you. Some core calculations can be enshrined in a set of COBOL routines. Maybe they were too complex to write in Powerhouse. So at this point, a Linux-bound customer is looking seriously for a COBOL replacement. They can reach for commercial products which run on Linux, or look to the open source community at OpenCOBOL. Some such migrations are moving from a COBOL they know, to a COBOL they don't. The commercial COBOLs have support staff and training. Open, not so much, unless a third party gets involved.

A seasoned migration engineer on an adept team says that OpenCOBOL and Linux had to be blended without help from the OpenCOBOL online forum. This typical sort of knowledge repository for open source "seems to have been read-only, for newcomers at least, ever since last January." When nobody's posting to a help forum, any questions had better be the same as they ones already answered.

OpenCOBOL is open source code that has a commercial counterpart, just like Red Hat commercialized Linux. You can download COBOL-IT to get started with this blend. Freshe Legacy, the former Speedware, was drawing attention to COBOL-IT during 2011.

But 64-bit OpenCOBOL, running on RedHat Enterprise Linux 5.3, eventually assumed the core calcuations which the 3000's COBOL once did. The calculations were in surround code. Sometimes Powerhouse is an application's surround code, but sometimes it's COBOL.

The 3000's COBOL can be compiled on OpenCOBOL 1.1. (Actually running it against a database like Oracle is another matter. There's the calls to HP's intrinsics, plus the exchange of data with IMAGE, to rewrite into Linux intrinsics and Oracle calls.) But there's also a thorough pre-requisite to simplifying the COBOL from the 3000. 

1.Remove all the code relating to long-dead product ranges that would never be purchased again. Good policy in all migration cases. Your migrations should well begin by studying all the programs that need not be migrated, because the end-users don't use them anymore.

2. Make the code almost completely ANSI-compliant, using COBOL's functions for date calculations instead of any home-grown ones. The 3000 COBOL's ENTRY points are already simple enough. They might be a lot of trouble to code around, and OpenCOBOL supports them anyway.

The blend of OpenCOBOL and Powerhouse works very differently than the 3000's, which requires this bit of technical refitting: keeping the OpenCOBOL on 64-bit. 

A 32-bit OpenCOBOL is needed if Powerhouse, itself 32-bit, is to call COBOL subroutines. So you do a COBOL wrapper for the subroutine, which makes it possible for Powerhouse to RUN it as a separate executable -- and 64-bit OpenCOBOL will be okay, now passing and returning the variables in a file.

If all of the above sounds like the effort of home-grown application development from the 1980s and 1990s -- workarounds galore -- of course it is. These migrations are moving applications that were constructed during that era. It might also serve as a leg in the journey moving the COBOL you know to a COBOL you don't on Linux. Especially if that COBOL is open sourced. The reputation that Linux bears -- being a hands-on environment -- survives, especially powered by reports like this.

Database: vendor-supported. Environment: same. COBOL: Perhaps best chosen as a commercial tool with support. And be vigilant about the run-time costs, which never existed under HP's COBOL II. That was the final COBOL, by the way, that HP ever created, using a well-honed languages lab. By the time COBOL became important to Unix or Linux, HP had left the compiler business to third-party experts.