A colleague of mine noticed some strange behaviours in his programs. It was later discovered that this is due to SyncSort not conducting a stable sort. Stable sort means that the sequence of elements in input is not changed if there is no strict need to change them.
Unfortunately, the documentation of SyncSort apparently does not contain a hint on that.
Recently I learned the hard way that IBM Enterprise COBOL compiler for z/OS (mainframe) cannot generate 8-byte long POINTER variables, but only 4-byte pointers. This means, you cannot use more than 2GB in COBOL on a mainframe. I.e., you cannot make use of AMODE=64 with COBOL on the mainframe. You can run in AMODE=64, but you cannot exploit it. By the way, we have the year 2013. So, no big-data on mainframe with COBOL.
IBM Assembler and C/C++ can fully exploit AMODE=64, i.e., can use 8-byte long pointers.
- Enterprise COBOL for z/OS, Version 4.2.0: No AMODE=64
- Enterprise COBOL for z/OS, Version 5.2.0: No AMODE=64
- Enterprise COBOL for z/OS, Version 6.1.0: No AMODE=64
- Enterprise COBOL for z/OS, Version 6.2.0: No AMODE=64
- Enterprise COBOL for z/OS, Version 6.3.0: Hurray, now finally AMODE=64 support since September 2019
For a list of versions see IBM Enterprise COBOL for z/OS.
Mainframe rehosting is about replacing the whole mainframe with one or multiple Linux boxes, or at times, move portions of the application landscape from the mainframe to Linux. Thereby you basically keep many of the hitherto used development- and runtime-environment, like COBOL, DB2, IMS, CICS, etc. The goal in mainframe rehosting is to dramatically reduce costs. If you are dauntless you can also move to Windows.
The point is that you do not rewrite your applications but rather just move your applications, i.e., you recompile your applications on new hardware. So all accumulated experiences with the software is fully preserved.
In 2008 I started writing a paper on mainframe rehosting, see Mainframe Rehosting.
During 2008-2011 the paper has been revised somewhat. The paper is in German.