We present our COBOL and PL/I solutions as legacy compilers, based on the premise that they will be used to compile existing code much more than newly written code.
This focus on existing systems (some may call them legacy) comes from a clear need: except for very specific cases, COBOL and PL/I are just not the right languages for new developments in 2015 and beyond.
This is why we offer a number of means for newly written modules in modern languages (C#, VB.NET, etc.) to interact gracefully with the existing legacy components. Having a COBOL or PL/I past should not force you into building ever more of COBOL and PL/I code forever. But the existing code must be dealt with, and that’s where legacy compilers come into the picture. They aim at reproducing the mainframe compilers’ behavior as accurately as possible, even when they drift from the standard, even when they contradict their own documentation.
In places, this behavior cannot be determined without extensive experiments. PL/I and COBOL are complex languages, and their specifications leave quite some wiggle room for implementors, who can take different approaches with different results while remaining within the limits of the published standard.
It sometimes gets more extreme than that. We knowingly reproduce known bugs of the PL/I compiler, to ensure that we get the same rounding errors in specific cases. We are not in the business of convincing our customers that our (different) COBOL and PL/I compilers are better than the one they currently use. We are in the business of ensuring that the behavior is the same, quirks, tolerances, limitations, variations and known bugs included.
Are there limits to this ambition to reproduce the mainframe compilers’ behavior? Of course there are. Some tolerances are so specific to the mainframe as a platform that supporting them on Windows is close to impossible (like embedding control characters in literal strings, that causes the ASCII version of what used to be an EBCDIC source file to become unreadable or truncated arbitrarily).
There are limits for sure, but we are pushing them as far as we can.
We make legacy compilers.
If you are not yet convinced, here are 8 good reasons to skip a legacy migration and keep your mainframe: 8 good reasons
Raincode Stack is a mainframe migration solution to move your legacy code off the mainframe, and integrate it in a full .NET infrastructure.
- Save money by running legacy applications on a much more affordable and more flexible platform
- Access DB2 on the mainframe or move your data to SQL Server with no change to your programs
- Free COBOL compiler
- Integrate your existing legacy components in new code written in VB.NET or C#