71–80 of 193 posts
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…
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.
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.)
Earlier quoted context omitted.
> Can LLMs do Cobol? I imagine it's the one place where LLMs would absolutely shine. COBOL jobs are usually very verbose, lots of boilerplate, but what they do is mostly very straightforward batch processing. It's ripe for automation with LLMs. The flip side is that banks are usually very conservative about technology (for good reason).
IMO the ideal path to working on COBOL without having decades of experience would be to spend a few days groking the syntax and writing toy programs for practice, then collaborate with a large LLM to understand the current code and gradually make changes.
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…
Can you describe the cultural gap? I haven't really met these folks in the wild, so I'm curious what the programmers of yore were like.
On the other hand, these guys generally write pretty neat, lean code that is quick, reliable, and directly responsive to the business. The really fun thing is watching the users fly through the keyboard-only screens, sometimes with muscle memory that is faster than the terminal emulator can update - they're literally working ahead of the screens.
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…
Can you describe the cultural gap? I haven't really met these folks in the wild, so I'm curious what the programmers of yore were like.
From a technical-cultural perspective it was mostly sulkiness, and a complete and utter lack of embracing the paradigms of distributed computing. Also, like most internal clouds, there were plenty of issues as it was. Initially they just tried to replace mainframe application components 1:1 onto VMs in whatever way and whenever anything was The developers I spoke with in that time though, were very much the opposite of the move fast breaking things crowd. Intelligent, but also narrow minded I would say.
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.
Earlier quoted context omitted.
Can you describe the cultural gap? I haven't really met these folks in the wild, so I'm curious what the programmers of yore were like.
In my experience, it's usually lack of awareness about modern security risks, and lack of familiarity with modern infrastructure paradigms. The latter really isn't a problem since these systems are usually standalone, but the former does become a problem - they often are from a time where this just wasn't something to consider. As a result, these legacy systems are often using default passwords, have tons of crazy st…
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…
Dumb question: mainframes and z/OS look interesting, how does one get started with learning about those systems and those environments ?
There are some free resources available that will allow you to get training but I haven’t tried them myself. IBM Z Xplore is worth a look as an example: https://www.ibm.com/products/z/resources/zxplore
I hope you find a way in, more mainframe developers and sysadmins(often called systemsprogrammers in the mainframe niche) are always needed.
Edit*: Spelling and grammar