16 ms·

The IBM mainframe: How it runs and why it survives

251 points by rbc 3y ago

Tomte 3y ago
IBM teaches you to use and program those: https://www.ibm.com/z/resources/zxplore https://www.ibm.com/z/resources/zxplore
tyingq 3y ago
If you zoom out, the ecosystem is very comparable to running on AWS or similar. It's an opinionated environment with proprietary answers for how to do things like scheduling, short-lived tasks, long-lived tasks, storage allocation, networks, monitoring, forced version upgrades, etc.
- jmartrican 3y ago
  I wonder if IBM can offer a mainframe in the cloud. Its everything a mainframe provides but all off-site and priced for my size.
  - pjmlp 3y ago
    It is already available, https://www.ibm.com/products/z-and-cloud-modernization-stack https://www.ibm.com/products/z-and-cloud-modernization-stack
  - ghaff 3y ago
    You mean timesharing? :-) I suspect that for most organizations that use mainframes today, there are so many integration points and so much data is involved that the economics that drove a lot of early-on timesharing no longer apply.
  - p_l 3y ago
    It's one of the major ways to get a mainframe these days, even companies you'd expect to have one on premises might actually have a lease on one running in IBM datacenter with VPN to internal network.
CraigJPerry 3y ago
The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the worlds most comprehensive application development framework. Going back to the hardware that everyone likes to focus on, it's less radically different from normal servers today than it was historically. The mainframe today is a 19 inch rack like any other. By that i mean it is not only a 19 inch rack like your x64/ARM servers are but also the same power density (32 or 64 amp racks), cooling requirements etc. The most interesting bit is the software, not the hardware. There are cool hardware aspects too - but focus on them and you miss the real reason these things are popular in certain environments.
- xahhkakappy11 3y ago
  Inline SQL is something I've always missed elsewhere. Not sure it's viable when you've got a billion different incompatible databases supported on a platform, so some of the limitations of mainframes have advantages.
  - colonwqbang 3y ago
    Check out C# LINQ, or Haskell postgresql-typed. https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/introduction-to-linq-queries https://learn.microsoft.com/en-us/dotnet/csharp/programming-... https://hackage.haskell.org/package/postgresql-typed-0.6.2.4/docs/Database-PostgreSQL-Typed.html#g:5 https://hackage.haskell.org/package/postgresql-typed-0.6.2.4...
    - leprechaun1066 3y ago
      Or q: https://code.kx.com/q4m3/9_Queries_q-sql/#93-the-select-template https://code.kx.com/q4m3/9_Queries_q-sql/#93-the-select-temp...
    - toyg 3y ago
rob74 3y ago
> Mainframes descended directly from the technology of the first computers in the 1950s. Instead of being streamlined into low-cost desktop or server use, though, they evolved to handle massive data workloads. I think the first sentence is 100% correct, but the second one not so much: current desktops and servers (not to mention laptops, tablets, smartphones etc. etc.) evolved from the first microcomputers introduced in the 1970s with the idea of having a computer (albeit initially a not very capable one) that anyone could afford. These then quickly evolved during the 1980s and 1990s to cover most of the applications for which you would have needed a mainframe a few years earlier.
- dralley 3y ago
  It's still somewhat true. Desktop CPUs have hardware acceleration for things like video decoding, mainframes have hardware acceleration for things like encryption / decryption, compression / decompression, fixed-decimal arithmetic, etc.
  - peterfirefly 3y ago
    Plenty of x86 CPUs have had crypto instructions in the last decade or so. https://en.wikipedia.org/wiki/AES_instruction_set https://en.wikipedia.org/wiki/AES_instruction_set https://en.wikipedia.org/wiki/Intel_SHA_extensions https://en.wikipedia.org/wiki/Intel_SHA_extensions
- hinkley 3y ago
  Centralization versus distribution. Each person has a box in which they are essentially the sole tenant, versus a big box that has to have a bunch of sophistication to handle multitenancy.
shrubble 3y ago
The only thing not mentioned are the co-processors that handle a lot of ancillary tasks and thus keep the main CPUs free for more work. For instance, printing a report might require just 1 interrupt per page, the rest being handled by the printing controller. The TN3270 terminals talk to a separate communications controller before being passed to the cpu, and the disks used to be able to return results in a sorted order, not sure what they do now...
kkielhofner 3y ago
"They’re designed to process large amounts of critical data while maintaining a 99.999 percent uptime—that’s three seconds of outage per year." Very wrong. Five nines is five minutes and 13 seconds of cumulative downtime in a year[0]. Three seconds of downtime in a year is seven nines[1]. [0] - https://uptime.is/five-nines https://uptime.is/five-nines [1] - https://uptime.is/99.99999 https://uptime.is/99.99999
- coleca 3y ago
  I've always heard that as "scheduled uptime" or "unscheduled outages". When I worked in a mainframe shop, they used to IPL (reboot) the mainframe every Sunday morning. That down time was never considered as part of the SLA.
  - kmoser 3y ago
    Wow, even Windows boxes can run longer than a week without having to be rebooted. I figured a mainframe would be able to last almost indefinitely.
    - nikau 3y ago
      weekly reboots force the business to build their processes around the system being offline at the same time each week. That way you don't have to try and organize downtime if maintenance is required, you know every sunday morning is available when needed.
      - kmoser 3y ago
        Not disagreeing, just commenting that I would have assumed that taking the entire system offline for a reboot on a weekly basis would be untenable from a business perspective. It seems at odds with the concept of all the redundancy built into mainframes to ensure high availability and uptimes. Given that many mainframe-based systems (e.g. airline reservations) generally need to be available 24/7/365, I would have assumed that while one part of the system is being rebooted, others are still available so the overall application can continue to run uninterrupted.
mousetree 3y ago
> Today, IBM is the only mainframe manufacturer AFAIK Fujitsu still manufacture mainframes
- dralley 3y ago
  Oxide could probably be considered a "modern mainframe" if you squint. The architecture is of course much different, but server CPUs from the likes of AMD are gradually catching up with the purpose-built stuff in raw power and I/O capabilities.
  - zozbot234 3y ago
    Oxide hardware is more comparable to a midrange computer. Though they are apparently planning to add support for having multiple physical racks in a single managed "silo", which enables HA scenarios and gets a bit closer to what mainframes provide.
    - hindsightbias 3y ago
      There's an article where their pitch was "It's the new AS/400" Or, you could just buy a new AS/400 that already does all that.
    - msh 3y ago
      I think its only IBM people who calls computers midrange ;)
  - steveklabnik 3y ago
    Yes, like many kinds of comparisons, it really depends on what you mean by the thing. The architecture of Oxide is very different than a mainframe, but the "big computer that's a fully integrated system" vibe is kinda similar.
- timbit42 3y ago
  Also HP NonStop (Tandem).
- 3y ago
brianzelip 3y ago
Here’s a recent-ish Changelog podcast with one of the few professors who teaches about IBM mainframes and COBOL and is part of the Open Mainframe Project, https://changelog.com/podcast/524 https://changelog.com/podcast/524
NelsonMinar 3y ago
My partner does very technical systems hacking on z/OS. They have a huge problem hiring new programmers. His colleagues are all well over 65 and are inevitably retiring (or worse). It seems like a real problem for the future of the platform.
- Melatonic 3y ago
  Lot of people in Taiwan are learning COBOL and mainframe programming specifically for this reason. Surprisingly big (or small, depending on how you look at it) popular of young people learning it.
  - pjmlp 3y ago
    Big offshoring companies like TCS went big with the Y2K bug correction, and handling COBOL development. Sometimes that is how one goes big, by taking care of stuff no one is interested into doing, and when there is enough money in the bank, go after everything else.
lizknope 3y ago
I've never used or even seen a mainframe in 26 years in the tech industry. My brother in law works for a bank and basically the business runs on it. The hardware and software are certainly impressive but does anyone use a mainframe for a new project and not just upgrading or expanding an existing system? I'm in integrated circuit design and we have compute clusters with thousands of CPUs. For some jobs we use a single machine with 128 CPUs and over 2TB RAM. Some steps get split over 30 machines in parallel. All of this EDA / chip design software migrated from Sun and HP workstations in the 1980's and 90's to Linux x86 in the 2000's. I think some of it ran on mainframes in the 70's but does anyone use mainframes for scientific style calculations or is it just financial transaction / database kind of stuff?
- Hikikomori 3y ago
  You'll most likely find it in large companies that operated in the 60s or 70s that haven't switched to anything new, mostly because their core business runs on it. I know of two companies, and at least one still use it, had several summer jobs there. They make sheet metal rolls by flattening out train cart sized hunks of steel, and while the mainframe system didn't run the machines (operators and PLC handled that) it kept track of everything, inventory, logistics and planning. I used it to plan rail shipments, where to put each roll of sheet metal on a train and loaded them up.
  - pdw 3y ago
    That could have been a mainframe, but I think factories are much more likely to be using AS/400 aka IBM i. That runs on regular IBM Power servers these days.
    - avgDev 3y ago
      Can confirm. Work for a midsize manufacturer. Core of the business is on AS/400 and DB2. Although a lot of new development is happening in C#/SQL/.NET and BLAZOR.
  - tristor 3y ago
    Oh, fun times. I've been on the other side of that business in my past life, where I had to "revive" a business critical program written in VB3 (yes for Windows 3.x) after a computer migration that was used to calculate the weight of an aluminum or steel coil/roll via its dimensions so it could be input into the PLC for the feeder mechanism at the beginning of a production line that did forming/extruding of metals. So on one end mainframes, on the other ends software written for DOS and Windows 3.x still being used in (at the time the 2010s) to keep critical infrastructure for manufacturing running.
kencausey 3y ago
Have there been any machine learning related deployments on a modern mainframe? Would there be any value in doing so?
madmulita 3y ago
I believe the real reason for its survivability is the fact that you can pull a tape from the seventies and those binaries will run without any modification. It's not only that you can easily recompile your COBOL from the '70s, the binary is still compatible. You've never been pushed to migrate to another technology. Imagine the effort and 'knowledge' included in those evolved programs. The banks don't even know, and are conscious of it, how many laws and regulations they have encoded in there. As someone stated in another comment, the software is the impressive part.
- technofiend 3y ago
  This is both good and bad. You have to consider bugs a kind of feature like anything else. One of my coworkers showed me a bug report he'd opened 30 years prior that IBM still refused to fix because people depended on the broken behavior. So porting off the mainframe also means bringing along those quirks or rewriting to specs that provably don't regress performance and behavior. Writing or rewriting software is easy, but migrations despite how they first appear are not really "green field" development.
lasermike026 3y ago
"A bank’s lifeblood isn't money—it’s data." Yeah, tell that to a failed bank.
rawgabbit 3y ago
I worked on a mainframe for a major airline over 20 years ago. I always found it amusing that Sabre detailed my programs/jobs to cost the airline almost 7 figures a year; I never knew if that was real dollars or price to be negotiated down. Most of my programs was to repackage yesterday's flights and passenger data into CSV files so an external program can pick them up and ETL into a data warehouse. At the time, there was no utility like ODBC. I had to use JCL and SAS and my own created utilities. I even had to write a utility to output to CSV (there was none offered out of the box by IBM or SAS).
stuff4ben 3y ago
I ran Internet banking for a small bank in the early 2000's. We had our IBM mainframe right next to a bunch of HP/UX servers. It was just massive and had a nice red button which they warned all of us to stay clear from. I recall that was around the time running Linux on the mainframe was becoming a thing and we tried to run Websphere and our J2EE app on it. It was not successful (too slow) and we kept running on HP/UX.
grishka 3y ago
> Communication is through Kafka events or Java Messaging Services, and new server instances can be spun up in seconds in AWS or Azure clouds to provide additional capacity, which is needed for high-volume processing. I'm honestly surprised that a bank would agree to run anything even remotely serious on someone else's infrastructure.
- FreezingKeeper 3y ago
  Some examples: https://aws.amazon.com/solutions/case-studies/monzo/ https://aws.amazon.com/solutions/case-studies/monzo/ https://www.avaloq.com/solutions/products/avaloq-core https://www.avaloq.com/solutions/products/avaloq-core
- elric 3y ago
  Many banks, including very large ones, already have some amount of stuff running on public (& private) cloud infrastructure. Many other banks are preparing migrations. I, too, was surprised by this, considering only a few years ago they were very reluctant to even buy software from anyone who wasn't on a very short whitelist. In the end, I guess it's all about the money ... and that includes the money it takes to find and train mainframe devs. Source: spent a significant part of my career in fintech.
- wkat4242 3y ago
  Me too. We sold a lot of dedicated fiber to banks in the early 2000s because they feared the packet switched nature of ATM. They thought packets would randomly end up at competitors. I don't know if they ever realized even dedicated fiber links were software switched by that time so it was easy to misclick and send an entire fiber stream to their competitor too :)
filereaper 3y ago
The mainframe exists because IBM and the devs respect the time and investments made by its customers. There are efforts made to make sure code doesn't break and migrations are put in place. Sadly only Microsoft and a few others share this attitude, and its likely why these companies and their products will be around forever.
- CaliforniaKarl 3y ago
  > Sadly only Microsoft and a few others share this attitude… Since the introduction of Windows 10, this is no longer true. For example, games that supported Microsoft's "Games for Windows – Live" often do not not work out of the box anymore, as required DLLs are no longer installed. And on the 2017 Microsoft Answers thread about what to do to work around this[0], users are reporting the steps no longer work. [0]: https://answers.microsoft.com/en-us/windows/forum/all/guide-games-for-windows-live-gfwl-steam-windows-10/c2a916de-ac00-485d-bc63-f77a385ef7f6 https://answers.microsoft.com/en-us/windows/forum/all/guide-...
larrik 3y ago
I never worked on z/OS, but I did work on AS400 (Series I, or whatever it's called now). I think the main things missing is how much IBM really brings to the table here. > If one crashes or has to go down for maintenance, the other partitions are unaffected. Effectively, IBM often does that for you. The machine detects an issue, and calls IBM, who sends someone out (in my day it was immediately), and they fix it. Then it's fixed and they leave and most of your staff has no idea they were there at all. Plus, there's not enough that can be said about using a dedicated stack of hardware and software owned by one company. If there's an issue, it's IBM's. They are the ones who need to fix it. No trying to get HP vs Microsoft to agree to take the blame (which can take literal weeks). Just call IBM, and they take care of it. (In theory)
- mxuribe 3y ago
  Throughout my career, the term i heard most often for this type of scenario was: "Which neck to choke when stuff fails...", or something like "...the least number of necks to choke when stuff fails...", etc. lol :-D
- hinkley 3y ago
  Oxide seems to be trying to build a similar arrangement with customers. That's half their motivation for switching to open firmware for the little computers hidden in your machine. There's a big game of fingerpointing these days where you call your vendor and they blame one of their vendors and can't/won't hunt down the issue for you. The ways I've heard that explained sound exhausting. Paying anyone who you can say, "your machine broke come fix it" and they actually do, is probably worth the money. Right now Cloud providers and IBM are the only ones really providing that service. I suspect history will say that people were not running to the Cloud so much as running away from bullshit hardware vendors.
  - Melatonic 3y ago
    Not always true - there are lots of hardware vendors that do have pretty decent support and automatically call home and a part is same day shipped. That being said usually I am the one replacing that part on my own infrastructure which is usually a 30 minute drive an hour to maybe 3 of my time
Scubabear68 3y ago
One of the reasons Mainframes continue to be used is depreciation. I know a few companies who love their mainframes because they are fully paid for and from a budget perspective they are seen as “free”. This can be very attractive compared to the never ending OpEx for running cloud computing.
- neverartful 3y ago
  Doesn't make sense to me. I believe that IBM has found the forced upgrade path for hardware/software like Apple has perfected. You may not be able to run old versions of IBM's software and still have it be supported by them. Same for the hardware. I don't think you would commonly find and old mainframe (the hardware) in operation. At the last place I worked that had mainframes, they would upgrade to new models every 2-3 years.
  - Scubabear68 3y ago
    I call BS on this. I never heard of upgrading mainframes every 2-3 years. It makes no sense. Mainframes are huge investments meant to last a long time, it is not a PC you replace in a few years.
    - neverartful 3y ago
      Call BS all you want, I don't care. I know what I witnessed. I don't know if the mainframes were owned are leased, but they were swapped out for new ones every few years.
      - Scubabear68 3y ago
        I’d like to hear more then. Mainframes are traditionally a big investment where you consolidate tons of load and jobs and LPARs onto one honking big machine. A very expandable machine in terms of any resource you can think of. Why would you turn over something like that every few years? Your narrative sounds more like taking about ephemeral cloud stuff, not multi million dollar main frames.
AlbertCory 3y ago
Believe it or not: I never worked on an IBM mainframe, except in college. It always seemed like the prejudices against it meant that, once you get into that world, you can't get out. That said: what the business types like is the belief, whether it's true or not, that when you call IBM for service they're there before you hang up the phone. Also, a long time ago at Oracle, I sat in probably the most boring meeting of my life: a group called MOSES, composed of sysadmins for Unix. Their complaint was that, supposedly, all mainframe sysadmins did things the exact same way, so if you hired a new one, there was no training. Whereas in Unix, everyone did things differently, so a new hire couldn't be productive right away.
Solvency 3y ago
Listen to this episode "Mainframes are still a big thing" — https://changelog.com/podcast/524 https://changelog.com/podcast/524. tldr: This awesome professor has an amazing track record of getting seemingly "average joes" trained up for mainframe programming. Because of how uncool this process is perceived by the average SV developer, it's literally shunted off into the dark recesses of the world, despite it being an awesome jobs platform.
sedawk 3y ago
Thank you for sharing, it was an excellent read!
StillBored 3y ago
"Today’s IBM mainframe CPUs are based on a highly evolved version of the POWER architecture that IBM has been developing for over 30 years. " I've heard a lot of largely clueless people who weren't aware of the differences between the zeries and pseries say something like this, but its generally been entirely false (especially 15-30 years ago which overlaps with some time I myself spent at IBM). Given the rest of the article I wouldn't presume the author is in this category. So has something changed? or is the implication stretching the truth? I mean I guess you could strip a POWER core down so it only runs s390 microcode/etc, but that likely won't actually yield a performant machine and the process of evolving it would likely fundamentally change the microarch of whatever RISCish core they started with. I mean they are entirely different Arches, in the past utilizing entirely different microarches. I can see some sharing of a RTL for maybe a vector unit, or cache structure, or a group doing layout, but that doesn't make the zeries processors any more derivative of POWER than Itanium was derivative of x86, etc. PS: the bit about zos partitions supporting linux seems like a bit of confusion too, earlier its correct about the LPARs being capable of running linux directly, but ZOS isn't providing the lpar functionality, and is generally just another guest alongside linux, ztpf, and various other more esoteric "OSs" that can run natively. There is a unix system services in zos but that isn't a linux kernel/etc.
- lizknope 3y ago
  Yeah, I don't know where the author is getting the POWER arch connection. I thought the IBM Z Architecture was the CISC based System 360 / 390 architecture from the 1960's. At least that is what I remember my one friend who has some mainframe experience was telling me.
- sillywalk 3y ago
  I wonder if the article meant that IBM had worked on the POWER architecture for over 30 years? IBM did work on the eCLipz Project [0][1], combining / sharing tech from IBM Power/pseries, AS/400/iseries, and Zseries. This was around 2005-ish. I assume that collaboration has continued, but I don't know if that counts as 'based on ...'. "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, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline. However, the processors are quite dissimilar in other respects, such as cache hierarchy and coherency, SMP topology and protocol, and chip organization. The different ISAs result in very different cores – there are 894 unique z10 instructions, 75% of which are implemented entirely in hardware. The z/Architecture is a CISC architecture, backwards compatible to the IBM System/360 architecture from the 1960s. "[2] For the POWER [0] https://www.realworldtech.com/eclipz/ https://www.realworldtech.com/eclipz/ [1] https://news.ycombinator.com/item?id=18494225 https://news.ycombinator.com/item?id=18494225 [2] https://en.wikipedia.org/wiki/IBM_z10 https://en.wikipedia.org/wiki/IBM_z10
sb-alien 3y ago
I was involved in an IBM mainframe to RS/6000 migration in the mid 1990s for a major aerospace company. We moved the engineering functionality to a client/server system, including many custom programs and CAD/CAM/CAE. Like the article mentioned, migration was a Herculean task done over a period of years, with a good chance it wouldn't succeed. I worked many 70 hour weeks, I had to drive to the factory at 2AM some days to monitor jobs because only certain people had remote access. Floating point and text encoding was different between the systems, decades of legacy engineering and manufacturing data and code (having cost hundreds of millions of dollars to produce) had to be translated and verified. There was a rivalry with the mainframe group who wanted it to see it fail, reluctant programmers, engineers, and line workers. On and on and on...we had to apply start-up levels of creativity and ingenuity while working in an MegaAeroCorp bureaucratic atmosphere. Ultimately, the project was a success, although the system soon moved to PC-based desktops as graphics cards became more powerful. I got a company award from my internal engineering customers. Shortly after the dust settled, I got called into a secretive meeting with my boss and the department head, expecting a promotion and a raise, or at least an "Attaboy!" No, I was reprimanded by an HR rep with a formal note in my records about my attitude ("You risked everything by cowboying!"). I was admonished for having the gall to take a couple of sick days during the ordeal (my coworkers were concerned when they found me passed out at my workstation, my boss warned me after my time-off "If you are sick be sick" and called me a filthy name.) I was put on double secret probation. Our whole department was eventually outsourced, and I ended my tenure there by being escorted by security to the door and told not to let it hit me in the backside. I guess I should have joined the mainframe group on the business side, in retrospect, they are still around grinding out profit statements. It was a challenge to get rid of a mainframe, maybe more so than eliminating our entire engineering support team.
- sb-alien 3y ago
  After the migration, when they were "decomissioning" the mainframe itself, the company photographer took a picture of the migration team gathered around the mainframe. It was unplugged, being gutted, with copper pipes sticking out. Years later, looking at a print, it reminded me of the old pictures of a whaling crew gathered around a whale carcass--don't get me wrong, whales are much more valuable and important. It does seem like we helped destroy something we really didn't completely understand the value of.
denton-scratch 3y ago
Back in the early 80s, I visited the Police National Computer Unit at Hendon in North London. The computer room was the size of a football pitch. Most of the floor was covered with washing-machine-sized disk-pack drives, along with quite a lot of dedicated IO processors (also washing-machine-sized). The walls were lined with storage for offline disk-packs. This system was a triple Burroughs B7800. What distinguished mainframes from minicomputers back then wasn't their awesome processing power, or their resilience; it was their huge IO capacity. They could handle hundreds of storage devices, and hundreds of thousands of terminals. At least, that's how I was told it; I never worked on mainframes. Nowadays a single connection to the internet can connect you to a similar number of "terminals", and storage is also accessed over a network. So the advantages touted by the author are quite different from what they used to be; IO nowadays isn't the issue it was back then.
myth2018 3y ago
It may be my mileage.. But I frequently hear about the shortage of mainframe professionals and, some years ago, I seriously considered getting into it. However, after some attempts to find training on topics I typically see in job postings (CICS, JCL etc), I gave up after finding no courses also providing access to a mainframe "account" for practicing. Maybe I didn't search it properly. I've been advised to try an entry-level position in a company hiring juniors, since they usually provide the training during the first months. But, after over 20 years as an engineer, that felt bigger a step back than what I was willing to take. I still feel interested though. I'm aware of the current state of chaos on mainframe development, but honestly, I don't think that the current web/mobile situation is much better and, besides, I personally hate them really bad.
dreamcompiler 3y ago
Early in my career I worked on IBM mainframes and wrote JCL for them. Let's say someone knocked on my door tomorrow and said "We're looking for someone with any experience at all with JCL on IBM mainframes. We'll pay a million dollars a year for a 10-year guaranteed contract. Are you that guy?" I would say "Nope. Sorry. I'm a plumber. I don't know nuthin' about computers." (And then they would say "Ha! GOTCHA! How'd you know we were talking about computers? Now take your million-dollar check and watch your head as you get into this nice black helicopter.")
eGuidezhan 3y ago
[dead]
mikewarot 3y ago
Absolute fringe opinion(or is it?): The performance and reliability are awesome, but have nothing to do with the real reasons IBM mainframes are still around. Backward compatibility helps - you can still run code for the IBM 1401 on these machines if you need to. When they came up with System 360, they effectively crystalized software development... taking what used to be a forced march to new hardware every few years as you got a new, faster, incompatible machine, and were rewriting the code for the better faster hardware.... and just FROZE that stream of development, which is why Y2K really happened. But even that's not the real reason IBM mainframes have stuck around so long... it's the same reason Virtualization and Containers took off.... they give no default access to files or disks, the administrator has to plan out which disks and other resources a Job, (or Runtime, VM, or container) will access. (Example, the DD statement of JCL[1]) This has the effect of being a very course grained capability object system.[2] The default access to everything on a Windows/Unix/Linux system just doesn't work in the modern era. It is because side effects can be strictly controlled, that Mainframes and later VMs and Containers have so much value. -- a small rant: It's 2023... consider the humble AC wall outlet, you can plug almost anything into it, and the circuit breaker or fuse will prevent bad things from happening to your wiring, house, etc. Why can't we protect against a rogue device plugged into a USB port? Why can't we just run any program we please, like we can plug in a lamp we bought at a garage sale, without risking everything? -- [1] https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-jcl-statements-what-does-dd-statement-do https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-... [2] https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
graycat 3y ago
Ah, good to hear that the IBM mainframes are still around, are more powerful, and that the software for the old IBM mainframes will still run on the new mainframes. So, yup, JCL still works! An 3270 series video terminals with 24 lines of 80 characters each driven with CICS (customer information control system or some such) is still used. But I didn't see that (1) Rexx, often a good replacement for JCL, (2) XEDIT, and the PC version KEDIT, my favorite text editor, (3) and VM/370, an impressive virtual machine supervisor, upgraded from the original CP/67 for the IBM 360/67 mainframe are still supported and used. I would be shocked if they were not still supported and also still used, especially for development and analytical computing tasks.
- neverartful 3y ago
  The latest incarnation of VM/370 is branded z/VM. Most of my hands-on mainframe work was with VM/CMS and I enjoyed using it.
  - graycat 3y ago
    For the software to schedule the fleet at FedEx, I wrote in PL/I on CP/67 (control program, i.e., virtual machine, for the IBM 360/67, with virtual memory) CMS (conversational monitor system, the user interface) on a 360/67 at National CSS time-sharing in Stamford, CT. Right, VM/370 was from CP/67! I wrote the code from my living room while teaching computer science at Georgetown U. Then in Memphis, one evening used the code to develop a schedule for all planned 33 airplanes for all planned 90 US cities. The next day two representatives of BoD member and crucial investor General Dynamics went over the schedule carefully and announced to the BoD that "it is a little tight in a few places but it's flyable". Until that schedule, due to concerns of some BoD members, scheduling had been a show stopper. But with the schedule the BoD was pleased, crucial funding, equity and also counting loans on the planes, etc., $55+ million, was enabled, and FedEx was saved until the next such BoD crisis. I solved the next such BoD crisis with the differential equation y'(t) = k y(t) (b - y(t)) and for this one, for the computing for the data to draw a graph of the solution, used my new HP calculator I'd paid $400 for! There the BoD wanted some revenue projections. NCSS was expensive, but I enjoyed using it AND PL/I! It didn't use 3270 communications and, instead, used asynchronous bits on a phone line and a portable terminal with heat sensitive paper in rolls. The terminal was from Execuport and supposed to be portable. Actually, it was delicate! It is just staggering how far computing has come since then! Hardware, operating system software, APIs, user interfaces, communications, YES, but applied math, algorithms, and programming languages, not as much and, thus, seem more fundamental!!!!
elzbardico 3y ago
The problem with most projects of mainframe migration that I've seen is that most of them suffered the bad luck of being started around the 90s and 2000s, a really complicated age in Enterprise Software, the age of COM/DCOM/COM+ and EJB 2.0. Any normal person would prefer to program in S/370 assembly than be forced to use EJB 2.0 Entity Beans.
tracker1 3y ago
I remember in my late teens, working as a temp... literally looking up individual accounts from a "past due" report to make sure they were still past due before they received a call from collections dept. Why, because paying a temp was literally less expensive than re-running the report on the mainframe.
PeterStuer 3y ago
The trick to surviving in Enterprise environments is consistently and credibly beating the longest horizon dtrayegic rate of return budget (luck has it enterprise's stategic horizons are not that long). At any point it is still better to stick with the current than to change. You boil the frog, but very carefully.

251 points by rbc 3y ago

IBM teaches you to use and program those: https://www.ibm.com/z/resources/zxplore https://www.ibm.com/z/resources/zxplore

tyingq 3y ago

If you zoom out, the ecosystem is very comparable to running on AWS or similar. It's an opinionated environment with proprietary answers for how to do things like scheduling, short-lived tasks, long-lived tasks, storage allocation, networks, monitoring, forced version upgrades, etc.

jmartrican 3y ago
I wonder if IBM can offer a mainframe in the cloud. Its everything a mainframe provides but all off-site and priced for my size.
- pjmlp 3y ago
  It is already available, https://www.ibm.com/products/z-and-cloud-modernization-stack https://www.ibm.com/products/z-and-cloud-modernization-stack
- ghaff 3y ago
  You mean timesharing? :-) I suspect that for most organizations that use mainframes today, there are so many integration points and so much data is involved that the economics that drove a lot of early-on timesharing no longer apply.
- p_l 3y ago
  It's one of the major ways to get a mainframe these days, even companies you'd expect to have one on premises might actually have a lease on one running in IBM datacenter with VPN to internal network.

CraigJPerry 3y ago

The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the worlds most comprehensive application development framework. Going back to the hardware that everyone likes to focus on, it's less radically different from normal servers today than it was historically. The mainframe today is a 19 inch rack like any other. By that i mean it is not only a 19 inch rack like your x64/ARM servers are but also the same power density (32 or 64 amp racks), cooling requirements etc. The most interesting bit is the software, not the hardware. There are cool hardware aspects too - but focus on them and you miss the real reason these things are popular in certain environments.

xahhkakappy11 3y ago
Inline SQL is something I've always missed elsewhere. Not sure it's viable when you've got a billion different incompatible databases supported on a platform, so some of the limitations of mainframes have advantages.
- colonwqbang 3y ago
  Check out C# LINQ, or Haskell postgresql-typed. https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/introduction-to-linq-queries https://learn.microsoft.com/en-us/dotnet/csharp/programming-... https://hackage.haskell.org/package/postgresql-typed-0.6.2.4/docs/Database-PostgreSQL-Typed.html#g:5 https://hackage.haskell.org/package/postgresql-typed-0.6.2.4...
  - leprechaun1066 3y ago
    Or q: https://code.kx.com/q4m3/9_Queries_q-sql/#93-the-select-template https://code.kx.com/q4m3/9_Queries_q-sql/#93-the-select-temp...
  - toyg 3y ago

rob74 3y ago

> Mainframes descended directly from the technology of the first computers in the 1950s. Instead of being streamlined into low-cost desktop or server use, though, they evolved to handle massive data workloads. I think the first sentence is 100% correct, but the second one not so much: current desktops and servers (not to mention laptops, tablets, smartphones etc. etc.) evolved from the first microcomputers introduced in the 1970s with the idea of having a computer (albeit initially a not very capable one) that anyone could afford. These then quickly evolved during the 1980s and 1990s to cover most of the applications for which you would have needed a mainframe a few years earlier.

dralley 3y ago
It's still somewhat true. Desktop CPUs have hardware acceleration for things like video decoding, mainframes have hardware acceleration for things like encryption / decryption, compression / decompression, fixed-decimal arithmetic, etc.
- peterfirefly 3y ago
  Plenty of x86 CPUs have had crypto instructions in the last decade or so. https://en.wikipedia.org/wiki/AES_instruction_set https://en.wikipedia.org/wiki/AES_instruction_set https://en.wikipedia.org/wiki/Intel_SHA_extensions https://en.wikipedia.org/wiki/Intel_SHA_extensions
hinkley 3y ago
Centralization versus distribution. Each person has a box in which they are essentially the sole tenant, versus a big box that has to have a bunch of sophistication to handle multitenancy.

shrubble 3y ago

The only thing not mentioned are the co-processors that handle a lot of ancillary tasks and thus keep the main CPUs free for more work. For instance, printing a report might require just 1 interrupt per page, the rest being handled by the printing controller. The TN3270 terminals talk to a separate communications controller before being passed to the cpu, and the disks used to be able to return results in a sorted order, not sure what they do now...

kkielhofner 3y ago

"They’re designed to process large amounts of critical data while maintaining a 99.999 percent uptime—that’s three seconds of outage per year." Very wrong. Five nines is five minutes and 13 seconds of cumulative downtime in a year[0]. Three seconds of downtime in a year is seven nines[1]. [0] - https://uptime.is/five-nines https://uptime.is/five-nines [1] - https://uptime.is/99.99999 https://uptime.is/99.99999

coleca 3y ago
I've always heard that as "scheduled uptime" or "unscheduled outages". When I worked in a mainframe shop, they used to IPL (reboot) the mainframe every Sunday morning. That down time was never considered as part of the SLA.
- kmoser 3y ago
  Wow, even Windows boxes can run longer than a week without having to be rebooted. I figured a mainframe would be able to last almost indefinitely.
  - nikau 3y ago
    weekly reboots force the business to build their processes around the system being offline at the same time each week. That way you don't have to try and organize downtime if maintenance is required, you know every sunday morning is available when needed.
    - kmoser 3y ago
      Not disagreeing, just commenting that I would have assumed that taking the entire system offline for a reboot on a weekly basis would be untenable from a business perspective. It seems at odds with the concept of all the redundancy built into mainframes to ensure high availability and uptimes. Given that many mainframe-based systems (e.g. airline reservations) generally need to be available 24/7/365, I would have assumed that while one part of the system is being rebooted, others are still available so the overall application can continue to run uninterrupted.

mousetree 3y ago

> Today, IBM is the only mainframe manufacturer AFAIK Fujitsu still manufacture mainframes

dralley 3y ago
Oxide could probably be considered a "modern mainframe" if you squint. The architecture is of course much different, but server CPUs from the likes of AMD are gradually catching up with the purpose-built stuff in raw power and I/O capabilities.
- zozbot234 3y ago
  Oxide hardware is more comparable to a midrange computer. Though they are apparently planning to add support for having multiple physical racks in a single managed "silo", which enables HA scenarios and gets a bit closer to what mainframes provide.
  - hindsightbias 3y ago
    There's an article where their pitch was "It's the new AS/400" Or, you could just buy a new AS/400 that already does all that.
  - msh 3y ago
    I think its only IBM people who calls computers midrange ;)
- steveklabnik 3y ago
  Yes, like many kinds of comparisons, it really depends on what you mean by the thing. The architecture of Oxide is very different than a mainframe, but the "big computer that's a fully integrated system" vibe is kinda similar.
timbit42 3y ago
Also HP NonStop (Tandem).
3y ago

brianzelip 3y ago

Here’s a recent-ish Changelog podcast with one of the few professors who teaches about IBM mainframes and COBOL and is part of the Open Mainframe Project, https://changelog.com/podcast/524 https://changelog.com/podcast/524

NelsonMinar 3y ago

My partner does very technical systems hacking on z/OS. They have a huge problem hiring new programmers. His colleagues are all well over 65 and are inevitably retiring (or worse). It seems like a real problem for the future of the platform.

Melatonic 3y ago
Lot of people in Taiwan are learning COBOL and mainframe programming specifically for this reason. Surprisingly big (or small, depending on how you look at it) popular of young people learning it.
- pjmlp 3y ago
  Big offshoring companies like TCS went big with the Y2K bug correction, and handling COBOL development. Sometimes that is how one goes big, by taking care of stuff no one is interested into doing, and when there is enough money in the bank, go after everything else.

lizknope 3y ago

I've never used or even seen a mainframe in 26 years in the tech industry. My brother in law works for a bank and basically the business runs on it. The hardware and software are certainly impressive but does anyone use a mainframe for a new project and not just upgrading or expanding an existing system? I'm in integrated circuit design and we have compute clusters with thousands of CPUs. For some jobs we use a single machine with 128 CPUs and over 2TB RAM. Some steps get split over 30 machines in parallel. All of this EDA / chip design software migrated from Sun and HP workstations in the 1980's and 90's to Linux x86 in the 2000's. I think some of it ran on mainframes in the 70's but does anyone use mainframes for scientific style calculations or is it just financial transaction / database kind of stuff?

Hikikomori 3y ago
You'll most likely find it in large companies that operated in the 60s or 70s that haven't switched to anything new, mostly because their core business runs on it. I know of two companies, and at least one still use it, had several summer jobs there. They make sheet metal rolls by flattening out train cart sized hunks of steel, and while the mainframe system didn't run the machines (operators and PLC handled that) it kept track of everything, inventory, logistics and planning. I used it to plan rail shipments, where to put each roll of sheet metal on a train and loaded them up.
- pdw 3y ago
  That could have been a mainframe, but I think factories are much more likely to be using AS/400 aka IBM i. That runs on regular IBM Power servers these days.
  - avgDev 3y ago
    Can confirm. Work for a midsize manufacturer. Core of the business is on AS/400 and DB2. Although a lot of new development is happening in C#/SQL/.NET and BLAZOR.
- tristor 3y ago
  Oh, fun times. I've been on the other side of that business in my past life, where I had to "revive" a business critical program written in VB3 (yes for Windows 3.x) after a computer migration that was used to calculate the weight of an aluminum or steel coil/roll via its dimensions so it could be input into the PLC for the feeder mechanism at the beginning of a production line that did forming/extruding of metals. So on one end mainframes, on the other ends software written for DOS and Windows 3.x still being used in (at the time the 2010s) to keep critical infrastructure for manufacturing running.

kencausey 3y ago

Have there been any machine learning related deployments on a modern mainframe? Would there be any value in doing so?

madmulita 3y ago

I believe the real reason for its survivability is the fact that you can pull a tape from the seventies and those binaries will run without any modification. It's not only that you can easily recompile your COBOL from the '70s, the binary is still compatible. You've never been pushed to migrate to another technology. Imagine the effort and 'knowledge' included in those evolved programs. The banks don't even know, and are conscious of it, how many laws and regulations they have encoded in there. As someone stated in another comment, the software is the impressive part.

technofiend 3y ago
This is both good and bad. You have to consider bugs a kind of feature like anything else. One of my coworkers showed me a bug report he'd opened 30 years prior that IBM still refused to fix because people depended on the broken behavior. So porting off the mainframe also means bringing along those quirks or rewriting to specs that provably don't regress performance and behavior. Writing or rewriting software is easy, but migrations despite how they first appear are not really "green field" development.

lasermike026 3y ago

"A bank’s lifeblood isn't money—it’s data." Yeah, tell that to a failed bank.

rawgabbit 3y ago

I worked on a mainframe for a major airline over 20 years ago. I always found it amusing that Sabre detailed my programs/jobs to cost the airline almost 7 figures a year; I never knew if that was real dollars or price to be negotiated down. Most of my programs was to repackage yesterday's flights and passenger data into CSV files so an external program can pick them up and ETL into a data warehouse. At the time, there was no utility like ODBC. I had to use JCL and SAS and my own created utilities. I even had to write a utility to output to CSV (there was none offered out of the box by IBM or SAS).

stuff4ben 3y ago

I ran Internet banking for a small bank in the early 2000's. We had our IBM mainframe right next to a bunch of HP/UX servers. It was just massive and had a nice red button which they warned all of us to stay clear from. I recall that was around the time running Linux on the mainframe was becoming a thing and we tried to run Websphere and our J2EE app on it. It was not successful (too slow) and we kept running on HP/UX.

grishka 3y ago

> Communication is through Kafka events or Java Messaging Services, and new server instances can be spun up in seconds in AWS or Azure clouds to provide additional capacity, which is needed for high-volume processing. I'm honestly surprised that a bank would agree to run anything even remotely serious on someone else's infrastructure.

FreezingKeeper 3y ago
Some examples: https://aws.amazon.com/solutions/case-studies/monzo/ https://aws.amazon.com/solutions/case-studies/monzo/ https://www.avaloq.com/solutions/products/avaloq-core https://www.avaloq.com/solutions/products/avaloq-core
elric 3y ago
Many banks, including very large ones, already have some amount of stuff running on public (& private) cloud infrastructure. Many other banks are preparing migrations. I, too, was surprised by this, considering only a few years ago they were very reluctant to even buy software from anyone who wasn't on a very short whitelist. In the end, I guess it's all about the money ... and that includes the money it takes to find and train mainframe devs. Source: spent a significant part of my career in fintech.
wkat4242 3y ago
Me too. We sold a lot of dedicated fiber to banks in the early 2000s because they feared the packet switched nature of ATM. They thought packets would randomly end up at competitors. I don't know if they ever realized even dedicated fiber links were software switched by that time so it was easy to misclick and send an entire fiber stream to their competitor too :)

filereaper 3y ago

The mainframe exists because IBM and the devs respect the time and investments made by its customers. There are efforts made to make sure code doesn't break and migrations are put in place. Sadly only Microsoft and a few others share this attitude, and its likely why these companies and their products will be around forever.

CaliforniaKarl 3y ago
> Sadly only Microsoft and a few others share this attitude… Since the introduction of Windows 10, this is no longer true. For example, games that supported Microsoft's "Games for Windows – Live" often do not not work out of the box anymore, as required DLLs are no longer installed. And on the 2017 Microsoft Answers thread about what to do to work around this[0], users are reporting the steps no longer work. [0]: https://answers.microsoft.com/en-us/windows/forum/all/guide-games-for-windows-live-gfwl-steam-windows-10/c2a916de-ac00-485d-bc63-f77a385ef7f6 https://answers.microsoft.com/en-us/windows/forum/all/guide-...

larrik 3y ago

I never worked on z/OS, but I did work on AS400 (Series I, or whatever it's called now). I think the main things missing is how much IBM really brings to the table here. > If one crashes or has to go down for maintenance, the other partitions are unaffected. Effectively, IBM often does that for you. The machine detects an issue, and calls IBM, who sends someone out (in my day it was immediately), and they fix it. Then it's fixed and they leave and most of your staff has no idea they were there at all. Plus, there's not enough that can be said about using a dedicated stack of hardware and software owned by one company. If there's an issue, it's IBM's. They are the ones who need to fix it. No trying to get HP vs Microsoft to agree to take the blame (which can take literal weeks). Just call IBM, and they take care of it. (In theory)

mxuribe 3y ago
Throughout my career, the term i heard most often for this type of scenario was: "Which neck to choke when stuff fails...", or something like "...the least number of necks to choke when stuff fails...", etc. lol :-D
hinkley 3y ago
Oxide seems to be trying to build a similar arrangement with customers. That's half their motivation for switching to open firmware for the little computers hidden in your machine. There's a big game of fingerpointing these days where you call your vendor and they blame one of their vendors and can't/won't hunt down the issue for you. The ways I've heard that explained sound exhausting. Paying anyone who you can say, "your machine broke come fix it" and they actually do, is probably worth the money. Right now Cloud providers and IBM are the only ones really providing that service. I suspect history will say that people were not running to the Cloud so much as running away from bullshit hardware vendors.
- Melatonic 3y ago
  Not always true - there are lots of hardware vendors that do have pretty decent support and automatically call home and a part is same day shipped. That being said usually I am the one replacing that part on my own infrastructure which is usually a 30 minute drive an hour to maybe 3 of my time

Scubabear68 3y ago

One of the reasons Mainframes continue to be used is depreciation. I know a few companies who love their mainframes because they are fully paid for and from a budget perspective they are seen as “free”. This can be very attractive compared to the never ending OpEx for running cloud computing.

neverartful 3y ago
Doesn't make sense to me. I believe that IBM has found the forced upgrade path for hardware/software like Apple has perfected. You may not be able to run old versions of IBM's software and still have it be supported by them. Same for the hardware. I don't think you would commonly find and old mainframe (the hardware) in operation. At the last place I worked that had mainframes, they would upgrade to new models every 2-3 years.
- Scubabear68 3y ago
  I call BS on this. I never heard of upgrading mainframes every 2-3 years. It makes no sense. Mainframes are huge investments meant to last a long time, it is not a PC you replace in a few years.
  - neverartful 3y ago
    Call BS all you want, I don't care. I know what I witnessed. I don't know if the mainframes were owned are leased, but they were swapped out for new ones every few years.
    - Scubabear68 3y ago
      I’d like to hear more then. Mainframes are traditionally a big investment where you consolidate tons of load and jobs and LPARs onto one honking big machine. A very expandable machine in terms of any resource you can think of. Why would you turn over something like that every few years? Your narrative sounds more like taking about ephemeral cloud stuff, not multi million dollar main frames.

AlbertCory 3y ago

Believe it or not: I never worked on an IBM mainframe, except in college. It always seemed like the prejudices against it meant that, once you get into that world, you can't get out. That said: what the business types like is the belief, whether it's true or not, that when you call IBM for service they're there before you hang up the phone. Also, a long time ago at Oracle, I sat in probably the most boring meeting of my life: a group called MOSES, composed of sysadmins for Unix. Their complaint was that, supposedly, all mainframe sysadmins did things the exact same way, so if you hired a new one, there was no training. Whereas in Unix, everyone did things differently, so a new hire couldn't be productive right away.

Solvency 3y ago

Listen to this episode "Mainframes are still a big thing" — https://changelog.com/podcast/524 https://changelog.com/podcast/524. tldr: This awesome professor has an amazing track record of getting seemingly "average joes" trained up for mainframe programming. Because of how uncool this process is perceived by the average SV developer, it's literally shunted off into the dark recesses of the world, despite it being an awesome jobs platform.

sedawk 3y ago

Thank you for sharing, it was an excellent read!

StillBored 3y ago

"Today’s IBM mainframe CPUs are based on a highly evolved version of the POWER architecture that IBM has been developing for over 30 years. " I've heard a lot of largely clueless people who weren't aware of the differences between the zeries and pseries say something like this, but its generally been entirely false (especially 15-30 years ago which overlaps with some time I myself spent at IBM). Given the rest of the article I wouldn't presume the author is in this category. So has something changed? or is the implication stretching the truth? I mean I guess you could strip a POWER core down so it only runs s390 microcode/etc, but that likely won't actually yield a performant machine and the process of evolving it would likely fundamentally change the microarch of whatever RISCish core they started with. I mean they are entirely different Arches, in the past utilizing entirely different microarches. I can see some sharing of a RTL for maybe a vector unit, or cache structure, or a group doing layout, but that doesn't make the zeries processors any more derivative of POWER than Itanium was derivative of x86, etc. PS: the bit about zos partitions supporting linux seems like a bit of confusion too, earlier its correct about the LPARs being capable of running linux directly, but ZOS isn't providing the lpar functionality, and is generally just another guest alongside linux, ztpf, and various other more esoteric "OSs" that can run natively. There is a unix system services in zos but that isn't a linux kernel/etc.

lizknope 3y ago
Yeah, I don't know where the author is getting the POWER arch connection. I thought the IBM Z Architecture was the CISC based System 360 / 390 architecture from the 1960's. At least that is what I remember my one friend who has some mainframe experience was telling me.
sillywalk 3y ago
I wonder if the article meant that IBM had worked on the POWER architecture for over 30 years? IBM did work on the eCLipz Project [0][1], combining / sharing tech from IBM Power/pseries, AS/400/iseries, and Zseries. This was around 2005-ish. I assume that collaboration has continued, but I don't know if that counts as 'based on ...'. "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, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline. However, the processors are quite dissimilar in other respects, such as cache hierarchy and coherency, SMP topology and protocol, and chip organization. The different ISAs result in very different cores – there are 894 unique z10 instructions, 75% of which are implemented entirely in hardware. The z/Architecture is a CISC architecture, backwards compatible to the IBM System/360 architecture from the 1960s. "[2] For the POWER [0] https://www.realworldtech.com/eclipz/ https://www.realworldtech.com/eclipz/ [1] https://news.ycombinator.com/item?id=18494225 https://news.ycombinator.com/item?id=18494225 [2] https://en.wikipedia.org/wiki/IBM_z10 https://en.wikipedia.org/wiki/IBM_z10

sb-alien 3y ago

I was involved in an IBM mainframe to RS/6000 migration in the mid 1990s for a major aerospace company. We moved the engineering functionality to a client/server system, including many custom programs and CAD/CAM/CAE. Like the article mentioned, migration was a Herculean task done over a period of years, with a good chance it wouldn't succeed. I worked many 70 hour weeks, I had to drive to the factory at 2AM some days to monitor jobs because only certain people had remote access. Floating point and text encoding was different between the systems, decades of legacy engineering and manufacturing data and code (having cost hundreds of millions of dollars to produce) had to be translated and verified. There was a rivalry with the mainframe group who wanted it to see it fail, reluctant programmers, engineers, and line workers. On and on and on...we had to apply start-up levels of creativity and ingenuity while working in an MegaAeroCorp bureaucratic atmosphere. Ultimately, the project was a success, although the system soon moved to PC-based desktops as graphics cards became more powerful. I got a company award from my internal engineering customers. Shortly after the dust settled, I got called into a secretive meeting with my boss and the department head, expecting a promotion and a raise, or at least an "Attaboy!" No, I was reprimanded by an HR rep with a formal note in my records about my attitude ("You risked everything by cowboying!"). I was admonished for having the gall to take a couple of sick days during the ordeal (my coworkers were concerned when they found me passed out at my workstation, my boss warned me after my time-off "If you are sick be sick" and called me a filthy name.) I was put on double secret probation. Our whole department was eventually outsourced, and I ended my tenure there by being escorted by security to the door and told not to let it hit me in the backside. I guess I should have joined the mainframe group on the business side, in retrospect, they are still around grinding out profit statements. It was a challenge to get rid of a mainframe, maybe more so than eliminating our entire engineering support team.

sb-alien 3y ago
After the migration, when they were "decomissioning" the mainframe itself, the company photographer took a picture of the migration team gathered around the mainframe. It was unplugged, being gutted, with copper pipes sticking out. Years later, looking at a print, it reminded me of the old pictures of a whaling crew gathered around a whale carcass--don't get me wrong, whales are much more valuable and important. It does seem like we helped destroy something we really didn't completely understand the value of.

denton-scratch 3y ago

Back in the early 80s, I visited the Police National Computer Unit at Hendon in North London. The computer room was the size of a football pitch. Most of the floor was covered with washing-machine-sized disk-pack drives, along with quite a lot of dedicated IO processors (also washing-machine-sized). The walls were lined with storage for offline disk-packs. This system was a triple Burroughs B7800. What distinguished mainframes from minicomputers back then wasn't their awesome processing power, or their resilience; it was their huge IO capacity. They could handle hundreds of storage devices, and hundreds of thousands of terminals. At least, that's how I was told it; I never worked on mainframes. Nowadays a single connection to the internet can connect you to a similar number of "terminals", and storage is also accessed over a network. So the advantages touted by the author are quite different from what they used to be; IO nowadays isn't the issue it was back then.

myth2018 3y ago

It may be my mileage.. But I frequently hear about the shortage of mainframe professionals and, some years ago, I seriously considered getting into it. However, after some attempts to find training on topics I typically see in job postings (CICS, JCL etc), I gave up after finding no courses also providing access to a mainframe "account" for practicing. Maybe I didn't search it properly. I've been advised to try an entry-level position in a company hiring juniors, since they usually provide the training during the first months. But, after over 20 years as an engineer, that felt bigger a step back than what I was willing to take. I still feel interested though. I'm aware of the current state of chaos on mainframe development, but honestly, I don't think that the current web/mobile situation is much better and, besides, I personally hate them really bad.

dreamcompiler 3y ago

Early in my career I worked on IBM mainframes and wrote JCL for them. Let's say someone knocked on my door tomorrow and said "We're looking for someone with any experience at all with JCL on IBM mainframes. We'll pay a million dollars a year for a 10-year guaranteed contract. Are you that guy?" I would say "Nope. Sorry. I'm a plumber. I don't know nuthin' about computers." (And then they would say "Ha! GOTCHA! How'd you know we were talking about computers? Now take your million-dollar check and watch your head as you get into this nice black helicopter.")

eGuidezhan 3y ago

[dead]

mikewarot 3y ago

Absolute fringe opinion(or is it?): The performance and reliability are awesome, but have nothing to do with the real reasons IBM mainframes are still around. Backward compatibility helps - you can still run code for the IBM 1401 on these machines if you need to. When they came up with System 360, they effectively crystalized software development... taking what used to be a forced march to new hardware every few years as you got a new, faster, incompatible machine, and were rewriting the code for the better faster hardware.... and just FROZE that stream of development, which is why Y2K really happened. But even that's not the real reason IBM mainframes have stuck around so long... it's the same reason Virtualization and Containers took off.... they give no default access to files or disks, the administrator has to plan out which disks and other resources a Job, (or Runtime, VM, or container) will access. (Example, the DD statement of JCL[1]) This has the effect of being a very course grained capability object system.[2] The default access to everything on a Windows/Unix/Linux system just doesn't work in the modern era. It is because side effects can be strictly controlled, that Mainframes and later VMs and Containers have so much value. -- a small rant: It's 2023... consider the humble AC wall outlet, you can plug almost anything into it, and the circuit breaker or fuse will prevent bad things from happening to your wiring, house, etc. Why can't we protect against a rogue device plugged into a USB port? Why can't we just run any program we please, like we can plug in a lamp we bought at a garage sale, without risking everything? -- [1] https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-jcl-statements-what-does-dd-statement-do https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-... [2] https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security

graycat 3y ago

Ah, good to hear that the IBM mainframes are still around, are more powerful, and that the software for the old IBM mainframes will still run on the new mainframes. So, yup, JCL still works! An 3270 series video terminals with 24 lines of 80 characters each driven with CICS (customer information control system or some such) is still used. But I didn't see that (1) Rexx, often a good replacement for JCL, (2) XEDIT, and the PC version KEDIT, my favorite text editor, (3) and VM/370, an impressive virtual machine supervisor, upgraded from the original CP/67 for the IBM 360/67 mainframe are still supported and used. I would be shocked if they were not still supported and also still used, especially for development and analytical computing tasks.

neverartful 3y ago
The latest incarnation of VM/370 is branded z/VM. Most of my hands-on mainframe work was with VM/CMS and I enjoyed using it.
- graycat 3y ago
  For the software to schedule the fleet at FedEx, I wrote in PL/I on CP/67 (control program, i.e., virtual machine, for the IBM 360/67, with virtual memory) CMS (conversational monitor system, the user interface) on a 360/67 at National CSS time-sharing in Stamford, CT. Right, VM/370 was from CP/67! I wrote the code from my living room while teaching computer science at Georgetown U. Then in Memphis, one evening used the code to develop a schedule for all planned 33 airplanes for all planned 90 US cities. The next day two representatives of BoD member and crucial investor General Dynamics went over the schedule carefully and announced to the BoD that "it is a little tight in a few places but it's flyable". Until that schedule, due to concerns of some BoD members, scheduling had been a show stopper. But with the schedule the BoD was pleased, crucial funding, equity and also counting loans on the planes, etc., $55+ million, was enabled, and FedEx was saved until the next such BoD crisis. I solved the next such BoD crisis with the differential equation y'(t) = k y(t) (b - y(t)) and for this one, for the computing for the data to draw a graph of the solution, used my new HP calculator I'd paid $400 for! There the BoD wanted some revenue projections. NCSS was expensive, but I enjoyed using it AND PL/I! It didn't use 3270 communications and, instead, used asynchronous bits on a phone line and a portable terminal with heat sensitive paper in rolls. The terminal was from Execuport and supposed to be portable. Actually, it was delicate! It is just staggering how far computing has come since then! Hardware, operating system software, APIs, user interfaces, communications, YES, but applied math, algorithms, and programming languages, not as much and, thus, seem more fundamental!!!!

elzbardico 3y ago

The problem with most projects of mainframe migration that I've seen is that most of them suffered the bad luck of being started around the 90s and 2000s, a really complicated age in Enterprise Software, the age of COM/DCOM/COM+ and EJB 2.0. Any normal person would prefer to program in S/370 assembly than be forced to use EJB 2.0 Entity Beans.

tracker1 3y ago

I remember in my late teens, working as a temp... literally looking up individual accounts from a "past due" report to make sure they were still past due before they received a call from collections dept. Why, because paying a temp was literally less expensive than re-running the report on the mainframe.

PeterStuer 3y ago

The trick to surviving in Enterprise environments is consistently and credibly beating the longest horizon dtrayegic rate of return budget (luck has it enterprise's stategic horizons are not that long). At any point it is still better to stick with the current than to change. You boil the frog, but very carefully.