The Beauty of the COBOL Programming Language
devops.com
devops.com
I use to code Cobol on VMS as was required at a job. But the application was more of a systems application and had to be redundant.
So I would code using VMS system services so it did not look like Cobol. Did have to figure out how to create data structures in Cobol needed with the system services. So a 32 bit word for example, descriptor, reference.
I did the redundancy by taking out a cluster lock on the cluster with a wait ($ENQ_W). Then it was part of the startup on all the nodes in the cluster but only one got the lock and the others were stuck in a wait state. So simple.
If the Vax crashed or rebooted for maintenance another node would get the lock and run properly.
The devices the application interacted with were attached to terminal servers so all the nodes in the Vax cluster could see the terminal server.
What was ridiculous is that it should have been written in assembler or C instead of Cobol. Just because it was Cobol no one else was going to be able to maintain just because it was Cobol.
What normal Cobol programmer is dealing with system level things? I basically did everything using library and system services. So there was almost no lines of code that look like any normal Cobol.
Wonder if that code is still running?
It has a lot of nice short-cuts and built-in "libraries" for that domain. You can get similar libraries/API's for say Java, but they'd be inconsistent for each shop because they are not built into Java. COBOL guarantees that a consistent set of business-oriented operations will be available, reducing the cross-shop learning curve and errors because they are time-tested.
Both FORTRAN and COBOL survive by NOT trying to be general-purpose languages, instead making sure they serve their domain well and consistently. I'm afraid some languages such as C# try too hard to be everything to everybody: a systems language, an application language, a scientific language, etc.
https://www.dbcsoftware.com/index.html
It was very, very similar to COBOL, and was the closest I ever got to using COBOL.
My work there was involved with developing an internally used piece of software written in Visual Basic, so I wasn't involved in the main product, but at one point they wanted to run everyone who did any kind of programming thru a set of training sessions on the language.
I found that it was just -barely- possible to build a version of Breakout using the language; it wasn't great, but it did work.
Later I used some of the extended functionality that was built into the language for network access to build a simple HTTP server; nothing fancy of course, just something to see if it could be done.
I am not sure how I feel about the language - or about COBOL in general, beyond it's legacy/historical value...
Sometimes I think about what it must be like to go back to COBOL today. There's probably money in it-- there can't be too many developers left! The environment is probably stable.... You'd just have to learn to navigate all the programs in your workspace (and that can be no small task.)
I think I'll pass. I like it better in the modern world.
And CICS. But even worse than those two was a 1980s IBM business language called CSP ( Cross-System Product ). If you can imagine COBOL with all its limited expressiveness removed. I used to be elated when I opened a member and found it to be COBOL or C rather than CSP.
-- Edsger W. Dijkstra