The judge overseeing Jonathan Langley's age discrimination lawsuit against IBM has dismissed the case, which was scheduled to go to trial later this year.
The court order [PDF] closing the case, signed on Wednesday by Judge David Ezra in the Texan Western District Court, cites a stipulation of dismissal by Langley and IBM. That suggests the two parties have agreed to settle confidentially out of court.
The Register asked IBM to confirm that the case has been settled. We've not heard back. Langley's attorneys could not be reached for comment.
In 2018, Langley sued IBM, claiming age discrimination. He was laid off at the age of 60 after 24 years at the biz. The lawsuit was filed several months after a report from ProPublica and Mother Jones claimed that IBM had embarked on a company-wide campaign to dismiss older workers, a project said to be called Operation Baccarat.
In January, Andrew Austin, the federal magistrate judge overseeing the pre-trial phase of the litigation recommended that case be allowed to go to trial. Then in February, IBM's motion to dismiss the case was rejected. Last week, Judge Ezra set the trial date for Monday, October 19, 2020.
But with the dismissal of the case, there will be no trial.
Numerous other lawsuits are pending; by some estimates 13,000 people were let go under similar circumstances.
[Disclaimer: I was an employee of IBM back in the last century. --martyb]
(Score: 0) by Anonymous Coward on Thursday April 16 2020, @06:11AM (6 children)
(Score: 0) by Anonymous Coward on Thursday April 16 2020, @06:35AM (5 children)
How challenging is it to learn COBOL, and how useful would it be when compared with today's popular languages?
(Score: 4, Informative) by Anonymous Coward on Thursday April 16 2020, @09:17AM (4 children)
COBOL is simultaneously easy, hard, very hard, and insanely hard.
It is easy because, when done right, it is very verbose and reads in an almost sentence-like structure and the structure of everything is explicit.
It is hard because being explicit in that way requires you to think in a way that many programmers aren't used to thinking anymore because the data structure comes first, then the relationships, then the algorithm, then the code. It is also hard because the sentence-like structure results in a huge list of global keywords and statement-specific keywords.
It is very hard because those keywords, among other things, are implementation-specific, so you have to know what environment and compiler, and sometimes specific compiler flags, you are using. It is also very hard because, for job security purposes, it is not uncommon for programmers to obfuscate code by combining statements, using bad variable names, removing the optional words, and explicitly relying on implementation-specific behavior. Oh, and there is usually no tests, comments, or documentation, so the above is all you get.
It is also insanely hard because COBOL is only 1/3 of the battle. You also need to have understanding of your scripting language, usually JCL, used to run your batches. And you need to understand your processing flow between the batch jobs, your infrastructure, and your entry/exit points.
All that said, when you see a job listing for COBOL, they are actually asking for much more than a simple programmer. It is part of the reason why they are paid a ton of money when they are good and experienced. It is also why IBM and others are trying so hard to get them to be cheaper. It is also a hard industry to get into as many current programmers are coasting, the groups hiring have usually been bitten by bad ones in the past due to going too inexperienced or cheap, or they are "trying" to get away from it.
At a minimum, I think it is an important language to be familiar with because it, like Prolog, Haskell, Python, R, and C, requires you to think in new ways, be disciplined, and stretch yourself. Plus, you can use the knowledge you learned elsewhere in other languages. Plus, if you end up liking it, you can put projects on Github/bitbucket/Gitea/etc. and one of the places may find you. Networking and recruitment is how many (most?) jobs get filled nowadays. Well that and the new accelerator/mentorship thing IBM announced to fill the urgent gap.
If I were you, I'd probably look at the language. Fill some time, learn something new, maybe get a programming job with actual job security. Worst case, it just pads the resume and looks impressive to HR.
(Score: 0) by Anonymous Coward on Thursday April 16 2020, @10:11AM
Thank you for taking the time to reply with such helpful information!
(Score: 0) by Anonymous Coward on Thursday April 16 2020, @12:39PM (2 children)
Had to learn it as part of my CS degree in the late 90s. Never quite understood all the hate it got, it wasn't a horrible language just very rigid.
(Score: 0) by Anonymous Coward on Thursday April 16 2020, @03:47PM
(Score: 1, Informative) by Anonymous Coward on Thursday April 16 2020, @07:42PM
Its partly because of what the AC said. It can be awfully verbose and equally laconic, depending on the programmer. The real problems is that, as I mentioned above, the data structure comes first and the code last. Many coders, especially the young or otherwise undiciplined ones, like to throw crap on the wall without thinking of everything else first. Not that that way of thinking can't be correct in the right situation or language, but it goes strongly against the COBOL paradigm. On top of that, like I also said, even if you get the COBOL part down, that is only 1/3 of the problems you will have in the "real world." Without equal or better understanding the rest of the environment, you still might not get the output you expect from the system your code runs on. So you commonly end up with someone who invests the time in learning to think of structures first and the COBOL syntax/semantics and then they get frustrated because that still isn't enough for an actual COBOL job because COBOL "programmer jobs" are usually more than just "coders" or "programmers" or dealing with COBOL. So they, naturally, conclude that the problem isn't them, but inherent in the language, the people hiring them, or the system, depending on exactly where they start having problems.