4 ms·
You are absolutely right, that's the nuance that's often missed in these discussions. The COBOL applications in question grew organically over decades to encomp
by marktangotango 10y ago
You are absolutely right, that's the nuance that's often missed in these discussions. The COBOL applications in question grew organically over decades to encompass business processes for entire industries. There was never a single design document or even goal.
The other thing is how these systems were architected. They were mostly all green screen apps that build data files that were then fed into extensive (complex, large) nightly batch processes. For example today when you do a transfer between bank accounts, you may expect the transfer to be immediate. most often it's shown in a pending status until after the next nightly process. This is why.
- marktangotango 10y agoEdit: further, the problem with transpiling is that these systems are still under active development. For example, banking systems have to be updated annually for changes in regulations and tax laws. If you translated all you COBOL to Java (which results in truly inscrutable code (cobol has unusual control flow constructs, even besides go to)). Then as an organization you're face with either modifying the Java code (this is very, very, very bad), or regenerating from COBOL periodically, which kind of defeats the purpose.
- collyw 10y agoI always assumed it was so the banks could skim off the interest generated for another night.
- woah 10y agoAre there any good resources on the architecture of these systems? It sounds very different from the application and web programming that I know and it would be interesting to learn about it.