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.
Running Linux, from a user's perspective, it feels just like a normal server with a fast CPU and 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.
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.
Postgres is weirdly popular despite being way, way behind on foundational technology adoption.
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.
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.
When you design a system around a database, it pays off to design your ways of mitigating performance issues you might face in the future. Often, a simple document explaining directions to evolve the system into based on the perceived cause. You might want to add extra read replicas, introduce degraded modes for when writes aren't available, moving some functions to their own databases, sharing big tables, and so on. With a somewhat clear roadmap, your successors don't need to panic when the next crisis appears.
For extra points, leave recordings dressed as Hari Seldon.
Speed is not the only reason why some org/business would have Big Iron in their closet.
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.
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.
sounds like "don't try to out-optimize the compiler."
In the 90s, a cryptography paper was published that more quickly brute forced DES (standard encryption algorithm back then) using SIMD across 64-bit registers on a DEC Alpha.
There is also the 80s Connection Machine which was a 1-bit SIMD x 4096-lane supercomputer.
---------------
It sounds like this guy read a few 80s or 90s papers and then got stuck in that unusual style of programming. But there were famous programs back then that worked off of 1-bit SIMD x 64 lanes or x4096 lanes.
By the 00s, computers have already moved on to new patterns (and this obscure methodology was never mainstream). Still, I can imagine that if a student read a specific set of papers in those decades... This kind of mindset would get stuck.
Not always, but they do have excellent performance analysis and will do what they can to avoid slow code in the hottest paths.
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.
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.
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.
Also, I'm sure there are many little POWER-like cores inside a z17 doing things like pushing data around. A major disappointment is that the hardware management elements are x86 machines, probably the only x86 machines IBM still sells.
> What languages are people still writing mainframe code in?
so I naturally answered with the ones I know about.
> RPG was never a big thing on mainframes for instance.
It certainly was in Portugal, back in its heyday.
> Same with NEWP, I've never heard of it.
Systems programming language for Burroughs B5000, evolution from ESPOL its original one, nowadays sold a Unisys MCP.
> 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.
The attempt from the past was converting JVM bytecodes to TIMI on the fly, this approach was dropped in favour of the regular JIT.
For the rest regarding "like WSL", I was trying to simplify, not giving an conference talk on UNIX support across micro and mainframes, and its evolution.