r/cobol

Four months ago IBM stocks suffered a huge hit after Claude Code demonstrated some COBOL AI capabilities.

The Tech industry has been also suffering mass layoffs dating back a few years after the pandemic.

I've seen the job market in my stack suffering a lot, I'm not receiving many offers (or any at all), and I have friends unemployed and unable to secure a new job for months (sometimes 6 or 8+ months waiting).

As someone that started learning about mainframe and COBOL just now, I wonder, how did you already in the industry have suffered or observed about these recent moves?

Have any of you suffered a layoff following this IBM stocks/AI COBOL announcement?

Have you seen mainframe/cobol colleagues suffering with the mass layoffs?

I've worked with many different programming languages for the past years, and I've been focusing in Go and Scala for the past 5 years.

I'm just starting with Mainframes and looking right after Cobol, I don't know why, but Mainframes and Cobol have been growing into me. Both Go and Mainframes are the only two things that made me feel the joy of programming again after a decade of work.

However, I do wonder, what do you think about the future in the Mainframe job market, or how it has been for you so far?

Hello guys. I am a university student, and i am learning COBOL these days. I am doing this in WSL (Ubuntu). So what i want to know is what kind of editors you guys are using and any recommendations for me.

I'm not a COBOL developer by profession, but I've been spending a lot of time trying to understand how large COBOL applications are maintained in the real world.

One thing I'm curious about:

Imagine someone drops a change request on your desk for a COBOL application you've never worked on before.

What does your process actually look like?

Do you start with:

• JCL?
• Program search?
• Copybooks?
• Existing documentation?
• Dependency analysis?
• Talking to someone who knows the system?

And what usually ends up consuming the most time?

I'm asking because from the outside it seems like the coding part might be easier than figuring out where the change needs to be made and what else it could affect.

Would love to hear real stories from people who work on these systems.

Serious question for people who actively work with COBOL.

If you had a magic button that could instantly solve ONE problem when maintaining or modifying a large COBOL application, what would it be?

Examples:

• Finding where business logic lives
• Understanding dependencies
• Impact analysis
• Tracing data flow
• Outdated documentation
• Knowledge trapped with a few senior developers
• Something else entirely

I'm curious whether the biggest challenges today are technical problems, documentation problems, or simply understanding systems that have evolved over decades.

Would love to hear what your "magic button" would solve.

I'm trying to understand how real mainframe applications are actually structured, and I'd value the perspective of people who've worked on them.

When you look at a production COBOL estate, how much of the meaningful business logic lives within a single program versus emerging across a chain of programs in a job stream? If you took one program out and ran it in isolation, would its behaviour be self-contained, or is so much driven by shared state, run order, and upstream/downstream steps that a single program doesn't mean much on its own?

I ask because I keep reading that COBOL programs are "more like modules" that work together as an application — so I'm trying to gauge how decomposable a real system actually is into pieces you could understand (or test) independently. Is that realistic, or a beginner's misunderstanding?

A question about how these systems behave when the data goes wrong, rather than the happy path. 

When a batch program hits something like a divide-by-zero, a numeric field overflowing its size, or an invalid value where a number should be — in practice, does the typical production program abend (and the job stops), or does it carry on, maybe with ON SIZE ERROR handling, maybe with a leftover or default value in the field? 

I ask because I imagine the ‘normal’ answer varies a lot — some shops code defensively with ON SIZE ERROR everywhere, others let it abend so nothing bad slips through silently. What's been your experience of how these edge cases are actually handled, and have you seen cases where a program quietly continued with a wrong value rather than failing loudly? Any war stories there would be really helpful. 

I'm trying to understand what ‘the same output’ really means when one COBOL program's output file feeds into another system. 

My assumption is that it depends on what the downstream system actually consumes. If it reads the literal characters/bytes of the file — including how a number is formatted, how a sign is represented (trailing sign, overpunch, CR/DB), how fields are padded — then two files that represent the same values but format them differently would NOT be interchangeable. But if the downstream just decodes the values, the formatting wouldn't matter. 

In your experience, which is it usually — is the exact byte-level layout and sign/format representation of an output file load-bearing for whatever reads it next, or do downstream systems mostly re-parse into values so formatting differences wash out? Trying to understand whether ‘identical output’ has to mean byte-for-byte or just value-for-value.