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 call them legacy systems) comes from a clear need: except for very specific cases, COBOL and PL/I are just not the right languages for new developments in 2016 and beyond.
Which is why we offer a number of resources for new modules written in modern languages (C#, VB.NET, etc.) which interact gracefully with existing legacy components. Having a COBOL or PL/I past shouldn’t force you to build more 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 mainframe compiler behavior as accurately as possible, even when it drifts from the standard, even when it contradicts its own documentation.
In places, the behavior cannot be determined without extensive experimentation. PL/I and COBOL are complex languages. Their specifications leave a great deal of wiggle room for implementors who can take different approaches with different results while remaining within the limits of the published standard.
Things sometimes get more extreme than that. We purposely reproduce known PL/I compiler bugs to ensure that we get the same rounding errors in specific cases. We aren’t in the business of convincing our customers that our (different) COBOL and PL/I compilers are better than the ones they currently use. We’re in the business of ensuring that the behavior is the same, quirks, tolerances, limitations, variations and known bugs included.
Are there limits to our goal of reproducing mainframe compiler 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, which causes the ASCII version of what used to be an EBCDIC source file to become unreadable or arbitrarily truncated).
There are limits for sure, but we’re pushing them as far as we can.
We make legacy compilers.
If you aren’t convinced yet, here are 8 good reasons to skip a legacy migration and keep your mainframe.