Migrations away from the HP 3000 mean leaving a fine-tuned COBOL behind. HP shaped COBOL II to include intrinsics which plug directly into the IMAGE database and the 3000's OS. Customers who move to another platform need to rewrite those intrinsic calls for a new COBOL. AcuCOBOL needs far less revision that other COBOLs, because it was designed in 2001-02 to incorporate most of those same 3000 specialties.
But if you're going to be doing any rewriting at all, why not aim for more than a new COBOL that acts like the old one? If a transfer to Java from COBOL is your desire, a software company called Veryant has a language that claims to speak both languages.
Java got a jolt of news this week while its bridegroom, Oracle, gathered the Oracle faithful at its annual Oracle World. James Gosling, considered the father of Java, reported that Java's NetBeans development environment and Glassfish, an open source application server, are more popular than ever. Gosling said this week that Glassfish, as free as any Linux distro, has been downloaded at the rate of a million copies a month.
Except that Oracle already has its own development environment. Plus an application server that it loves. There may be some overlap in that acquisition. But a million copies a month carries a lot of clout. It's things like Glassfish that make Java look attractive during a move away from COBOL. That's where Veryant's isCOBOL could take a role in the move away from COBOL. It all depends on what caliber of Java you get out of it.
Remember, we're talking about migrations that will require revisions of COBOL here. These sites are already committed to rewrites, somewhat automated but which require testing. When you've got the hood up, can you get all the way to Java? isCOBOL compiles COBOL code into Java. In the late 1990s, a time of great optimism for Java, the 3000 community not only had an interest in the language, but third party did its best to make the technology transfer a reality. Chuck Townsend of Synkronix pushed the Java stone up the 3000 hill, but not even his IBM experience could give PERCobol a place to rest in 3000 shops. And that product understood COBOL II's extensions, according to Townsend.
Alfredo Iglesias of Veryant would love to work with a 3000 site on that kind of adoption. Veryant's isCOBOL came to our attention when Speedware's Nick Fortin pointed it out after our article about the two migration COBOL choices. With isCOBOL there may be three, and Transoft has certified its Transoft U/SQL Adapters for use with the isCOBOL Application Platform Suite.
You'd be among the very first to choose this isCOBOL for a 3000 project. "We do not have any customers yet that have used isCOBOL to replace HP COBOL II," Iglesias said. "We would be glad to work with any interested in the future." Migration can offer such groundbreaking opportunity. Java may be worth the experimentation, considering those millions of adopters out there.
Iglesias admits that the COBOL II specialties will demand some replacement. "I must bring to your attention that isCOBOL does not offer any compatibility to the HP 3000 extensions to the COBOL standard found in HP COBOL II. That means that they will have to be removed by the customer or a migration company in order for the code to compile and execute with isCOBOL."
isCOBOL was also on the radar screen of our author of the "Deciding Between COBOLs for Migration" article. Mike Howard mentioned it in passing at first, calling it no major player. It seems the adoption rate to date in the 3000 world confirms his view. Howard has his own assessment of isCOBOL's utility as well.
It is a COBOL that has no COBOL compiler. And yet the development process is to
1. Write the COBOL source code
2. Compile it to produce an object
3. Run the compiled object
And this is what the developer sees when he programs in isCOBOL. But in fact, the compile step actually has two steps in it. 1. Convert the COBOL source to Java source; 2. Compile the Java source.
So the actual process is
1. Code the program in COBOL
2. Convert the COBOL source to Java source
3. Compile the Java source
4. Run the Java object code
This process clearly demonstrates one additional item: how accurately COBOL can be converted to Java. For this process to work, the converter must be 100 percent at all times.
You can actually stop the "compiler" after the COBOL to Java conversion step and get the converted Java code. Unfortunately, it isn't much use, because the conversion was simply done for the Java compilation to take place — and the actual Java code is horrible. A better application code converter would be written to convert the COBOL to Java to produce code so that is good, maintainable Java.