When I'm in the office I'm on the 4th floor of a 6 story building and I noticed that there were all these OLD nerdy looking guys (and a few women), that all worked on the 6th floor. I'd guess those are folks in their 70s, there's one that I would guess might be 80…

So I asked one of them one day what they did up on the 6th floor, and he explained they work on mainframes and they all are COBOL programmers.

I mentioned to him that I'd had a few classes in that many years ago, he said if wanted to get back into that he could get me a job with no problem. I declined!

BANA with the MIS track here. Had to take multiple COBOL classes. My first position after graduation was a sys admin for a small medical billing firm, and they valued COBOL so much that the first thing they did was sign me up for RPG-400 training to run the brand new AS400 they got talked into buying. I never wrote a single line of COBOL in my entire career.

Down goes COBOL! Down goes COBOL!
Pushing ai hard, someone will make a mistake and loose the ai upon us that will lock out humans from the internet. We will need a nerd super hero.

Wanna beat the machines? FORTRAN or GTFO!

I've worked on a number of large modernization projects. Every legacy system were written in COBOL.

Bobaloo said:

---

I've worked on a number of large modernization projects. Every legacy system were written in COBOL.

---

Seems like Y2K was mostly a COBOL issue, no?

I loved my pic of Snoopy we did in Fortran.

techno-ag said:

---

Bobaloo said:

---

I've worked on a number of large modernization projects. Every legacy system were written in COBOL.

---

Seems like Y2K was mostly a COBOL issue, no?

---

Not at all. Y2K was a century rollover problem in tons of platforms.

The Sun said:

---

techno-ag said:

---

Bobaloo said:

---

I've worked on a number of large modernization projects. Every legacy system were written in COBOL.

---

Seems like Y2K was mostly a COBOL issue, no?

---

Not at all. Y2K was a century rollover problem in tons of platforms.

---

I just seem to recall a lot of guys getting hired out of retirement. It was one of the reasons the alarm was sounded. They said too few programmers knew the legacy programs that still ran everything.

The 99 to 00 rollover was just #1

Just wait until Jan 19, 2038 suddenly becomes Dec 13, 1901 and the computers think we're headed for WWI.

G Martin 87 said:

---

BANA with the MIS track here. Had to take multiple COBOL classes. My first position after graduation was a sys admin for a small medical billing firm, and they valued COBOL so much that the first thing they did was sign me up for RPG-400 training to run the brand new AS400 they got talked into buying. I never wrote a single line of COBOL in my entire career.

---

BANA MIS here as well.

The Sun said:

---

Max Stonetrail said:

---

In 2026, was IBM really deriving that much revenue from COBOL? If that is what caused this, seems overdone.

On another note, COBOL is so wordy and long, it's no surprise that it has even take AI a few years to crank anything out.

---

IBM charges a lot for COBOL and its compilers. I don't know why this news would effect IBM stock though as they just sell the licensing to it. Faster methods of writing COBOL shouldn't effect their revenue.

---

It's my understanding that most of that COBOL runs on 360 mainframes. IBM makes lots of money from leases and services on that infrastructure.

The thinking is that Claude ingests the COBOL and spits out Python or Go or whatever and that runs on Linux instead. It's about the transition away from it.

Logos Stick said:

---

The Sun said:

---

Max Stonetrail said:

---

In 2026, was IBM really deriving that much revenue from COBOL? If that is what caused this, seems overdone.

On another note, COBOL is so wordy and long, it's no surprise that it has even take AI a few years to crank anything out.

---

IBM charges a lot for COBOL and its compilers. I don't know why this news would effect IBM stock though as they just sell the licensing to it. Faster methods of writing COBOL shouldn't effect their revenue.

---

It's my understanding that most of that COBOL runs on 360 mainframes. IBM makes lots of money from leases and services on that infrastructure.

The thinking is that Claude ingests the COBOL and spits out Python or Go or whatever and that runs on Linux instead. It's about the transition away from it.

---

It's not rewriting the code that is the issue, it's the putting it into production without any hiccups. Something like 80%-90% of global card transactions run through COBOL because it is so engrained in the processing infrastructure. None of the people running these systems want to risk screwing up something that processes trillions of dollars in transactions a day because tiny mistakes could potentially cost billions. Think replacing a carburetor with a fuel injection system while trying to drive. It's basically an issue of, "If it ain't broke, don't fix it."

ABATTBQ11 said:

---

It's not rewriting the code that is the issue, it's the putting it into production without any hiccups. Something like 80%-90% of global card transactions run through COBOL because it is so engrained in the processing infrastructure. None of the people running these systems want to risk screwing up something that processes trillions of dollars in transactions a day because tiny mistakes could potentially cost billions. Think replacing a carburetor with a fuel injection system while trying to drive. It's basically an issue of, "If it ain't broke, don't fix it."

---

Exactly. There's nothing wrong with Cobol, especially for batch processing which is what it was designed for. Online Cobol programs otoh could be a pain in the butt, not because of Cobol, but because of CICS.

DeschutesAg said:

---

ABATTBQ11 said:

---

It's not rewriting the code that is the issue, it's the putting it into production without any hiccups. Something like 80%-90% of global card transactions run through COBOL because it is so engrained in the processing infrastructure. None of the people running these systems want to risk screwing up something that processes trillions of dollars in transactions a day because tiny mistakes could potentially cost billions. Think replacing a carburetor with a fuel injection system while trying to drive. It's basically an issue of, "If it ain't broke, don't fix it."

---

Exactly. There's nothing wrong with Cobol, especially for batch processing which is what it was designed for. Online Cobol programs otoh could be a pain in the butt, not because of Cobol, but because of CICS.

---

IMS is another big issue as well. You sound like a fellow mainframer.

Logos Stick said:

---

The Sun said:

---

Max Stonetrail said:

---

In 2026, was IBM really deriving that much revenue from COBOL? If that is what caused this, seems overdone.

On another note, COBOL is so wordy and long, it's no surprise that it has even take AI a few years to crank anything out.

---

IBM charges a lot for COBOL and its compilers. I don't know why this news would effect IBM stock though as they just sell the licensing to it. Faster methods of writing COBOL shouldn't effect their revenue.

---

It's my understanding that most of that COBOL runs on 360 mainframes. IBM makes lots of money from leases and services on that infrastructure.

The thinking is that Claude ingests the COBOL and spits out Python or Go or whatever and that runs on Linux instead. It's about the transition away from it.

---

360s haven't been around since 1978. Yes COBOL primarily runs on IBM System Z, z/VM and AS/400.

Claude will not be able to convert financial applications accurately. There is too much institutional knowledge passed down over the years in understanding why things are written as they are. Don't get me wrong, it could certainly covert the code but the meaning behind it would be lost.

Working Storage Section.

TexasRebel said:

---

The 99 to 00 rollover was just #1

Just wait until Jan 19, 2038 suddenly becomes Dec 13, 1901 and the computers think we're headed for WWI.

---

what..????

we need 10000000 more H1Bs to help us tide through it.

eric76 said:

---

Are there even any COBOL programmers left who are not already at least 65?

---

Yes.

I'm not one of them, but I work for a company that has them.

techno-ag said:

---

Bobaloo said:

---

I've worked on a number of large modernization projects. Every legacy system were written in COBOL.

---

Seems like Y2K was mostly a COBOL issue, no?

---

It happened in other languages too: You could printf("19%d", stTime.tm_year) and get wrong results in the year 2000.

But COBOL was especially vulnerable because its variable declaration syntax requires specifying how many digits each number has. So you'd have to change YEAR PIC 99 to YEAR PIC 9999. Whereas in more modern languages, you'd just have "int year" and not think about it.

wtf are we using a sign bit for in the time?

Do you want Y2K38?
That's how you get Y2K38!

uint64_t

Let them worry about it again in 585 billion years.

My father (who passed in 2024) is going to be very upset to find his COBOL skills are no longer required.

I'll keep saying it, AI will be the worst thing that's ever happened to us.

My large state agency finally turned off our Cobol based system in June of 2025 after it came online in 1997.

We only had 4 people who could still code in that language and they were all retire/rehires.

so happy not to deal with Cobol programming times and waterfall programming methods.

DeschutesAg said:

---

Gilligan said:

---

eric76 said:

---

Are there even any COBOL programmers left who are not already at least 65?

---

Current or former?

---

Maybe A&M is still running some legacy Cobol-based systems.

A&M is an enormous nonprofit government entity that sells higher education, does research, and provides many other services. To run those enterprises, there must have been many COBOL-based systems that used to run on A&M's OS/MVS mainframe. And the USDA, the Texas Railroad Commission, the state's Ag Extension Service, NOAA, and several other federal and state government agencies probably had many systems written in Cobol that ran on A&M's IBM (or Amdahl) mainframe.

---

The lynchpin holding everything together is a bunch of 50 year old legacy cobol systems. Whomever finds a way to fix these and account for the 500+ to 1000+ edge cases will be a trillionaire company. No I'm not joking, that's how big of a deal it is.

I'm also a BANA MIS grad who took the two COBOL classes under Dr. Ajay Vinze back in the late 80s. I am a former professional COBOL programmer with American General for roughly 3 years in the late 90s. I currently work with a software consulting firm and am on a client project modernizing a COBOL code base to Java. We are using AI in the form of GitHub Copilot to accelerate the engineering; I'm using the Claude Sonnet 4.6 model.

Just looking at the COBOL code has made me damn glad I've spent the last 30 years working in pretty much any other language (VB, C#, Delphi, Java, even JavaScript).

There's an object-oriented version of COBOL now. It's called ADD 1 TO COBOL.

Oh yes... As if COBOL wasn't warped enough, I had the hilarious Turkish prof Dr Yurtass teach it

"Don't tell me 'I know these things.' I know you know these things but the problem is you never do."

"You know what I always say, 'kill three birds with two stones'."

"You will never do this; that is the 1950's way of programming."

"PHP is hippy technology"

"We all know the difference between "regular" and "friend" functions already. It's just like real life: we let friends touch our private members, but if just anyone tries to touch them, we throw things. In this case, it would be compiler errors, but in the real world it's things like bricks."

I took an entire semester covering cobol! Now what, I'll have to GO TO ANOTHER-JOB

Yeaaaah I'm a little concerned how well these new models can code.

Punch cards, Wilbur...and Fortran or gtfo.

TexAgs91 said:

---

Oh yes... As if COBOL wasn't warped enough, I had the hilarious Turkish prof Dr Yurtass teach it

"Don't tell me 'I know these things.' I know you know these things but the problem is you never do."

"You know what I always say, 'kill three birds with two stones'."

"You will never do this; that is the 1950's way of programming."

"PHP is hippy technology"

"We all know the difference between "regular" and "friend" functions already. It's just like real life: we let friends touch our private members, but if just anyone tries to touch them, we throw things. In this case, it would be compiler errors, but in the real world it's things like bricks."

---

Oh yes, what a memorable professor.

I remember him opening a compiled executable in a text editor and saying "You can't read this because it's written in Turkish."

Cinco Ranch Aggie said:

---

I am a former professional COBOL programmer with American General for roughly 3 years in the late 90s. I currently work with a software consulting firm and am on a client project modernizing a COBOL code base to Java. We are using AI in the form of GitHub Copilot to accelerate the engineering; I'm using the Claude Sonnet 4.6 model.

Just looking at the COBOL code has made me damn glad I've spent the last 30 years working in pretty much any other language (VB, C#, Delphi, Java, even JavaScript).

---

The logistical challenges of replacing an existing production system. Fun fun fun. Especially because the legacy code and legacy database file structures are in production and usually aren't static; they have to be updated, maintained, and modified by the production coding team due to ongoing mandatory business requirements.

DeschutesAg said:

---

Cinco Ranch Aggie said:

---

I am a former professional COBOL programmer with American General for roughly 3 years in the late 90s. I currently work with a software consulting firm and am on a client project modernizing a COBOL code base to Java. We are using AI in the form of GitHub Copilot to accelerate the engineering; I'm using the Claude Sonnet 4.6 model.

Just looking at the COBOL code has made me damn glad I've spent the last 30 years working in pretty much any other language (VB, C#, Delphi, Java, even JavaScript).

---

The logistical challenges of replacing an existing production system. Fun fun fun. Especially because the legacy code and legacy database file structures are in production and usually aren't static; they have to be updated, maintained, and modified by the production coding team due to ongoing mandatory business requirements.

---

As computers and the internet mature from being a novelty to core infrastructure, these challenges will only get harder.

Imagine being a software developer in 2226 and having to deal with complaints from co-workers that they can't get their W-2 because Payroll's application server can only handle one COBOL thread at a time and so it gets overloaded.

There's actually a lot of stuff so running it from what I remember. It's been around and embedded so long it's easier to maintain than convert.

The deeps space relay network comes to mind

I am waiting for some idiot young hotshot CEO to arrogant declare that he now that he has AI, he doesn't need anyone else, unceremoniously layoff the 60+ age group of COBOL programmers and then get this army of H1Bs he shipped in from India at $30/hr to modernize the existing systems that process millions of dollars of transactions.

When can we see this funny event? I am waiting with popcorn.