Reality check

For the avid reader in search of irony, product descriptions on 21st century websites can be an infinite source of inspiration. They are filled with pedantic superlatives, which make no sense whatsoever when taken literally.

  • “Revolutionary”. Condoned by Marx and Proudhon perhaps?
  • “Ground-breaking”. Delivered by the Hulk, for sure.
  • “Widely acclaimed’.  You know, like the Beatles or the Rolling Stones, but then, truly popular.
  • “State-of-the-art”. Compared to what? Says who?
  • “Industry standard’. You know the drill, big pond, small pond. It is just a matter of reducing the “industry” to something small enough.
  • Even “Patent pending” should be taken with a grain of salt, given how hard it is to protect IT-related IP nowadays.



I should stop this sarcastic enumeration right here, as I know for a fact that our own website is not immune from such liberal uses of the English language.

But at least, in the business of Legacy Modernization – and definitely in the PACBASE migration market – there is one tangible thing people brag about on websites, one thing one can count on, one thing one can see, almost touch.

It is automation.

In a previous post, I stressed the importance of automation – and more specifically, in our case, the benefits of having a truly 100% automated process. Nobody questions its relevance to legacy modernization, a line of business which deals with large volumes of code and data.

All legacy modernization products and services are advertised as highly automated. But unlike the other superlatives listed above, you don’t have to take anyone’s word for it. Automation comes in different flavors as well as different degrees. And while talk is cheap, whether a solution is indeed adequately automated can be demonstrated. The same goes for its robustness when facing new inputs. Or flexibility when tweaking its output.

And you, as a concerned party, should demand such a demonstration. Any vendor with a straight face would welcome the opportunity to show how great, automated, robust and flexible their super-duper solution is.

But if one fails this very simple test, if he or she will not let you see how automated, robust and flexible the solution is – with a lame excuse of protecting their intellectual property or anything along the same lines – you can consider their claim to greatness as a joke.

A revolutionary, ground-breaking, widely acclaimed, state-of-the-art, industry standard joke.


Posted in Uncategorized | Leave a comment

COBOL or Java ?

Should one go to COBOL or to Java/C# ?

On the face of things, this is a very odd question to ask.

As if these two/three languages (I write two/three because for most of the practical concerns we’ll be looking at, Java and C# are fairly equivalent) were the only choices in town. As if they could really be compared (they can, but only to a degree). As if this question controls everything (it obviously doesn’t).

But when it comes to migration projects, whether they deal with PACBASE or not, it becomes an amazingly common question, fueled by a wealth of conflicting motives and misunderstandings. This post is an attempt at providing the most comprehensive answer possible to this question, despite its intrisic oddity and relative irrelevance.



1 – Long term viability

When comparing languages, critical mass and long term availability are crucial.

At least, for COBOL, it is easy.

In short, COBOL is here to stay. Its disappearance has been announced every so many years, and proven wrong over and over again. For better or for worse, the world will be running COBOL for decades to come. There are COBOL compilers for all platforms, with different technical characteristics, to care for virtually all situations. Whether one likes the language or not (more on this below in this post), it is now clear that COBOL will not disappear anytime soon.

Java is much more recent, but has gained enough momentum to build trust in its availability for the foreseeable future. However, even though Java as a language has reached critical mass and should therefore be considered a safe bet by now, the scaffoldings of frameworks one uses to develop Java systems are more of a concern. Persistence, XML parsing, web page creation from templates, workflow, etc. are some of the issues addressed by such third party frameworks, most of which are available with an open source license. These frameworks evolve with up to three releases every year, and are maintained by independent teams with no central authority to ensure consistency and compatibility. Java projects end up spending a serious amount of time and effort just keeping up with the (sometimes incompatible) evolutions of the frameworks they depend on.

In short, these frameworks have turned into liabilities in their own right, that can seriously jeopardize the longer term perspectives on a Java system.

C# is even more recent. It is supported by a major player in the market – namely, Microsoft – which maintains most of the peripheral frameworks and guarantees they remain in sync at all times. Whether one likes this concept of an omnipotent authority or not, experience shows clearly that it does deliver serious benefits in reliability and consistency (See the disclaimer at the end of this post).



2 – Performance

From a performance perspective, both languages should be more or less equivalent.

COBOL is a bare bone language that can be compiled effectively, even though most COBOL applications are I/O bound by full orders of magnitude. This focus on I/O as the source of most if not all performance issues shows in the practicality of even far less efficient compilation schemes (to intermediate languages or virtual machines).

And even though Java (and C#) goes through a virtual machine for execution, as a language, it is perfectly adequate for high-performance computing. The only caveat is that one must use caution when designing the system’s architecture. Far more than the language itself, bloated architectures with scaffolding of frameworks and dynamic behaviors (excessive allocations, reliance on the reflexive API, systematic serialization and deserialization of objects, etc.) must be blamed for the numerous Java/C# systems that fail to deliver adequate performance levels.

On the other hand, well-designed systems can rely on the serious improvements that have been put in the just-in-time compilation facilities, together with the same bias towards I/O bound systems as described above for COBOL, to turn Java and C# into sound choices performance-wise.birds_2

 3 – Technical excellence

(In a normal world, this question would come first, but obviously, the world we live in has given up any pretense at normality ages ago)

As languages go, COBOL is way older than Java, but there is no such thing as the proof of time in IT. And old language is not ‘proven’. It is just old.

And from a purely technical level, Java as well as C# are way superior to COBOL. They are both more orthogonal, provide much better abstractions (especially compared with COBOL which barely provides any abstraction at all), a cleaner syntax, well-defined semantics and a wealth of useful facilities such as generic classes and an automatic garbage collector. The only downside has been a tendency to over-engineer applications, developing generic frameworks rather than business logic in many cases.

Admittedly, it is unfair to blame languages for the way some people so blatantly misuse them.

4 – As targets for migrations

This question it at least a simple one: if the system to migrate runs on a mainframe or mainframe-like platform, COBOL is a must, as it is the only widely available language that mimics the mainframe data types accurately on all platforms, including the most recent ones.

On the other hand, if a mainframe system it to be migrated to Java or C#, one must choose from two equally unappealing curses:

  • Use native Java/C# data types, and accept possible differences of behavior when truncating or rounding intermediate numeric values
  • Revert to complex class libraries to mimic the original Mainframe behavior accurately, with a serious impact on performance and even more importantly, on the structure and the maintainability of the resulting system.

If there is no such constraint regarding accuracy and data types physical representation, Java or C# usually are a better choice, as their abstraction mechanisms allow for a much smoother migration, and a technically better and more structured system to maintain.


5 – What about PACBASE then ?

Given what is written above, the choice should be simple.

PACBASE is a mainframe system. It deals with mainframe concepts and mainframe data types. Migrating it to COBOL has its challenges, but at least, one can count on numerical accuracy to deliver absolute functional equivalence with minimal cost.

Even so, one can understand the appeal of targeting Java or C# instead, because of their vastly superior technical properties and because of the clear market push in this direction.

But in the real world, as explained above, migrating to Java or C# will mean a high risk of functional difference, or an entropic transformation that will jeopardize further maintenance efforts.

Pick your poison.

6 – What about converting COBOL to Java or C# then ?

I know that there are quite a few companies that claim to have solutions that convert COBOL to maintainable Java or C#.

I know that they all claim to produce more readable code than their competitors.

I know that they also claim that their users love maintaining their migrated code.

But I can’t help having serious doubt about this. Producing Java or C# code that behaves exactly as the original COBOL code is a lot of work, but it definitely can be done. But I can’t imagine the resulting code look, feel, sound, taste or smell like anything a Java or C# programmer would have written, or would be willing to maintain. And I have never met any of these developers super-happy to maintain Java or C# code that used to be COBOL business logic.


The purpose of this post is not to compare Java and C# on their respective merits. Even so, it is fair to acknowledge that even if the author has extensive and relevant experience with Java, he (and more generally, the company he represents) also has a long standing relationship with Micosoft as a company, and one could reasonably question his objectivity when comparing languages when Java and C# are involved.


Does this answer the original question ? Probably not entirely, but I still hope it provides useful hints.


What do you think ? As always, comments are welcome.


Posted in COBOL | Leave a comment