Enforcing quality in a PACBASE migration solution

Raincode’s solution to migrate PACBASE systems has been tested more than any other in the field, both in terms of number of sites it has been applied to, and in the total volume of code it has processed.

pacbase toolset

Still, it is not carved in stone. The migration toolset still evolves, to recognize COBOL quirks (some dare call them extensions) we never encountered before, or to support new features, new patterns, new transformations required by our customers.

But then comes the question, how do we validate the changes? How do we ensure that the migrated code still works as the original one, that functional equivalence remains guaranteed release after release? The migration machinery is a sophisticated piece of software, and it requires more than superficial testing here and there. We would not want to go to our prospects and customers, telling them that we are going to change their source code if we are not entirely confident that the functional equivalence is guaranteed.

Our quality control procedures aim at providing us with this confidence. It is based on a common strategy when it comes to software engineering, namely divide and conquer.

But before we proceed, we must first explain more about how the migration toolset is structured.

It is divided in two main components:

  • The Raincode engine is our COBOL parsing and analysis facility. It deals with everything that has to do with recognizing COBOL programs, and supports transformations and queries on these programs. It recognizes numerous COBOL dialects, including SQL, CICS and DL/I extensions. It is a generic tool we use for a number of purposes, out of which PACBASE migration is just an example.
  • On top of the Raincode engine, the COBOL restructuring facility actually transforms the code to make it more maintainable, more readable etc.

This clear separation in two layers is the cornerstone of our testing strategy, based on a simple premise: we never change both components simultaneously. We always change one of the components, and test the result extensively before considering changing the other.

How does this work in practice?

We keep a large portfolio made of several thousands of PACBASE-generated COBOL programs, together with the resulting code after restructuring. When changing only the engine, since the logic of the restructuring is not altered, we can ensure that the new engine produces the same restructured COBOL program logic to the character level. Failing that, the new version of the Raincode engine has an obvious change of behaviour.

When the restructuring facility evolves, we restructure a number of thoroughly crafted test programs that exercise the various transformations supported by the migration facility, run them and ensure that their execution remains consistent with the previous release of the restructuring facility.

pacbase structure


Differences in the resulting COBOL programs are also inspected manually, to ensure that they are in line with the changes that have just been made to the restructuring facility.

This layered approach to regression testing has yielded excellent results. Differences of behaviour are detected as early as possible in the process, rather than relying on customer testing to ensure that the restructured programs do indeed behave as they did before.

After all, this is a volume business, and requiring extensive ad hoc testing would defeat the purpose altogether.

As always, comments are very welcome!

That’s all for now…


Posted in COBOL, Uncategorized | Leave a comment

Any Loch Ness monster around?

Some species have been talked about for ages even though very few people can actually claim to have seen a living or even dead specimen. Even then, the evidence is sketchy at best. More often than not, the pictures are blurred and the footage unconvincing.


It goes for Nessie, a.k.a. the Loch Ness monster.

And for the Yeti, sometimes referred to as the Abominable Snowman.

And Bigfoot.

And the list of such colorful cryptids goes on and on.


But when hearing some of the players in our industry talk about prestigious - even though always unnamed – customers, I feel about them just as I feel about Nessie or Bigfoot. I hear stories about these mythical customers over and over again, and still, I can’t help doubt their existence. Because my rational self does not come to terms with the story.


More specifically, it has always been my deep conviction that translating COBOL to Java or C# was technically feasible, but that the result would be so unlike what a Java or a C# programmer would have written in the first place, that it would be very hard to maintain unless one has extensive COBOL expertise to start with (which admittedly defeats the purpose altogether) The languages are just too different, and the concepts do not map gracefully from one to the other.


Perhaps even more importantly, no self-respecting Java or C# programmer would ever want to maintain this code, and given the current state of the job market, they can afford to be choosy. And they are.

But who am I to say? Sales people, with the unlimited confidence that comes with the trade, tell me over and over again that they have numerous customers that are very happy with the Java or C# code produced from COBOL.

But their confidence stops when asked for an actual reference, the ability to talk to an actual person actually maintaining this generated code.

So, anyone out there? Any hardcore Java or C# programmer, responsible for the maintenance of code produced from a COBOL translator, enjoying their job? How much fun can Java be, without inheritance, polymorphism, almost without modularity?


Or is it just me asking for Bigfoot to step out of line?

A few hundred views and some feedback down the road, please let me clarify: I don’t doubt that some companies have converted their COBOL code to Java and C#. My point is to find out how programmers experience the task of maintaining this generated code.

And even more so when these programmers are Java or C# programmers, with no prior knowledge of COBOL and its idiosyncrasies.


Posted in COBOL | Leave a comment