Ask HN: Any active COBOL devs here? What are you working on? • Hacker News Board

Re: Ask HN: Any active COBOL devs here? What are you working on?

#141

Post by freedomben » Fri, Jul 18, 2025, 5:46 PM UTC

hnurl wrote: post #133

I am working as a mainframe developer at a bank, currently within a kind of data warehouse solution. Mainly writing in COBOL and Java (in USS), with some scripting in Rexx for internal ISPF tools. A lot of SQL as well, we use DB2 as our main database. Most of our processes are EOD centric, we run a lot of batch jobs (mainly TSO, very little IMS). Integrations are mostly file based but we do both call and expose APIs…

What are wages like? I heard several years ago that you could land a sweet high paying COBOL gig, but from what I've read recently that doesn't seem to be true?

Re: Ask HN: Any active COBOL devs here? What are you working on?

#142

Post by sethhochberg » Fri, Jul 18, 2025, 5:46 PM UTC

gosub100 wrote: post #136

zeeframe wrote: post #18

I’m not a COBOL dev but I work with mainframes(z/OS). Most COBOL applications I’ve seen have been banking and insurance related with few exceptions. Most of them either run as a series of batch jobs or via transaction managers like IMS and CICS. Backends are usually sequential files(we call them datasets),DB2,VSAM(Virtual Storage Access Method) or DL/1(hierarchical DB that’s part of IMS). Quite a few places I’ve seen…

What is the primary computational task for insurance? Is it computing actuarial tables? Or accounting for the premiums/claims? Or something else? I can excuse banking for not switching off of COBOL but I fail to see how insurance uses it to any significant degree.

Some less-common varieties of life insurance start to look a whole lot like investment products and are (sometimes controversially) sold as such for people in very specific financial situations - think like cash value and death benefit value that vary over time based on asset performance. A legacy insurer selling Variable Universal Life or similar policies would have some financial calculation needs.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#143

Post by FlyingSnake » Fri, Jul 18, 2025, 5:47 PM UTC

haiku2077 wrote: post #89

kazinator wrote: post #60

Earlier quoted context omitted.

PuTTY into Linux and you're in 16 colors.

My Linux terminal is 256 colors. Two hundred fifty six! That's like, every color!

256 colors ought to be enough for anybody.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#144

Post by krylon » Fri, Jul 18, 2025, 5:50 PM UTC

TechDebtDevin wrote: post #69

slowmotiony wrote: post #37

I work with a lot of COBOL dinosaurs in the bank, I often like to watch them work on their 16-colors IBM z/OS host terminals, it's quite mesmerizing. Sometimes they show me some interesting code that was written before I was alive (I'm 36), or tell me stories about big mainframe incidents in the '80s, where they would get called in the middle of the night and flown to a different country to fix a bug because there wa…

This hasn't been virtualized?

They're probably using a 3270 emulator on a PC, but that emulator will still display 16 colors.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#145

Post by papadilbert » Fri, Jul 18, 2025, 5:51 PM UTC

Glad to meet y'all. Yes. I code COBOL along with C, C++, Java, REXX, SQL, and IBM mainframe Assembler. I support the racehorse of IBM mainframe operating systems, z/TPF. There are few familiar with it. Think of z/OS as a Clydesdale horse, big and SLOW.

zTPF runs the airlines, the model for real online transaction systems... Not SQL relational database shopping carts.

Botton line, everything is Assembler. It's all just bits.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#146

Post by palmfacehn » Fri, Jul 18, 2025, 5:51 PM UTC

reaperducer wrote: post #73

Any active COBOL devs here? A legitimate question, but so far not many answers, and they're mostly from people who know people who know COBOL devs. This is to be expected. Demographically, COBOL devs skew older, and there aren't a lot of graybeards left on HN. This place used to be full of them, and they always had interesting and unusual insights and techniques to share. Those days are long gone. IMO, Graybeards hav…

>...they always had interesting and unusual insights and techniques to share.

We need more like this, please.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#147

Post by mcdow » Fri, Jul 18, 2025, 5:51 PM UTC

Followup question: what’s it like to write COBOL? It’s so ancient as this point you never hear anyone actually talking about what the developer experience is like. How performant is it? What features does it have (or not have)? How bad is it really?

Re: Ask HN: Any active COBOL devs here? What are you working on?

#148

Post by kqr » Fri, Jul 18, 2025, 5:57 PM UTC

gosub100 wrote: post #136

zeeframe wrote: post #18

I’m not a COBOL dev but I work with mainframes(z/OS). Most COBOL applications I’ve seen have been banking and insurance related with few exceptions. Most of them either run as a series of batch jobs or via transaction managers like IMS and CICS. Backends are usually sequential files(we call them datasets),DB2,VSAM(Virtual Storage Access Method) or DL/1(hierarchical DB that’s part of IMS). Quite a few places I’ve seen…

What is the primary computational task for insurance? Is it computing actuarial tables? Or accounting for the premiums/claims? Or something else? I can excuse banking for not switching off of COBOL but I fail to see how insurance uses it to any significant degree.

Accounting is a huge part of it. Sometimes claims are not fully resolved for decades, and the books for that policy hypothetically have to be kept open for as long. This must be kept correct, but is not computationally heavy.

Computing total exposures and possible loss distributions are things which can be more computationally heavy. It includes grouping together similar policies which is multiplicative in complexity.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#149

Post by posix86 » Fri, Jul 18, 2025, 6:07 PM UTC

mtmail wrote: post #20

Met one close to retirement who worked on a ERP system in the food processing industry. Nightly batch jobs would trigger orders from their suppliers, customer service would enter new orders. Two SAP migrations already failed, costing the company millions. All company process knowledge was in code, database fields have been repurposed (but no renamed, too much work), feature development stop long time ago. In parallel…

I quickly worked at a company like that, that had large parts of their core business logic running on an AS400, and they were asking what they need to do to migrate to something newer - was surreal. A few hundred employees all interacting with the system - in building A, a deliver arrives, they scan it like this, press this button. Building B, a guys job was to oversee the conversion of tables from As400 to a csv format suitable for some other outsourced software. Data goes into system C and shows to employees working on conveyor belts this and that. Hundreds of kilometers away, truck drivers get a notification for this and that.b

And, nobody knew how the whole worked. Everyone has their niche of interaction with the system. They would be able to shave off an insane percentage off expenses (in the form of employees whose job exists for no real reason), but the switching costs would also be immense.

I sometimes wonder what came of their company. The system was so far beyond the complexity that anyone could grasp, they had no inhouse devs, they'd need people with the competency to judge which competency they need.

Re: Ask HN: Any active COBOL devs here? What are you working on?

#150

Post by psunavy03 » Fri, Jul 18, 2025, 6:11 PM UTC

Work on a dual Java/COBOL team in a F500. Not a COBOL dev myself but I'm surrounded by them. Two biggest problems are:

a) the systems are very tightly coupled, like uber-monolith architecture, and it's hard to QA them without end-to-end testing through everything. Good luck getting anyone to refactor them because a1) they're going away and a2) they're so huge. Which leads into . . .

b) there's 40 years of undocumented business logic in there, or business logic that only exists in code comments. And it still makes billions of dollars a year. So good luck replicating 40 years of tribal knowledge in the new systems.

c) It was written by cowboy coders 40 years ago when the company was a startup, so no one can learn to work on it without first getting hired here. The joke is one of the original architects went and created his own dialect of COBOL.