4 ms·

> So what do we replace COBOL with? Why replace it at all? Why not build up GnuCOBOL, and evolve the needed IDEs, deployment infra, and mainframe functionality

> So what do we replace COBOL with? Why replace it at all? Why not build up GnuCOBOL, and evolve the needed IDEs, deployment infra, and mainframe functionality replacements around it, so we can continue to use old, functioning code in new ways? Insisting on rewriting the code is insistence on simply never completing the project at all.

skissane 7y ago
A lot of COBOL software is running on IBM mainframes under z/OS. In that case, it isn't just COBOL, it is all the middleware and OS components the COBOL interacts with – CICS, IMS, DB2, VSAM, JCL, DFSORT, etc, etc, etc. Duplicating all of that functionality is an infeasible task. Duplicating a big enough subset that you can successfully port a real world mainframe app is achievable, and a number of commercial offerings exist which do that – e.g. Oracle Tuxedo Application Runtimes for CICS/IMS/Batch, Tmaxsoft OpenFrame, UniKix, etc. However, building such a solution is a huge amount of work requiring a rare skillset, and I doubt the open source community has the ability/resources/motivation to replicate that work.
- Roboprog 7y ago
  I hear that. I worked at a place in the early 90s that had a product to port System/36 based RPG II code onto newer platforms. It kept 4 of us pretty busy, and RPG is just a small language doing flat files on a mini with a simple scripting language (OCL = operation control language) and job queue system. Later we took on the AS/400 version, but I left before that product went live. I can’t imagine how much IBM’s mainframe system has sprawled out over the last quarter of a century.
- michaelbrave 7y ago
  It would be interesting to see all the places that have this problem hire a team of open source people to tackle this with the intention of solving it for all instead of just for some. A collective solution contributing to the commons, I think it could work.

skissane 7y ago

A lot of COBOL software is running on IBM mainframes under z/OS. In that case, it isn't just COBOL, it is all the middleware and OS components the COBOL interacts with – CICS, IMS, DB2, VSAM, JCL, DFSORT, etc, etc, etc. Duplicating all of that functionality is an infeasible task. Duplicating a big enough subset that you can successfully port a real world mainframe app is achievable, and a number of commercial offerings exist which do that – e.g. Oracle Tuxedo Application Runtimes for CICS/IMS/Batch, Tmaxsoft OpenFrame, UniKix, etc. However, building such a solution is a huge amount of work requiring a rare skillset, and I doubt the open source community has the ability/resources/motivation to replicate that work.

Roboprog 7y ago
I hear that. I worked at a place in the early 90s that had a product to port System/36 based RPG II code onto newer platforms. It kept 4 of us pretty busy, and RPG is just a small language doing flat files on a mini with a simple scripting language (OCL = operation control language) and job queue system. Later we took on the AS/400 version, but I left before that product went live. I can’t imagine how much IBM’s mainframe system has sprawled out over the last quarter of a century.
michaelbrave 7y ago
It would be interesting to see all the places that have this problem hire a team of open source people to tackle this with the intention of solving it for all instead of just for some. A collective solution contributing to the commons, I think it could work.