My company has plenty of Cobol. While I am not on their part of IT, I used to work together with them for integration. I left with very mixed feelings.
Some bad sidess
* The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past.
* IT practices are old. They havent yet embraced lower case. I trieds to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane.
* IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine wih auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod.
* The database consists of 12 files (we would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join.
* Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications:
* The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up.
* There is no sexism here. The male/female mix is approx 50/50.
* These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at the new applications just to keep them limping along.
* There is no hubris here. No Architect, no Consultants, no expensive management ideas. A recent migration from cobol to oracle OSB+gui actually required us to add 1/3 of personnel to account for the slowdown caused by people . Yeah we all saw it comming, those wo reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argumant for or against Cobol
Out of interest what do you see as the benefits of UTF-8 in source files?
It has caused me problems a couple of times, and I don't ever think I have needed anything outside of ASCII for source code, with the exception of entering some foreign names in to a database via a script.
I want UTF-8 in the database, not the source files. This is Europe, user data has accents aplenty.
This once ran on a real mainframe, but was then migrated. So it has the common subset of win1252 and some ebcdic variant, minus lowercase. No euro sign on the financial report anywhere ;-)
Oh dear, that post suffered a lot from lack of time and keyboard. Sorry. Hereunder a reformat/spelling/missing sentence fix. If some mod sees this: Feel free to replace the original with this:
---
My company has plenty of Cobol. While I am not on their part of IT, I used to work together with them for integration. I left with very mixed feelings.
Some bad sides:
-The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past.
-IT practices are old. They haven't yet embraced lower case. I tried to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane.
- IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine with auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod.
- The database consists of 12 files (SQL would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join.
- Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications:
- The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up.
- There is no sexism here. The male/female mix is approx 50/50.
- These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at some of the new applications just to keep them limping along.
- There is no hubris here. No Architect, no Consultants, no expensive management ideas. Compare that with a recent migration from cobol to oracle OSB+gui: It actually required us to add 1/3 of personnel to account for the slowdown caused by people having to fight the new-and-shiny application . Yeah we all saw it coming, those who reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argument for or against Cobol
Some bad sidess * The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past. * IT practices are old. They havent yet embraced lower case. I trieds to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane. * IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine wih auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod. * The database consists of 12 files (we would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join. * Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications: * The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up. * There is no sexism here. The male/female mix is approx 50/50. * These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at the new applications just to keep them limping along. * There is no hubris here. No Architect, no Consultants, no expensive management ideas. A recent migration from cobol to oracle OSB+gui actually required us to add 1/3 of personnel to account for the slowdown caused by people . Yeah we all saw it comming, those wo reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argumant for or against Cobol