6.6 million jobless claims.
-
"My pronouns are FA/FO." - Mik, 2024
-
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 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.
-
@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.
-
@Mik said in 6.6 million jobless claims.:
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.
Sounds like I would have.
Wrote cobol on a IBM 370 for years. Then an IBM 8100 system. Some of that code ran for over 15 years before they retired the system.
We have the freedom to choose our actions, but we do not get to choose our consequences.
Yes, there are two paths you can go by, but in the long run, there's still time to change the road you're on. -
@Improviso said in 6.6 million jobless claims.> Wrote cobol on a IBM 370 for years. Then an IBM 8100 system. Some of that code ran for over 15 years before they retired the system.
I have a system that is still running at a dental lab that I wrote in 1985. He finally stopped upgrading the underlying runtime system about 5 years ago. He said he was retiring. He is still working and I did some enhancements for him to start a new process just last December.
-
IT systems are tools. Nothing more. If the tool does what you need done and is on a maintainable platform it's good.
I have seen a lot of businesses that worked for technology rather than technology working for them. You see a LOT of that in healthcare. That's the wrong way to go.
