4 ms·

What type of workloads are actually ran on mainframes? What do they do better than regular machines?

by vips7L 5y ago

ryanianian 5y ago
Think: opposite of general-purpose operating systems use-cases. Very IO/compute/latency-intensive things. Where the whole programming paradigms are designed around efficient (even real-time) compute. Where the software+hardware pair are written once and rarely if ever changed, restarted, or taken down for maintenance. Credit card transaction processing and airline reservation systems for example. Of course you could use Linux or similar for such jobs, but highly specialized hardware+software pairings can eke out surprising performance at the cost of massive hardware and software-engineering bills.
tyingq 5y ago
For z/OS, I don't think much anymore. The high level of single-machine redundancy and architecture of I/O offload USED to be better than commodity machines. That's been eclipsed by raw power and improved distributed functionality in the commodity world. There are still companies (Visa, Airlines, GDS) having issues getting off the more unique TPF operating system. It's basically a distributed K/V data store that scales very well and deals well with write contention. So far, only Amadeus has been able to migrate off of it. Some smaller airlines were able to migrate away, but not the larger ones. The company that Google bought (ITA), was on their way to writing a full reservations system. They had finished the shopping engine but not the whole system. That was a company chock full of money of talent, and they didn't finish. Though their shopping engine is the best one that exists. Edit: Somewhat related point. The "developer efficiency" was quite good in these environments. Since the OS came with everything a developer needed, there was mostly only one right way to do everything. The languages, libraries, database, batch management, "UI", authentication/authorization, security, and so on, was already decided for you.
deleted 5y ago
[deleted]
enthd 5y ago
My first professional dev job was COBOL and it's associated tech, a majority of the stuff we did was banking stuff and at the time it seemed like that's what a majority of the COBOL market took up but I could be wrong
bob33212 5y ago
Some software was written for Mainframes that effectively NEVER reboots. So you have to modify it to support reboots easily, but it was written in COBOL or and old version of C and compiled with an old compiler. So it isn't that easy to fix.
- aerostable_slug 5y ago
  It's really fun to recover a system that's designed to never go down. Some years ago I was working with Tandem/Compaq and they had a web server on the NonStop Himalaya platform. Long story short, said server had its first experience with real world web traffic at scale when we were delivering coverage of an international sporting event, and Things Went Poorly. The onsite Tandem engineers had never been faced with a NonStop setup that just...stopped (actually it was worse than that). Bear in mind this was the company that used to do demos by randomly unplugging hardware and the transactions kept chugging along. We ended up punting coverage to a smaller flat version of the site served off Compaqs running IIS while we cleaned up the mess. Now, Tandem shouldn't feel bad. After all, Cisco had guys in the hosting facility trying to keep the then-new PIX series up and running.
  - rbanffy 5y ago
    > It's really fun to recover a system that's designed to never go down The thing with systems designed to never go down is that you still need to be sure the recovery process works well. Never going down is just half if your nines. > served off Compaqs running IIS Yikes!
- zozbot234 5y ago
  > Some software was written for Mainframes that effectively NEVER reboots. So you have to modify it to support reboots easily Run it in a VM instance that can be snapshotted/checkpointed, so that any reboot turns into "suspend and resume from checkpoint"? Or are there any pitfalls to just doing that?
  - bob33212 5y ago
    Yes that can help, but VMs are still either Linux or OSX or Windows, and they all require security or other updates that will eventually need to reboot the system. Also the processors are different.

What type of workloads are actually ran on mainframes? What do they do better than regular machines?

by vips7L 5y ago

What type of workloads are actually ran on mainframes? What do they do better than regular machines?

Think: opposite of general-purpose operating systems use-cases. Very IO/compute/latency-intensive things. Where the whole programming paradigms are designed around efficient (even real-time) compute. Where the software+hardware pair are written once and rarely if ever changed, restarted, or taken down for maintenance. Credit card transaction processing and airline reservation systems for example. Of course you could use Linux or similar for such jobs, but highly specialized hardware+software pairings can eke out surprising performance at the cost of massive hardware and software-engineering bills.

tyingq 5y ago

For z/OS, I don't think much anymore. The high level of single-machine redundancy and architecture of I/O offload USED to be better than commodity machines. That's been eclipsed by raw power and improved distributed functionality in the commodity world. There are still companies (Visa, Airlines, GDS) having issues getting off the more unique TPF operating system. It's basically a distributed K/V data store that scales very well and deals well with write contention. So far, only Amadeus has been able to migrate off of it. Some smaller airlines were able to migrate away, but not the larger ones. The company that Google bought (ITA), was on their way to writing a full reservations system. They had finished the shopping engine but not the whole system. That was a company chock full of money of talent, and they didn't finish. Though their shopping engine is the best one that exists. Edit: Somewhat related point. The "developer efficiency" was quite good in these environments. Since the OS came with everything a developer needed, there was mostly only one right way to do everything. The languages, libraries, database, batch management, "UI", authentication/authorization, security, and so on, was already decided for you.

deleted 5y ago

[deleted]

enthd 5y ago

My first professional dev job was COBOL and it's associated tech, a majority of the stuff we did was banking stuff and at the time it seemed like that's what a majority of the COBOL market took up but I could be wrong

bob33212 5y ago

Some software was written for Mainframes that effectively NEVER reboots. So you have to modify it to support reboots easily, but it was written in COBOL or and old version of C and compiled with an old compiler. So it isn't that easy to fix.

aerostable_slug 5y ago
It's really fun to recover a system that's designed to never go down. Some years ago I was working with Tandem/Compaq and they had a web server on the NonStop Himalaya platform. Long story short, said server had its first experience with real world web traffic at scale when we were delivering coverage of an international sporting event, and Things Went Poorly. The onsite Tandem engineers had never been faced with a NonStop setup that just...stopped (actually it was worse than that). Bear in mind this was the company that used to do demos by randomly unplugging hardware and the transactions kept chugging along. We ended up punting coverage to a smaller flat version of the site served off Compaqs running IIS while we cleaned up the mess. Now, Tandem shouldn't feel bad. After all, Cisco had guys in the hosting facility trying to keep the then-new PIX series up and running.
- rbanffy 5y ago
  > It's really fun to recover a system that's designed to never go down The thing with systems designed to never go down is that you still need to be sure the recovery process works well. Never going down is just half if your nines. > served off Compaqs running IIS Yikes!
zozbot234 5y ago
> Some software was written for Mainframes that effectively NEVER reboots. So you have to modify it to support reboots easily Run it in a VM instance that can be snapshotted/checkpointed, so that any reboot turns into "suspend and resume from checkpoint"? Or are there any pitfalls to just doing that?
- bob33212 5y ago
  Yes that can help, but VMs are still either Linux or OSX or Windows, and they all require security or other updates that will eventually need to reboot the system. Also the processors are different.