6.6 million jobless claims.
-
My old skills are back in demand apparently. Most of these systems are still running COBOL.
“I am fond of pigs. Dogs look up to us. Cats look down on us. Pigs treat us as equals.” ~Winston S. Churchill
-
My old skills are back in demand apparently. Most of these systems are still running COBOL.
@Mik said in 6.6 million jobless claims.:
My old skills are back in demand apparently. Most of these systems are still running COBOL.
How long would it take to train a C (or name several other languages) programmer in COBOL? Maybe a couple hours, a day or two for the second string.
Assuming you don't have to get too deeply in BL and BLL cells.
-
Python's better.
-
@Mik No, but it does run big data and machine learning.
-
Read somewhere just yesterday that 1 in 3 households have someone who has lost his job or has his pay (or hours) cut.
-
I was the best COBOL programmer I ever knew. My code was clean, structured, efficient and stable. If it went down unexpectedly there were always sufficient breadcrumb trails consistently in the same places where one could find out the where the program was and what data it was looking at. If I detected something wrong and had to abend the program there was always an explicit report in the run logs that told you exactly what happened on what input record or DB call, why it was bad and if possible what to do to fix it and finish the run. Those things are pretty easy to do if you set up the structure right the first time. Everyone loved supporting my stuff because it was so easy.
-
@Mik said in 6.6 million jobless claims.:
My code was clean, structured, efficient and stable.
This might be a fun game:
Provide examples of COBOL code that is not “structured.”
It seems to me the COBOL language specification makes it virtually impossible for any compilable COBOL code to not be structured. From time to time I see C programmers deliberately write obfuscated free-flowing C one-liners that do brilliant things. That does not seem possible with COBOL.
-
That's really more of an assembly language thing, if you want to do really slick stuff, at least for older languages. But I would contend that if it's obfuscated it's not brilliant. Just obfuscated. I've seen a lot of that in C and other more recent languages.
The whole point of COBOL is an spoken-language-like readability, the ability of the poor sap who comes after you to understand what you did and why. And I saw a whole lot of poorly written unstructured code that compiled and ran just fine...until it didn't. You did not want to be the guy who got called at 3 am to figure it out. I always contended that programmers like that should be taken out back and shot so they didn't go to work somewhere else.
“I am fond of pigs. Dogs look up to us. Cats look down on us. Pigs treat us as equals.” ~Winston S. Churchill
-
I taught Basic COBOL, Advanced COBOL and Structured Techniques along with several other courses, in Kuwait, a long, long, long time ago.
Structured Techniques were a miracle of the early 70s endorsed by IBM. The best, all used Structured Techniques. It was certainly possible to not meet this standard.
-
I taught Basic COBOL, Advanced COBOL and Structured Techniques along with several other courses, in Kuwait, a long, long, long time ago.
Structured Techniques were a miracle of the early 70s endorsed by IBM. The best, all used Structured Techniques. It was certainly possible to not meet this standard.
-
Apparently there is no longer a shortage of COBOL programmers. IBM set up a site where they can register and be found easily. I registered yesterday afternoon and hundred more have done so since. Good thinking on IBM's part.
H/T to Big AL for alerting me to it.
-
https://www.dol.gov/ui/data.pdf
In the week ending April 18, the advance figure for seasonally adjusted initial claims was 4,427,000, a decrease of 810,000 from the previous week's revised level. The previous week's level was revised down by 8,000 from 5,245,000 to 5,237,000. The 4-week moving average was 5,786,500, an increase of 280,000 from the previous week's revised average. The previous week's average was revised down by 2,000 from 5,508,500 to 5,506,500.
-
That's really more of an assembly language thing, if you want to do really slick stuff, at least for older languages. But I would contend that if it's obfuscated it's not brilliant. Just obfuscated. I've seen a lot of that in C and other more recent languages.
The whole point of COBOL is an spoken-language-like readability, the ability of the poor sap who comes after you to understand what you did and why. And I saw a whole lot of poorly written unstructured code that compiled and ran just fine...until it didn't. You did not want to be the guy who got called at 3 am to figure it out. I always contended that programmers like that should be taken out back and shot so they didn't go to work somewhere else.
@Mik said:
You did not want to be the guy who got called at 3 am to figure it out.
Grrrr...... I WAS that guy for many years in my early career.
The C hotshots were the worst. Mofo's writing code that did 20 things in one line of code. With NO comments as to what it did.
More like magic in/magic out, trust me. -
Yep. And they think it is brilliant. YOU DON'T HAVE TO BE THAT EFFICIENT ANYMORE. Disk, processor speed and memory are plentiful and cheap.
Yeah, I used to have to write overlay code to use memory effectively on larger programs, but that was 35 years ago and it was on its way out then.
The thing I hated was lazy-ass programmers who would force an abend when something went wrong but DIDN'T TELL YOU WHAT WENT WRONG, WHAT RECORD or anything else that might help you figure it out without reading a dump. If I did it I gave as much info as I could right there in the SYSOUT including restart instructions either in the code or the JCL. You would have liked working with me.
By the way, that IBM site for COBOL programmers? Not one single response from a desparate state unemployment system - or any other hiring agency for that matter - has been received. The problem is not in the code, although requirements and calculations would have to be changed in COBOL. That should be easy. The problem is in the system architecture that is not scalable to the catastrophic event like this. That takes a whole lot more time.
