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, @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.