4 ms·

What languages are people still writing mainframe code in? In 2011 working for a prescription rx processor, COBOL was still the name of the game.

rbanffy 1y ago
There's also lots of Java as well, and IBM is making a big effort on porting existing Unix utilities to z/OS (which is a certified UNIX). With Linux, the choices are the same as with other hardware platforms. I assume you'll find lots of Java and Python running on LinuxONE machines. Running Linux, from a user's perspective, it feels just like a normal server with a fast CPU and extremely fast IO.
- jiggawatts 1y ago
  > extremely fast IO. I wonder how big a competitive edge that will remain in an era where ordinary cloud VMs can do 10 GB/s to zone-redundant remote storage.
  - inkyoto 1y ago
    Guaranteed sustained write throughput is a distinguished feature of the mainframe storage. Whilst cloud platforms are the new mainframe (so to speak), and they have all made great strides in improving the SLA guarantees, storage is still accessed over the network (plus extra moving parts – coordination, consistency etc). They will get there, though.
  - Cthulhu_ 1y ago
    GB/s is one metric, but IOPS and latency are others that I'm assuming are Very Important for the applications that mainframes are being used for today.
    - imtringued 1y ago
      IOPS is the most meaningless metric there is. It's just a crappy way of saying bandwidth with an implied sector size. 99% of software developers do not use any form of async file IO and therefore couldn't care less. The async file IO support in postgres has been released a month ago. It's that niche of a thing that even extremely mature software that could heavily benefit from it hasn't bothered implementing it until last month.
      - jiggawatts 1y ago
        Microsoft SQL Server has been using async scatter/gather IO APIs for decades. Most database engines I've worked with do so. Postgres is weirdly popular despite being way, way behind on foundational technology adoption.
        rbanffy 1y ago
        > Microsoft SQL Server has been using async scatter/gather IO APIs for decades. Most database engines I've worked with do so. Windows NT has asynchronous IO since its VAX days ;-) > Postgres is weirdly popular despite being way, way behind on foundational technology adoption. It's good enough, free, and performs well.
        jiggawatts 1y ago
        I constantly hear about VACUUM problems and write amplification causing performance issues bad enough that huge users of it were forced to switch to MySQL instead.
        pgaddict 1y ago
        I've been involved in a couple of those cases, where a large company ran into an issue, and chose to solve it by migrating to something else. And while the issues certainly exist (and are being addressed), the technical reasons often turned out to be a rather tiny part of the story. And in the end it was really about internal politics and incentives. In several such cases, the company was repeatedly warned about how they implemented some functionalities, and that it will cause severe issues with bloat/vacuuming, etc. Along with suggestions how to modify the application to not hit those issues. Their 10x engineers chose to completely ignore that advice, because in their minds they constructed an "ideal database" and concluded that anything that behaves differently is "wrong" and it's not their application that should change. Add a dose of politics where a new CTO wants to rebuild everything from scratch, engineers with NIH syndrome, etc. It's about incentives - if you migrate to a new system, you can write flashy blog posts how the new system is great and saved everything. You can always argue the original system would be worse, because everyone saw it had issues - you just leave out the details about choosing not to address the issues. The engineering team is unlikely to argue against that, because that'd be against their interests too. I'm absolutely not claiming the problems do not exist. They certainly do. Nor am I claiming Postgres is the ideal database for every possible workload. It certainly is not. But the worst examples that I've seen were due to deliberate choices, driven by politics. But that's not described anywhere. In public everyone pretends it's just about the tech.
  - RetroTechie 1y ago
    On-site. Speed is not the only reason why some org/business would have Big Iron in their closet.
  - FuriouslyAdrift 1y ago
    Latency is much more important than thoughput...
- jandrewrogers 1y ago
  How fast is “extremely fast”? Normal x86 Linux servers drive multiple 100s of GB/s of I/O these days. Storage is only slow because cloud.
  - rbanffy 1y ago
    I never benchmarked it, but the latency feels very low. Mainframes don't have any local storage, so anything it's using will be a box on a separate rack (or spanning multiple racks).
bob1029 1y ago
You can do a lot of damage with some stored procedures. SQL/DB2 capabilities often go overlooked in favor of virtualizing a bunch of Java apps that accomplish effectively the same thing with 100x the resource use.
- exabrial 1y ago
  Hah, anecdote incoming, but 100x times a resource usage is probably accurate. Given, 100x of a human hair is still just a minuscule grain of sand, but that’s the scale margins Mainframe operators work in. As one grey beard said it to me: Java is loosely typed and dynamic compared to colbol/db2/pl-sql. He was particularly annoyed that the smallest numerical type a ‘byte’ in Java was quote: “A waste of bits” and that Java was full of “useless bounds checking” both of which were causing “performance regressions”. The way mainframe programs are written is: the entire thing is statically typed.
  - PaulHoule 1y ago
    I knew mainframe programmers were writing a lot of assembly in the 1980s and they probably still are.
    - BugheadTorpeda6 1y ago
      It's one of the last platforms that people still write a lot of hand written assembly for. Part of this is down to the assembler being very ergonomic and there being a very capable macro system available with macros provided for most system services. Part of it is due to the OS predating C becoming popular, so there are no headers files (just assembler macros) for many older system services (you can thunk them into C compatible calls, but it's sometimes more of a headache than just writing in assembler). Definitely C is becoming more popular lately on the platform, but you will still find a lot of people programming in assembler for a living in 2025. Its probably the only subfield of programming that uses handwritten assembly in that way outside of embedded systems.
  - thechao 1y ago
    When I was being taught assembly at Intel, one of the graybeards told me that the greatest waste of an integer was to use it for a "bare" add, when it was a perfectly acceptable 64-wide vector AND. To belabor the the point: he used ADD for the "unusual set of XORs, ANDs, and other funky operations it provided across lanes". Odd dude.
pjmlp 1y ago
RPG, COBOL, PL/I, NEWP are the most used ones. Unisys also has their own Pascal dialect. Other than that, there are Java, C, C++ implementations for mainframes, for a while IBM even had a JVM implementation for IBM i (AS/400), that would translate JVM bytecodes into IBM i ones. Additionally all of them have POSIX environments, think WSL like but for mainframes, here anything that goes into AIX, or a few selected enterprise distros like Red-Hat and SuSE.
- BugheadTorpeda6 1y ago
  It sounds like you are referring to AS/400 and successors (common mistake, no biggie) rather than the mainframes being referred to here that are successors of System 360 and use the Telum chips (as far as I am aware they have never been based on POWER, like IBM i and AIX and the rest of the AS/400 heritage). RPG was never a big thing on mainframes for instance. I've never come across it in about 10 years of working on them professionally. Same with NEWP, I've never heard of it. And Java is pretty important on the platform these days and not an attempt from the past. It's been pushed pretty hard for at least 20 years and is kept well up to date with newer Java standards. Additionally, the Unix on z/OS is not like WSL. There is no virtualization. The POSIX APIs are implemented as privileged system services with Program Calls (kind of like supervisor calls/system calls). It's more akin to a "flavor" kinda like old school Windows and OS/2 than the modern WSL. You can interface with the system in the old school MVS flavor and use those APIs, or use the POSIX APIs, and they are meant to work together (for instance, the TCPIP stack and web servers on the platform are implemented with the POSIX APIs, for obvious compatibility and porting reasons). Of course, you can run Linux on mainframes and that is big too, but usually when people refer to mainframe Unix they are talking about how z/OS is technically a Unix, which I don't think it would count in the same way if it was just running a Unix environment under a virtualization layer. Windows can do that and it's not a Unix.
  - sillywalk 1y ago
    Nitpick: Almost 20 years ago IBM had the eclipz project to share technology between its POWER (System i and System P) and Mainframe (System Z) servers. I'm not sure if counts as "based on", but "the z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style."[0] The chips were otherwise quite different, and obviously don't share the same ISA. I also don't know if IBM has kept this kind of sharing between POWER & Z. [0] https://en.wikipedia.org/wiki/IBM_z10 https://en.wikipedia.org/wiki/IBM_z10
BugheadTorpeda6 1y ago
For applications or middlewares and systems and utilities? For applications, COBOL is king, closely followed by Java for stuff that needs web interfaces. For middleware and systems and utilities etc, assembly, C, C++, REXX, Shell, and probably there is still some PL/X going on too but I'm not sure. You'd have to ask somebody working on the products (like Db2) that famously used PL/X. I'm pretty sure a public compiler was never released for PL/X so only IBM and possibly Broadcom have access to use it. COBOL is best thought of as a domain specific language. It's great at what it does, but the use cases are limited you would be crazy to write an OS in it.
fneddy 1y ago
There is a thing called LinuxONE. That’s Linux for IBM mainframes. So basically you can run anything that runs on Linux (and can be compiled on s390x) on a mainframe.
- fneddy 1y ago
  And if you are really interested. There is the LinuxONE community cloud by the marist college. If you do open source and want to add support for mainframe / s390x you can get a free tir from them.

rbanffy 1y ago

There's also lots of Java as well, and IBM is making a big effort on porting existing Unix utilities to z/OS (which is a certified UNIX). With Linux, the choices are the same as with other hardware platforms. I assume you'll find lots of Java and Python running on LinuxONE machines. Running Linux, from a user's perspective, it feels just like a normal server with a fast CPU and extremely fast IO.

jiggawatts 1y ago
> extremely fast IO. I wonder how big a competitive edge that will remain in an era where ordinary cloud VMs can do 10 GB/s to zone-redundant remote storage.
- inkyoto 1y ago
  Guaranteed sustained write throughput is a distinguished feature of the mainframe storage. Whilst cloud platforms are the new mainframe (so to speak), and they have all made great strides in improving the SLA guarantees, storage is still accessed over the network (plus extra moving parts – coordination, consistency etc). They will get there, though.
- Cthulhu_ 1y ago
  GB/s is one metric, but IOPS and latency are others that I'm assuming are Very Important for the applications that mainframes are being used for today.
  - imtringued 1y ago
    IOPS is the most meaningless metric there is. It's just a crappy way of saying bandwidth with an implied sector size. 99% of software developers do not use any form of async file IO and therefore couldn't care less. The async file IO support in postgres has been released a month ago. It's that niche of a thing that even extremely mature software that could heavily benefit from it hasn't bothered implementing it until last month.
    - jiggawatts 1y ago
      Microsoft SQL Server has been using async scatter/gather IO APIs for decades. Most database engines I've worked with do so. Postgres is weirdly popular despite being way, way behind on foundational technology adoption.
      - rbanffy 1y ago
        > Microsoft SQL Server has been using async scatter/gather IO APIs for decades. Most database engines I've worked with do so. Windows NT has asynchronous IO since its VAX days ;-) > Postgres is weirdly popular despite being way, way behind on foundational technology adoption. It's good enough, free, and performs well.
        jiggawatts 1y ago
        I constantly hear about VACUUM problems and write amplification causing performance issues bad enough that huge users of it were forced to switch to MySQL instead.
        pgaddict 1y ago
        I've been involved in a couple of those cases, where a large company ran into an issue, and chose to solve it by migrating to something else. And while the issues certainly exist (and are being addressed), the technical reasons often turned out to be a rather tiny part of the story. And in the end it was really about internal politics and incentives. In several such cases, the company was repeatedly warned about how they implemented some functionalities, and that it will cause severe issues with bloat/vacuuming, etc. Along with suggestions how to modify the application to not hit those issues. Their 10x engineers chose to completely ignore that advice, because in their minds they constructed an "ideal database" and concluded that anything that behaves differently is "wrong" and it's not their application that should change. Add a dose of politics where a new CTO wants to rebuild everything from scratch, engineers with NIH syndrome, etc. It's about incentives - if you migrate to a new system, you can write flashy blog posts how the new system is great and saved everything. You can always argue the original system would be worse, because everyone saw it had issues - you just leave out the details about choosing not to address the issues. The engineering team is unlikely to argue against that, because that'd be against their interests too. I'm absolutely not claiming the problems do not exist. They certainly do. Nor am I claiming Postgres is the ideal database for every possible workload. It certainly is not. But the worst examples that I've seen were due to deliberate choices, driven by politics. But that's not described anywhere. In public everyone pretends it's just about the tech.
- RetroTechie 1y ago
  On-site. Speed is not the only reason why some org/business would have Big Iron in their closet.
- FuriouslyAdrift 1y ago
  Latency is much more important than thoughput...
jandrewrogers 1y ago
How fast is “extremely fast”? Normal x86 Linux servers drive multiple 100s of GB/s of I/O these days. Storage is only slow because cloud.
- rbanffy 1y ago
  I never benchmarked it, but the latency feels very low. Mainframes don't have any local storage, so anything it's using will be a box on a separate rack (or spanning multiple racks).

bob1029 1y ago

You can do a lot of damage with some stored procedures. SQL/DB2 capabilities often go overlooked in favor of virtualizing a bunch of Java apps that accomplish effectively the same thing with 100x the resource use.

exabrial 1y ago
Hah, anecdote incoming, but 100x times a resource usage is probably accurate. Given, 100x of a human hair is still just a minuscule grain of sand, but that’s the scale margins Mainframe operators work in. As one grey beard said it to me: Java is loosely typed and dynamic compared to colbol/db2/pl-sql. He was particularly annoyed that the smallest numerical type a ‘byte’ in Java was quote: “A waste of bits” and that Java was full of “useless bounds checking” both of which were causing “performance regressions”. The way mainframe programs are written is: the entire thing is statically typed.
- PaulHoule 1y ago
  I knew mainframe programmers were writing a lot of assembly in the 1980s and they probably still are.
  - BugheadTorpeda6 1y ago
    It's one of the last platforms that people still write a lot of hand written assembly for. Part of this is down to the assembler being very ergonomic and there being a very capable macro system available with macros provided for most system services. Part of it is due to the OS predating C becoming popular, so there are no headers files (just assembler macros) for many older system services (you can thunk them into C compatible calls, but it's sometimes more of a headache than just writing in assembler). Definitely C is becoming more popular lately on the platform, but you will still find a lot of people programming in assembler for a living in 2025. Its probably the only subfield of programming that uses handwritten assembly in that way outside of embedded systems.
- thechao 1y ago
  When I was being taught assembly at Intel, one of the graybeards told me that the greatest waste of an integer was to use it for a "bare" add, when it was a perfectly acceptable 64-wide vector AND. To belabor the the point: he used ADD for the "unusual set of XORs, ANDs, and other funky operations it provided across lanes". Odd dude.

pjmlp 1y ago

RPG, COBOL, PL/I, NEWP are the most used ones. Unisys also has their own Pascal dialect. Other than that, there are Java, C, C++ implementations for mainframes, for a while IBM even had a JVM implementation for IBM i (AS/400), that would translate JVM bytecodes into IBM i ones. Additionally all of them have POSIX environments, think WSL like but for mainframes, here anything that goes into AIX, or a few selected enterprise distros like Red-Hat and SuSE.

BugheadTorpeda6 1y ago
It sounds like you are referring to AS/400 and successors (common mistake, no biggie) rather than the mainframes being referred to here that are successors of System 360 and use the Telum chips (as far as I am aware they have never been based on POWER, like IBM i and AIX and the rest of the AS/400 heritage). RPG was never a big thing on mainframes for instance. I've never come across it in about 10 years of working on them professionally. Same with NEWP, I've never heard of it. And Java is pretty important on the platform these days and not an attempt from the past. It's been pushed pretty hard for at least 20 years and is kept well up to date with newer Java standards. Additionally, the Unix on z/OS is not like WSL. There is no virtualization. The POSIX APIs are implemented as privileged system services with Program Calls (kind of like supervisor calls/system calls). It's more akin to a "flavor" kinda like old school Windows and OS/2 than the modern WSL. You can interface with the system in the old school MVS flavor and use those APIs, or use the POSIX APIs, and they are meant to work together (for instance, the TCPIP stack and web servers on the platform are implemented with the POSIX APIs, for obvious compatibility and porting reasons). Of course, you can run Linux on mainframes and that is big too, but usually when people refer to mainframe Unix they are talking about how z/OS is technically a Unix, which I don't think it would count in the same way if it was just running a Unix environment under a virtualization layer. Windows can do that and it's not a Unix.
- sillywalk 1y ago
  Nitpick: Almost 20 years ago IBM had the eclipz project to share technology between its POWER (System i and System P) and Mainframe (System Z) servers. I'm not sure if counts as "based on", but "the z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style."[0] The chips were otherwise quite different, and obviously don't share the same ISA. I also don't know if IBM has kept this kind of sharing between POWER & Z. [0] https://en.wikipedia.org/wiki/IBM_z10 https://en.wikipedia.org/wiki/IBM_z10

BugheadTorpeda6 1y ago

For applications or middlewares and systems and utilities? For applications, COBOL is king, closely followed by Java for stuff that needs web interfaces. For middleware and systems and utilities etc, assembly, C, C++, REXX, Shell, and probably there is still some PL/X going on too but I'm not sure. You'd have to ask somebody working on the products (like Db2) that famously used PL/X. I'm pretty sure a public compiler was never released for PL/X so only IBM and possibly Broadcom have access to use it. COBOL is best thought of as a domain specific language. It's great at what it does, but the use cases are limited you would be crazy to write an OS in it.

fneddy 1y ago

There is a thing called LinuxONE. That’s Linux for IBM mainframes. So basically you can run anything that runs on Linux (and can be compiled on s390x) on a mainframe.

fneddy 1y ago
And if you are really interested. There is the LinuxONE community cloud by the marist college. If you do open source and want to add support for mainframe / s390x you can get a free tir from them.