Search

October 14, 2009

Leaving COBOL? isCOBOL offers Java path

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 code2. Compile it to produce an object3. 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 COBOL2. Convert the COBOL source to Java source3. Compile the Java source4. 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.

Comments

Leaving COBOL? isCOBOL offers Java path

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.

Comments

Thank you for mentioning isCOBOL and Veryant in this article.

Although many of Veryant’s customers use isCOBOL as the perfect bridge to leave COBOL programming in favor of Java programming, the tool-set is currently designed for those customers that would like to continue to develop, maintain, debug in the COBOL language and deploy in the Java Runtime Environment (note I did not say use the Java programming language). A clear example of how isCOBOL facilitates the integration of COBOL and Java applications is Donatos Pizza (http://tinyurl.com/yk7qbmh). Donatos is leaving COBOL behind and rewriting its core business applications in Java. The facilities that isCOBOL provides make that transition more affordable to the enterprise and less dramatic to the end-users.

On the other hand, the majority of Veryant customers find the idea of leveraging their COBOL and application expertise while deploying pure Java applications very attractive. They do not have to learn the Java programming language, Java scripting, Ajax, Web programming, etc. They are able to play in the Java sandbox using the COBOL programming language (including OO COBOL), a standards base COBOL compiler, a graphical, portable debugger with remote debugging capabilities and a COBOL friendly IDE based on the Eclipse platform.

Yes, the intermediate Java code generated by the isCOBOL compiler (which as correctly noted, in the first step acts as a COBOL to Java translator) has a heavy COBOL ‘accent’. By default isCOBOL does not even preserve the generated Java source code on disk. If the developer wants to see it, a special compiler option needs to be set. Currently, it is neither the focus of Veryant nor the objective of isCOBOL to generate maintainable -- from a Java programmer point of view -- Java source code. There are plenty of vendors in that space. In fact, there is a question about how accurately COBOL code can be converted to maintainable Java code. The isCOBOL COBOL to Java translation step is 100% accurate all of the time. However, if someone who knows the COBOL application, takes the time to study the Java libraries that isCOBOL provides for the runtime environment, it is possible to take the generated Java code, clean it from the ‘accent’ and continue development in the Java programming language.

I would like to repeat the invitation extended above for any of the readers of this publication to try isCOBOL as an option for their HPe3K COBOL II applications. You will find that isCOBOL is true to its COBOL nature.

I'd like to suggest an alternative that has the COBOL II issues worked out, is faster than isCOBOL, and is the source from which isCOBOL was copied: LegacyJ.

As the newly appointed CEO for LegacyJ, I will be relaunching the company in the next few weeks, building on our 12-year history of designing the fastest modernization solutions in the industry.

Before Java was recognized as a standard, our architects had selected it as the Object-Oriented Standard of choice, and invested heavily in providing 16 different COBOL flavors, as well as utilizing the industry-standard Eclipse technology and offering a CICS replacement product.

Among those different variations of COBOL, we worked with both HP's COBOL and COBOL II, though the resultant database activity will most certainly move to one of the SQL standard database engines available from those little companies like Oracle, Microsoft.

We focus on providing rapid translation of your COBOL assets, freeing up your budgets to consider future choices after quickly moving to more affordable platforms.

If you'd like to work with the Original COBOL-to-Java translation company and get your HP COBOL II handled in a hurry, feel free to contact me anytime: