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

Very old coder here. Wrote COBOL to help Atari add features to a inventory processing system to account for the fact that "inventory" intially was items received at the loading dock, fork-lifted to the shipping dock and shipped. So "inventory" needed to be booked immediately as sales. Now I dabble mostly with Python and JS/HTML. My memory of the Atari gig was that the most critical part was the CICS code. There was just one guy who knew enough to setup the CICS. If he got hit buy a bus... Well after about a year, the bus would not have mattered. Atari buried millions on unsold carts, and I went from working in a beautiful office complex next to Great America Park, to a windowless basement closet somewhere near Mountain View now making changess because the "forklift inventory" version was no longer needed. I know this is a bit off topic, but "COBOL" was the into I needed.

My mother and her husband are COBOL devs for a US state government. She works on the health insurance side for teachers and other state employees. Think claim processing.

Lots of batch jobs running at night. Their alert system is an actual human who calls my mom when jobs fail in the middle of the night.

It's high paying for the city they live in, but not high paying for software development. They will both have full retirement and healthcare for life, assuming the government can fulfill it. They are both fully remote since COVID too.

She's also worked for state lottery, teacher's retirement system and DOT.

edit: she says they have a SQL database, but mostly store in IBM IMS

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 have run IBM MQ as well.

If changes are made to these systems it’s often due to changes in regulation or driven by changes in the business(new financial products being offered etc.

Off-topic: I’ve seen quite a few mainframe related posts on HN fly by over the years. I’ve been meaning to create an account and participate but I’ve only gotten around to it just now.

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 was no remote desktop back then.

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 a new system was built in-house (no longer trusting external consultants) and his job was explaining what the system does. Probably well paid but he didn't seem to care, he just wanted to work less and retire on good terms.

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 (“regular REST APIs”) as well as consuming from and producing to Kafka among other things. We integrate with both mainframe and distributed systems on prem as well as “internal” systems hosted on cloud.

We use Git for source control but have a CI/CD solution that is built in house. Quite a lot of other infrastructure is also built in house.

I am mid 30s and am on the younger side looking at the mainframe area as a whole at my employer, however in my team we have several developers is in their 20/30s.

My background is mainly back- and frontend development on the Microsoft tech stack but I have worked, and do work, with whatever is at hand/required. But mostly stuff like .NET and SQL Server on the backend, and Angular/Vue/React on the front end before this.

Not a COBOL developer, but working at a sizeable bank I witnessed the phasing out of their mainframes and AS400 systems. They ran some critical systems, both in retail and wholesale banking. They either converted to java, and optimized that code, but some COBOL code from the mainframe, and all of the AS400 stuff was converted into Micro Focus COBOL, which runs on Windows, which could be hosted on our Private Cloud. I worked on helping them migrate to our cloud infra, which was an interesting exercise. There was a very tangible cultural gap between the people maintaining and developing these applications and the rest of the organization.

I've had a bunch of recent projects reverse-engineering old COBOL code, in financial services.

Mostly to figure out the best way to replace the old systems with something newer, so not really as a "COBOL dev", though.

I haven't worked in COBOL, but I've worked with it.

This was around 1999, and I was building a system for configuring and ordering custom PC's at a large distribution company. One of the feature requirements was that we display inventory over the various options. (ie: There are 373 20G disks in stock, but only 12 30G disks in stock). The idea was that this would let a customer ordering 200 machines know that they should pick the 20G disk if the wanted it now.

The way inventory at this company was done was via two systems. There was a normal SQL database that had access to a daily snapshot of inventory taken from a mainframe that always had the up to date data. With the mainframe taking a while to process queries, we used the less current SQL database for the majority of the UI, but took the time to query the mainframe once a customer was in the shopping cart. Customers might see a change during the flow, but it would at least let them see the most current data prior to committing to a purchase.

The mainframe query itself was implemented by someone else as a COBOL job that produced the required inventory numbers. From my point of view, it was just a limited sort of query conducted over a specialized JDBC driver. (Not necessarily the weirdest aspect of that design.... for a variety of reasons, we did the UI in ASP/VBScript, the back end using Microsoft's JVM invoked via COM Automation, and the SQL database link was via a dubious use of a JDBC/ODBC bridge to connect to SQL Server. It all worked, but not the most solid architecture.)

==

My only other mainframe experience was working as an intern for a utility company a few years prior (1991-1992). They used CDC Cyber mainframes to run the power grid, using something like 4MM lines of FORTRAN code. The dispatchers themselves interfaced to the system using consoles with 4 19" color displays running at 1280x1024. Heady stuff for 1991. (The real time weather radar screen was cool too, in an age before the internet made it common place.)

I met a dev who's mom had been working on legacy banking systems her whole career. She had started in the eighties and she still did some urgent jobs at a crazy rate despite officially having retired.

Not Recently. 2010ish was working for an insurance processor that was actively writing thousands of lines and executing on z/OS with no plans to migrate.

I was part of team that was writing web applications that needed to call z/OS transactions. The IBM solution was to use their Transaction Gateway product, which cost a ton, and was slow as shit. We developed a framework that used annotations on the Java Side to map COBOL Records to Java Objects and invoke transactions over a TCP socket. Learning how to pack decimals and convert encodings was pretty cool. We ended up with a framework that was at least a zillion times faster than the IBM solution. Left that job though as the company was is distress and was losing customers (health plans). They eventually folded.

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.

I have written cobol in the past. I worked at a financial company that had a decent amount of cobol devs around, with the primary database being DB2. The code is mostly financial transactions and record updates, basically CRUD code. Cobol was essentially the backend with the front end being Java and Javascript/Angular.

My brother works with COBOL for a bank here in Brazil, he is young (in his 20s), started before finishing his degree. Pay is poor, hours are insane, he is overworked as hell, and anything “modern”, like git, is out of the question.

He’s trying to learn Go now and modernize himself to see if he can get out. I’m trying to help as much as I can. Hopefully, he’ll land a job somewhere else this year.

I have a friend who works writing COBOL for a US state government, I sent him this post and this was his response:

I work in COBOL for government systems.

We upgraded our old mainframes to IBM Z16's, and we just got some new ones in recently for our backup server.

Part of the job is taking whatever they decide in legislation and translating that into code that processes whatever they decided to make law, from fees, suspensions, special legislation for certain areas, etc.

Our programming environment primarily uses TSO/ISPF and changeman for version control. We have access to IBM's IDz (previously RDz) as an IDE for development, and I would personally prefer to use that but haven't been able to get it installed on my work computer due to licensing issues. Part of security protocol is that we cannot use anything open-source, so VSCode with Zowe is, unfortunately, out of the picture.

We maintain a lot of old programs and modules, but we are also actively developing new programs as we expand our IT department - and yes, that is new COBOL programs. We have a Linux side as well which mainly deals with the web-side, but they still interact with the mainframe to call on modules - but all they are really doing is sending data to CICS to get data back. They do not know anything about the COBOL itself or how to program in it.

What I'm wondering: Are the salaries high? Not just because you've been employed at the job for a long time with regular raises, but because it's hard to find developers.

My father is 75 and he still works, has his own software development company with his own back-office program written in cobol. He started a company back in 1991 with two other cobol programmers, they are retired now, and while almost all of the code they wrote has been replaced with c# code by younger programmers there are still some parts of the code written in cobol that he still maintains.

Global Shop ERP is written in Visual Cobol, believe it or not. Supposedly they are actively rewriting the eight million lines of code to C#.

In undergrad(around 2005) we used to have a COBOL lab, most of the assignments were pretty much add/update/delete types. A friend of mine found COBOL so boring, in order to keep it interesting he wrote COBOL program for brothel(not real one), to maintain the customers, prostitutes, transactions and whole nine yard. Despite of not liking the language, he was the best COBOL programmer in college.

Related [0]

[0] https://research.ibm.com/blog/watsonx-code-assistant-for-z-i...

Apropos of nothing in particular, there's an older HN thread about "Good resources for learning COBOL" that some folks here might find interesting. OK, calling it a "thread" is over-stating things, but still...

https://news.ycombinator.com/item?id=18479536

This is in my past, so no COBOL recently but in one of my first consulting gigs I wrote several business programs in RPG III. Which is the nightmare that you might imagine it is. Think plugboards. Halfway through the IBM guy came by and installed COBOL and wow what a difference. My last act was to recommend that they get a computer department. And so Tom Monaghan called IBM

I've done COBOL since the 80s, but I don't have a paying gig for it anymore. That said, I have situations where I need to process a flat file of data, and I find it a lot easier to just fire up gnucobol and write the program than try to remember the syntax for python or golang.

Learned COBOL in the 90s as an undergraduate at university. Took it at the same time as PC Assembly language (woefully 16 bit).

I had less trouble with assembly than COBOL at the time I'm afraid.

They're both weird beasts, but once I learned the C calling conventions for assembly, I was able to make a lot more sense of the assembly.

COBOL is a world unto itself. I didn't hate it, but I didn't think I saw a career in it either.

I'm just glad I opted not to take RPG :-)

For my sins, I work in Education supporting PeopleSoft. That means that I do work in COBOL on occasion. I am not tasked with writing anything new in COBOL, but I so quite a bit of analysis and support. That is: I _read_ COBOL more than I write it.

There are three flavors of COBOL that I deal with: PeopleSoft delivered, Vendor delivered, and University modified. Most of the work I do in COBOL breaks down to reading the code to determine why a given behavior is observed. Only once (in University modified code) have I needed to make an actual edit. The rest of the times I either modify the flow of information into the COBOL code or I modify the resultant after the code has run.

I am not a COBOL dev but have worked on a few codes here and there. I played around with LLM and it appears to be not too bad at COBOL, what’s the consensus or your experience utilizing LLM for COBOL?

I worked as a cobol dev in my first fulltime job. I did mostly cobol85 (microfocus) and object-cobol (netexpress/fujitsu cobol), with isam files. Did the whole "migrate to year 2000" process in a couple of big but old applications (healthcare management software and manufacturing management software). Cobol is a school by itself; there are so many ways you can shoot yourself in the foot that one either learn how to structure programs avoid a spaguetti mess, or slowly descend into madness trying to fix bugs :)

Not COBOL but years ago I did some work on IBM AS/400 using RPG. For those who don’t know, RPG was originally written (in 1959) for punch cards and the programs had to be written in a pattern that resembles punchcard. It was a fun experience and I am grateful to have dabbled in it.

Many megacorps still run AS/400 and it’s uptimes and performance is legendary.

Edit: Forgot to mention that I was mentored by folks more than twice my age that time.

I do other things besides COBOL but I maintain and occasionally enhance many COBOL applications:

- Item Database (SKU, UPC, attributes)

- Stock Status (Sales, Onhands, process sales transactions from POS systems)

- Replenishment (Create vendor and DC orders to stores)

- Reporting (Report sales and other performance data by stores, departments, classes, etc..)

- Pricing (make and maintain current and future price changes, send to store when needed).

- Many other applications (15+)

They have been saying they are going to get rid of these applications for over 20 years now. I am still waiting...

Government. About 25% of my job. No day to day mainframe development, but we do need to update some logic for new policies and regulations.

There’s not much maintenance work. There are very few bugs, as the core applications have been running for decades, most come up with interactions to external services.

Any major development projects are only in service of lower overall COBOL development time, like transitioning some business logic to database updates.

And there is a decommission plan for the mainframe, so plenty of work helping that team.

I don't code in Cobol myself anymore but I manage team who does.

We work on Phoenix, government of Canada payroll system. If you google it up, you'll see some interesting coverage. However, the underlying peoplesoft ERP itself is rock solid at every other client I've served over last 25 years. Peoplesoft uses Cobol and sqr, as well as proprietary languages stored in database, application engine and peoplecode.

Key payroll processes are in Cobol. This is because of its tight integration with database and ability to manually control database cursors. We are very database oriented when it comes to performance. Our developers need to know the programming language, but also deep understanding of client business processes, and sql optimization. They also work closely with our dbas to ensure good performance. So our developers are technically proficient in Cobol and couple of other languages, but also very very strong in sql optimization, and understand clients payroll rules and can speak intelligently with compensation advisers and payroll processors.

I personally found that to be true for most Cobol programmers - whereas typical hacker news Dev seems very technology oriented and frequently moving, typical Cobol programmer is very business process aware and integrated with corporate line of business. They don't move as much for several reasons, but that deep awareness of client is one of them.

Edit: I shoild mention, while peoplesoft can and does work on mainframe, most of my clients are on windows, Linux, or AIX. COBOL is not quite as mainframe specific as it sometimes seems :-). See e.g.microfocus Cobol for a modern multi platform compiler.

About 10 years ago I was working on a net-new COBOL compiler for z/OS. There was a huge demand from banks especially for this.

I know some COBOL devs. They work in a bank.

They wouldn't hang around here though.

Not a COBOL dev myself but for many years I worked in government healthcare for my state. Probably 75% of developers and BAs for the organization were working to support an extremely large mainframe system(s). I worked as a web developer and we had to use a product called Hostbridge that allowed our web applications to interface with the mainframe via javascript.

I still remember this crazy time where COBOL engineers were in dire need: https://news.ycombinator.com/item?id=22787828

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?

I knew a guy who wrote a lot of 360 assembler back in the day, never a COBOL programmer.

2075 HN: Ask HN: Any active Java devs here? What LLM do you use?

Not me, but not even 5 years ago one of my friends was working on Cobol codebase running on IBM zOS. It did not last long, but as far as know they had a decent time.

A note-taking app.

I’m not affiliated, but this made me think of this AI for COBOL startup: https://www.cobolcopilot.com/

For some reason I think we’re all drawn to the idea of working with an older language. I wonder why!

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.

Y'all commented about the number of terminal colors. That's funny. Only 1 color is needed for programming. The IBM mainframe terminals (3278) were called Green screens for a reason.

Cloud migrations

I worked with COBOL in banking, a lifetime ago. It was one of my first jobs.

Batch jobs, clunky and very verbose programs, nothing interesting. I... hated it.

Maybe the COBOL devs aren’t here.

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 have largely left HN for a few reasons:

- They're tired of being shouted down by the Reddit-quality ageism that lingers through this forum.

- They're mature enough to no longer be interested in chasing every little tech fad as if their lives depended on it, and that's 90% of what HN has become.

- As most older people do, have other things in their lives that are more interesting than work. Family. Children. Hobbies. Traveling. Service. The world is full of things more rewarding than being terminally online, or being reminded of your day job.

I applaud your curiosity, but you're standing in a church asking, "Where are all the atheists?" COBOL devs aren't here. And where they are is likely not online.

not cobol but we do a hell of a lot of business basic.

Bank.