
The Mainframe Is a Modern Platform - rbanffy
https://www.enterprisesystemsmedia.com/post/the-mainframe-is-a-modern-platform
======
Multicomp
If nobody but a business can afford a computing platform, it is doomed long-
term. Everything was on mainframes until PCS were good enough and now
'everything' is on a PC, on prem or in the cloud. Even the serverless things
are run on someone's PC somewhere. With the exception of the bleeding edge of
high-speed computing with large amounts of data or old legacy banks that
couldn't support a 10 character password if their lives depended on it, x86 or
amd64 rule the world.

IBM does not get to boss us around anymore with their industry-specific terms
that they refuse to use standard industry jargon instead.

> have you ever tried to run a Windows 3 app on Windows 10

Yes. It is called cardfile and it runs fine even though Windows 10 tries its
best to never work on anything that isn't a telemetry laid in uwp social
sharing app. No expensive mainframe needed.

(Windows experts will note that card file has 32-bit versions and not just
16-bit versions but hop back even one version of Windows and it can run 16-bit
stuff as well so well my example wasn't perfect my point stands)

~~~
lol768
> Everything was on mainframes until PCS were good enough and now 'everything'
> is on a PC, on prem or in the cloud

100% agree with this - as a business, why would you want to pay the IBM
support contract costs? As a developer, why would you want to waste your time
learning about this sort of tech (I can't think of a more risky ecosystem to
invest your time into learning in terms of chance of the skillset becoming
obsolete)?

I've yet to hear about any legitimate usecases that couldn't be accomplished
using x86/amd64 VMs/machines. Monzo has clearly shown it's not required in
banking (and frankly, have shown how slow and generally useless the other
legacy banks have been when it comes to innovating on top of these mainframe-
based platforms).

~~~
rbanffy
> why would you want to waste your time learning about this sort of tech

Mainframes provide the largest single-image machines available today. A single
z15 can have ~190 cores and 40 terabytes of memory and can be networked into a
single-image group of sixteen machines to form a ~3000 core, 640 TB beast.

So, in essence, it allows one to program today your laptop of 2050. That's a
pretty cool superpower.

Remember when 8 CPU 64-bit RISC machines running Unix were cutting-edge? There
is one in my pocket right now.

~~~
TheOtherHobbes
The one in your pocket has a touch interface with a web browser and a
completely different OS and development environment. As a system, it has very
little in common with some mid-2000s UltraSPARC derivative.

The same will apply to a hypothetical 2050 laptop. There will be Some Hardware
but the software around it will be almost unrecognisably different - assuming
we still have laptops in 2050, which I doubt.

~~~
rbanffy
Well... It has less in common to the SPARCstation or the O2 I used in the
2000's than with the Linux box sitting to my left, but it still has a multi-
tasking, multi-user OS and I can still have a terminal shell to it.

If, in 1990, I were asked to say what my laptop would look like, I'd say it'd
use a microkernel OS like QNX and an intelligent assistant not unlike Sun's
Starfire film.

------
adev_
I will be hated for saying that but ....

Little reflection: The Cloud (PaaS & SaaS) is nothing else than the new
Mainframe 2.0.

Same staff, different time.

\- Mainframes provides you HA by hardware redundancy, The Cloud do the same
using distributed consensus and virtualization.

\- Mainframes offer a way to scale your infrastructure through vertical
scaling. The Cloud does the same through horizontal scaling.

\- Mainframes jail its users through proprietary software stack (COBOL&IBM),
the Cloud do exactly the same through proprietary APIs & services (SQS,
lambda, Aurora).

\- Mainframes make you jailed financially to an hardware provider (support
contract). The Cloud make you jailed financially to a service provider (BW,
$/h).

\- Mainframes were provided by Big-Corps in close to duopoly situation. Same
for Cloud providers today.

~~~
dijit
The main difference is that I can kinda almost run the software on my laptop.

Until you use Cloud Spanner or SQS or any other cloud specific technology.

~~~
tams
Even with cloud specific technologies still have to option to use locally
running alternatives for development with a little abstraction.

Unless your core business specifically targets the capabilities of chosen
cloud specific tech, you can get away with developing on a supplemental
solution and rely on CI plus staging environments to uncover and fix the edge
cases that you miss this way.

This is especially true with low-level stuff like databases and queues. I've
worked like this for years and never had to worry much about it.

~~~
luma
If you're going to run alternatives to cloud services and call that good
enough, then the same is also true for mainframe development.

Meaning, I can't run DynamoDB locally but PostgreSQL is close enough for most
tasks, so sure I can kinda run that workload locally, but I won't learn any
implementation-specific issues about how it would behave in AWS.

Similarly, I might have a hard time running DB2 for Z/OS, but I can also run
it on Windows or Linux, and in this case I'm far closer to the actual
development environment. Same is true for most of the dev tools and services
commonly found in Z series environments.

I would argue the commenter above you is flat-out wrong: for most core AWS and
Azure services, it's far easier to put together a home, single-desktop-PC-
based dev environment for mainframe than it would be for cloud if you don't
have the ability to actually use the cloud directly.

------
bhawks
Every organization I've encountered with mainframe dependencies has them not
because they are a strategic asset but because the economics and risks of
removing the mainframe from the system dwarf the expensive costs of the
hardware itself.

The biggest lessons the mainframe has to teach software engineers is not
around vertical scaling, uptime, backward compatibility or IO throughput but
how software quickly becomes a liability and a risk rather than an asset or an
advantage when it is not developed in a thoughtful disciplined way.

~~~
stubish
And if they get someone smart enough to do the migration without sinking the
business, they won't be repeating mistakes of the past and replacing their
entrenched mainframe systems with more mainframes. Unless they are paying IBM
to do it, and even IBM will likely be selling something sexier like a private
cloud.

------
mothsonasloth
All the commenters trying to shoot down the article with their fervour for
modern apps deployed onto cloud infrastructure are failing to see the irony.

Their shiny app that they built a few years ago and is deployed succesfully
into a companies systems, it will be maintained for a few years. Then some
people will leave.

Then documentation (if there was any) will be lost.

A few rookie developers will be brought in and will try to learn the system
and add a few widgets or features on.

Then in 20 years time, the app will be like the COBOL programs running on
dusty mainframes.

 __History repeats itself __

~~~
tluyben2
Most people believe that their software won't be used for more than a couple
of years at most, especially young people who (seem to) think companies just
rewrite everything to the latest and greatest (currently js/react; tomorrow
something else) every few years. So they are not thinking about 2 years let
alone 20 years.

As someone who is maintaining products written (by me) 15 to 25 years ago, I
know that I was absolutely wrong about that assumption. A company will not
touch software if it works, no matter what the latest or greatest is and no
matter if it looks like crap. I shudder to think, with JS projects breaking
between minor versions of libraries, what happens if there is an issue 20
years from now... Egotistical really to use 'the latest and the greatest' and
then just let 'the next person' live the pain of supporting that. You can say
whatever about php and java but 20 year old code works fine with very minor
changes; I have Node/JS code from 2 years ago that doesn't work anymore at all
after security updates.

~~~
collyw
20 years of real world testing is worth a lot than some unit test suite.

~~~
couchand
Well that's a false dichotomy if I've ever heard one. All those years of
running in production will do nothing for you when the business asks for
tweaks.

------
bregma
The comments here are a wonderful insight into the SV and HN mindset.
Developers want to develop.

Take the classic unicorn triad of finance/sales/development, and make a plan
to exit as close to the peak of the revenue curve as possible. After all, the
instantaneous value of peak income at the inflection point is pretty high. If
all goes well (and it almost never does), you could be earning billion of
dollars per second, at least if you ignore the burn rate.

It turns out that some 99% of the money to be made is under the curve between
the initial peak and the end of the long tail -- and the end is not yet in
sight for many mainframe applications. They're busy earning billions of
dollars a year.

~~~
p_l
Funnily enough at $DAYJOB we use data from some mainframe systems.

Recently the team learnt that no, those mainframes are not on-premises, they
are in IBM cloud.

------
wmf
This doesn't really matter. Legacy apps need to be modernized but their owners
can't afford/aren't willing to. It's not the mainframe holding these apps
back... the problem is much much worse.

Also, mainframes are the most expensive way to run modern code so the fact
that it's possible is not interesting.

~~~
trimbo
> Legacy apps need to be modernized but their owners can't afford/aren't
> willing to. It's not the mainframe holding these apps back... the problem is
> much much worse.

I've been thinking about this a lot. I don't think many businesses have the
margin to pay for the vast cost of a rewrite off of legacy. So maybe it's
simply an evolution of business. Old businesses die and young businesses take
their place with more efficient technology.

Unfortunately, it does not happen in industries that are heavily regulated,
and probably where we need it most.

~~~
OldHand2018
If it aint broke, don't break it.

In a business context, the outcomes that your software enable are the things
that matter. If your legacy platform still works and your business can still
accomplish the things it wants to accomplish, why add a huge expensive
distraction?

IBM still makes mainframes. You can still buy OpenVMS systems. There is no
reason to believe that you will wake up one day and your technology will no
longer exist. Don't hire people from Stanford or MIT. Recruit at 2nd tier
schools and get them a year or two before you need them. They can learn all
they need on the job, and they cost less, too.

~~~
wmf
Ah yes, outcomes like payments taking over a day to go through and people not
being able to receive unemployment.

~~~
sp332
Mainframes are not slow. IBM's POWER architecture has some downsides but it is
no slouch in transactions/second.

> payments taking over a day to go through

That's due to the protocol.
[https://en.wikipedia.org/wiki/ACH_Network](https://en.wikipedia.org/wiki/ACH_Network)
"when a real-time transfer is required, a wire transfer using a system such as
the Federal Reserve's Fedwire is employed instead".

> people not being able to receive unemployment

That's probably not due to the mainframes.
[https://slate.com/technology/2020/04/new-jersey-
unemployment...](https://slate.com/technology/2020/04/new-jersey-unemployment-
cobol-coronavirus.html) That's probably an administration issue.
[https://www.citylab.com/equity/2020/04/unemployment-
benefits...](https://www.citylab.com/equity/2020/04/unemployment-benefits-
reopen-georgia-business-coronavirus/610321/)

~~~
Lutzb
Z and POWER are two distinct architectures.

~~~
sp332
I know you can get different architectures in a mainframe, including Power.
What's Z like?

~~~
lboc
[https://www.redbooks.ibm.com/abstracts/sg248851.html](https://www.redbooks.ibm.com/abstracts/sg248851.html)

and

[http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf](http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf)

Should pretty much cover it :)

Edit: missed http

------
marktangotango
Given all the attention COBOL has gotten lately, I still haven’t seen any
discussion of its characteristics that make it relatively “safe”, secure, and
fast. These are; all memory is statically allocated, no dynamic memory
allocation. No user defined functions and no stack. Of course I’m referring to
the 85 standard here and later versions added these things but 85 is very
common on mainframes (my understanding please correct if wrong).

These two things disallow entire classes of exploits and errors.

Edit to add, rather than put out these puff pieces, ibm needs to figure out
how to get mainframe access for developers, only then will they see usage
increase.

~~~
voldacar
Those things also disallow entire classes of program. Good luck writing a
webserver or game engine without heap allocation

~~~
shoo
While not addressing the comment of writing programs without heap allocation,
a lot of programs can be compiled to execute using the only mov instructions:
[https://github.com/xoreaxeaxeax/movfuscator](https://github.com/xoreaxeaxeax/movfuscator)

Yes, it can run doom:
[https://github.com/xoreaxeaxeax/movfuscator/tree/master/vali...](https://github.com/xoreaxeaxeax/movfuscator/tree/master/validation/doom)

It just doesn't run doom terribly fast.

~~~
voldacar
ok, so how do you call malloc or syscalls with mov instructions? Do you just
(assuming you turned on executable stack) use mov to write the corresponding
non-mov instructions necessary to do those things to memory, then mov the
address of these instructions to the ip register? im struggling a little here

~~~
lxdesk
These are classified as "libc things". When using mov you can still access
libc like any other program. Go study movfuscator(which I linked again) if you
would like a full understanding[0]. When you have to interface C with a not-
very-Unixy system like Webassembly or these mainframes, you have to link to a
compatible libc that remaps everything appropriately.

Malloc isn't particularly more special than any libc function. It simply
supports the fantasy that the memory is unlimited in scale. It was always of a
static size, you were just handing off the chore of dividing it up. You can
usefully implement dynamic sizing in languages with static memory allocation
by pre-allocating large arrays and then maintaining handles and liveness
flags. This is, in fact, how every console game used to do it until available
memory sizes got into the hundreds of megabytes. Fragmentation and the
subsequent crashes from OOM presented too much of a concern before then.

[0]
[https://github.com/xoreaxeaxeax/movfuscator](https://github.com/xoreaxeaxeax/movfuscator)

~~~
voldacar
Ah I thought the idea was to make the whole program use nothing but mov
instructions. Still cool though. That's an interesting point too about console
games, it seems to make a lot of sense if the whole machine can be dedicated
to running just your program

------
ancarda
>Nevertheless, many older applications need to be modernized, for example, to
create a modern web or GUI interface instead of the ubiquitous green screen
interface common for older mainframe applications.

Why do they "need" this? What's wrong with a TUI? Must every single piece of
software have a "modern web" interface?

If the option is between a TUI that's instant, and a React/Vue/whatever app
that takes 15 seconds to load and breaks the back button... maybe the TUI
ain't so bad?

~~~
ulisesrmzroche
First things the vast majority of users (virtually all) when they see an old
ugly GUI is to hit the back button.

Decent SPAs don’t take 15 seconds to load and they don’t break the back
button. Stop spreading FUD.

It’s like the HN myth of how there’s supposedly all these old devs writing
COBOL for the government and in reality the government can’t find any
developers to maintain their ancient apps

~~~
SamuelAdams
> It’s like the HN myth of how there’s supposedly all these old devs writing
> COBOL for the government and in reality the government can’t find any
> developers to maintain their ancient apps

Exactly. I worked at a private, multi-billion dollar organization a few years
ago. There were plenty of "old devs" working on their COBOL software, but they
also got paid more than 6 figures to do so. And they hired recent grads to
work on those same systems. New grads typically started around 60k, more if
you negotiated better. Whereas these gov't jobs only pay around 35k - 75k for
the same work. For someone with years of experience.

------
kstrauser
No, it's not. A mainframe is awesome for certain classes of problems, but I
don't generally think of those classes as modern. Yes, you _can_ run ML on a
mainframe, but its performance isn't going to scale as broadly as throwing a
thousand ephemeral virtual hosts at the problem (why virtual? because I'm not
running ML 24/7 and don't want to pay for the cluster while everyone is at
home asleep). Sure, maybe it can handle 12 million web requests per second -
I'm skeptical about the complexity of those requests but let's roll with it -
but now the computing resource is more robust than the network connections you
have plugged into it. Are the pipes into your data center truly more reliable
than a multi-AZ, multi-region AWS deployment?

To put it bluntly, mainframes are wonderful solutions to problems that I don't
personally find interesting. (Note: personally. It's not like I don't think
there's a legitimate need for the financial systems that mainframes power,
it's just that I'm glad I'm not the one who has to run them.) The problems I
enjoy involve horizontal scaling at levels that a mainframe just isn't going
to reach, and those are the kinds of problems that most people would describe
as "modern". And as I don't think mainframes are a good solution to what I
consider to be modern problems, neither do I consider them to be a modern
platform.

Again, not that this makes them less valuable for the problems they _do_
solve. I don't want to run a stock exchange with its gazillion transactions
(as in the database _and_ financial kind) per second on a cluster of x86 VMs.

Edit: But you want to make them modern, make it easier to play with the damn
things. I can get almost any other kind of computing tech into my house for
under $1,000, but it's freaking impossible to experiment on a mainframe
without selling a kidney or signing a contract in blood. If your platform's
"learn more" link goes to a form read by a salesperson, you've already lost
me. If I have to pull out a credit card to tinker with it, you've already lost
me. Contrast with AWS, for example, which practically throws free resources at
you to get you interested and invested in the platform. Where are my free IBM
resources that get me a mainframe login and access to developer-useful
documentation? As it stands today, if I want to learn how to operate Big Iron,
I pretty much have to take a job doing it full-time. Make it easy for me to
poke at one at night and on weekends if you want me to tell my boss about this
cool thing you're trying to sell.

~~~
zozbot234
Except that mainframe-like platforms are all about vertical as opposed to
horizontal scaling, particularly for transactional workloads where this kind
of scaling is highly relevant. You can't horizontally scale a database (beyond
trivial sharding of logically-independent partitions, perhaps with some
further dependency on rarely-changing data that can thus be replicated/cached
locally) without severe tradeoffs in both latency and reliability.

~~~
kstrauser
That's pretty much what I said. Conversely, you can't vertically scale a
database (beyond throwing ever more CPUs, RAM, and RAIDed SSDs) without severe
tradeoffs in electric bills and support contracts, and while still not getting
the advantages of geographic redundancy. For instance, notice that none of the
FAANGs are serving their websites off mainframes. Cost-per-server isn't the
only reason for that.

My point wasn't that mainframes aren't useful - they are! - but that they're
not good solutions for a lot of the new problems people are trying to solve
lately. For instance, a huge portion of fun challenges are perfectly fine with
eventually consistent solutions that optimize for availability, where one
single piece of reliable hardware behind a couple of redundant peering
connections simply can't compete with 1,000 reasonably reliable nodes
distributed globally.

~~~
zozbot234
> For instance, notice that none of the FAANGs are serving their websites off
> mainframes

Obviously, nobody cares if the data that makes up your FB/Twitter timeline or
Google search results page is less than completely reliable. The new problems
people are trying to solve with horizontal scaling and distributed computing
may well be "fun" for users and developers alike, but fun is quite different
from generally worthwhile.

~~~
kstrauser
I didn't say they were unreliable. I said they were eventually consistent.
ACID is a wonderful model for lots of data problems, but wholly inappropriate
for lots of things where availability matters more than perfect consistency
before it's reconciliation time. For instance, suppose you're reading data
from a million sensors in a particle collider. You absolutely _don 't_ want to
model that as a million `BEGIN; INSERT INTO readings (sensor, value) VALUES
('particle_489285', 83); COMMIT;` queries. It's probably more appropriate to
shard those sensors to N servers that log the readings to local journals in
realtime, then upload them to a central data warehouse later after the
experiment is finished. Reliability is extremely important there, but realtime
ACID-style consistency would add nothing of value.

Financial transactions aren't the only "real" work out there, and there are
lots of "fun" projects that are deadly serious.

------
dgrrrrr
I've recently worked with mainframes in a large, global organisation. Like the
majority of people commenting here, I was sceptical about them.

The reality is, when it comes to transactions per second, reliability,
security and vertical scaling - _nothing_ beats them.

Also, it worked out about 60% less expensive to run a z-series for three years
than it would've been to use a third party cloud solution.

So, yeah. Mainframes rock. And that's the reality of it.

~~~
m1sta_
The hardware is great. It's the software and labour that kills things from a
cost perspective.

~~~
dgrrrrr
The labour! There's a severe skills shortage. The average age of a mainframe
admin is about 95 years old!

~~~
somatic
I mean... is there _really_?

How much do these people get paid?

~~~
p_l
I've heard of real, major issues in USA where organizations that were willing
to train someone from zero just could not get them over the fact that the
terminal was block-based instead of character based...

------
jasonmar
As part of my job over the past 2 years I’ve been migrating a data warehouse
with data being loaded from Mainframe into BigQuery. I’ve learned a lot and
gained respect for the platform.

One of Google’s differentiating products is the TPU, to train neural networks
in hardware. Meanwhile, the mainframe has specialized hardware for TLS, gzip
compression and encrypted storage.

------
paleogizmo
Can anyone explain how Mainframes differ from commodity servers or a high-
performance computing cluster with low-latency networking? Is there really a
practical difference? I get that they are useful for handling banking
transactions, but I've never gotten a good explanation of why a collection of
networked servers is poor for this.

~~~
bob1029
A cluster of x86 servers can be made to be as or more reliable than a
mainframe and provide equivalent or superior performance.

The difficulty is that doing this requires building a full vertical around the
idea, and it's so hard to sell new big scary ideas to the business. So, the
entire space is now fractured into 10000 vendors trying to sell you various
nuanced aspects of the big picture. Combine with the cloud hysteria, and
there's virtually zero chance you get to even experiment with this idea unless
you take it up as a hobby and/or build a company around it.

To do this right for commodity x86 - that is, make it as or more reliable than
a Z15 mainframe with equivalent performance - you have to do it on-prem and in
a datacenter designed around the topology of the cluster. You cannot run
something like this inside AWS/Azure/et.al. and expect it to perform well. You
need direct fiber links between nodes without switches in the middle. Minimum
of 5 nodes for N+2 redundancy. N+1 paths between every node. 2N+1
power/cooling. There is zero compromise you can take on the aspects of such a
solution if you want to meet or beat IBM's insane numbers. On top of this, you
would have to develop a software platform that is directly aware of your
physical topology in order to properly leverage it. This implies writing new
business software against your new platform. This is risky business. No
reasonable shop would sign up for that ride unless you had 2-3 success stories
and living, breathing clients to testify to the same effect.

~~~
linksnapzz
_A cluster of x86 servers can be made to be as or more reliable than a
mainframe and provide equivalent or superior performance._

For some carefully chosen, possibly hypothetical value of cluster,x86,server,
reliable and performance.

To go from a hypothetical to a concrete would require an investment of time
and money of sufficient magnitude to make the purchase/lease of an extant
mainframe a compelling choice.

IOW, if my grandmother had wheels, she'd be a horse trailer.

~~~
zozbot234
> To go from a hypothetical to a concrete would require an investment of time
> and money of sufficient magnitude

As another commenter mentioned, Oxide Computer seems to be going for something
not unlike this. People might compare their system-design target to the
minicomputer (or the "supermini") as opposed to the mainframe, but that's just
semantics at this point.

------
lasermike026
Mainframe hardware is amazing. You can do many soficiated configurations and
is quite fault tolerant. The kicker is the price. If your a large multi-
billion dollar corporation it might make sense to buy a few of them. For the
rest of us the price is way too much.

As for cobol, cobol will be running long after we are dead. It's a testament
to cobol's resilience.

That being said, I am not a mainframe guy and I don't plan to be. The cloud,
linux and container does what need and quickly. (Mainframers can add their
snark here.)

~~~
rbanffy
I seriously doubt a 4-socket, 80-thread, 8 terabyte x86 box from Lenovo is
that much cheaper than the lowest end of the z15 spectrum.

A 4-socked Dell with 8 TB of RAM will cost you almost 400 thousand dollars
and, in order to get 5 nines out of it, you'd better buy a bunch of them. You
also won't be able to match the single thread performance of the z15 CPUs and
almost a gigabyte of L4 cache.

~~~
unixhero
I think you have a point.

However. Seriously. Who the heck needs 5 9s? Who are dependent on only being
able to hold their breaths for 60 milliseconds per week?

~~~
rbanffy
An unscheduled reboot of a reasonably sized server doesn't happen in 60 ms. I
don't think 60 ms is even enough to properly power up all components of the
BMC.

We are looking into, at best, many minutes of unscheduled downtime. Depending
on your business model, that lost revenue could have paid for a lot of metal
in the first place.

~~~
p_l
60ms won't get you stabilized _voltages_ on motherboard, let alone a reboot.

------
mcescalante
I have been involved in a slow-rolling project at work to migrate a fair
number of administrative screens and their data (written in the late 80s/early
90s) off of the existing zOS mainframe, primarily because of the costs
(management doesn't want to pay IBM anymore for the limited set of things it's
being used for and finding devs is expensive too). The project has already run
way past the original estimate, no major surprise.

Our new APIs and web UIs are nice and all and offer a number of advantages for
today's users/admins, but sometimes it feels they take more babysitting and
fuss (updating deps, etc.) than the old mainframe code did - I'm not confident
that an Angular SPA running for 20+ years would still work the same, so we
have tried to take that into consideration while designing replacements.

I'm not complaining about one or the other but rather I feel lucky to have
experienced tradeoffs and learned about how some of these problems were solved
20-30 years ago, while I was still in grade school.

~~~
zozbot234
Not everything needs to be an Angular SPA, surely? It seems obvious that
choosing a well-understood server side platform would make way more sense for
something like this.

~~~
mcescalante
You're absolutely correct - we have a healthy mix of traditional server-side
web applications and a small number of SPAs only where it makes sense (usually
complex forms with lots of feedback/conditionals). I just used Angular as an
(admittedly) easy target. These days, I've been trying my best to avoid SPA
for enterprise stuff if possible

------
skybrian
It seems like we should distinguish between hardware and the platform that
software runs on.

I'm wondering if the same software can be deployed to mainframes and non-
mainframes easily. Is the hardware sufficiently abstracted away so that it's
like running a Docker file?

I do realize that virtual machines were invented in the mainframe era, but I'm
wondering how it's done nowadays.

~~~
lboc
(s390x) Docker containers are natively supported in z/OS 2.4:

[https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com...](https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_whatisintro.htm)

I guess there'd be nothing to stop you eg. including a s390x Linux on Hercules
into your build pipeline to produce z-ready images?

------
ksec
I am reading a lot of these comment. But I cant help but think most people
aren't exactly attacking the idea of Mainframe at all.

They simply dont like IBM. Or Mainframes from IBM.

Personally I love those ideals, 7 nines reliabilities, vertical scaling to the
max rather than super horizontal scaling ( Conceptually simpler ). I just wish
they were more accessible.

~~~
nix23
Well they are for everyone: [https://www.ibm.com/it-
infrastructure/z/education/master-the...](https://www.ibm.com/it-
infrastructure/z/education/master-the-mainframe)
[https://www-01.ibm.com/events/wwe/ast/mtm/audit.nsf/enrollal...](https://www-01.ibm.com/events/wwe/ast/mtm/audit.nsf/enrollall)

~~~
lboc
Woohoo! I can give my ctrl-c, ctrl-v fingers a bit of a break :)

------
arghwhat
This article, as with any other article referencing Gartner as an authority on
any matter, is just a sales pitch for the author's services.

------
martin1b
Working with a mainframe everyday, my experience is this. While IBM has
enabled the mainframe to run modern software, many mainframe developers cling
to the old development languages and techniques.

So, while the mainframe CAN be a modern platform, it may not be used as such.

------
tedk-42
Clickbait detected.

If this were true, we'd see a massive uptick in the sales of mainframes.

Mainframes don't scale. Nor do the apps you build into them. Unless you have
very deep engineering pockets. Most places though won't invest in this due to
the high initial upfront cost.

~~~
dfox
There is nothing inherent in mainframe hardware nor software ecosystem that
causes it to not scale. In fact, "modern" scalable software architecture with
containers, microservices and pervasive automation closely matches how things
are done in mainframe environment for 30+ years.

This fact obviously isn't lost on the IBM, because they even market scaled
down mainframe hardware as "kubernetes cluster in a box".

------
trasz
Are there any meaningful benchmark results for mainframe hardware available
anywhere? You’d expect there to be, like for any other competitive platform,
unless the IBM’s license makes it impossible to share them?

------
ngcc_hk
I think they should let someone to have an entry point for at least trainee
and people trying. Or it is another security measure, only insider can join
with barrier of million dollars investment.

~~~
collyw
A million isn't that much in tech terms. A team of 5-10 for a year?

------
sfgweilr4f
What mainframes are available like a cloud provider for me to get hosting?

eg I want to run code on a mainframe and pay for the equivalent of a VM (or an
actual VM)... who does this for a z15?

~~~
lboc
IBM Dallas:

[http://dtsc.dfw.ibm.com/](http://dtsc.dfw.ibm.com/)

Others exist, but you might need to be looking for/googling a 'service bureau'
(what cloud providers were called in the olden days)

------
andriosr
Mainframes are amazing machines, but I’m not sure as to how one would bring
these 9s to the end user application.

Can you have it globally distributed? Cross datacenters? Blue/green
deployments? Canary?

I saw a couple real world cases where banks went out of service due to an
electricity outage, they could not switch the mainframes to another
datacenter.

If you put a fault-tolerant multi/az app on AWS, the spinning disk or ssd may
not have the 9s of mainframes, but the end users won’t notice if one stops
work ring.

~~~
lboc
1\. Yes 2\. Yes

[https://ibmsystemsmag.com/IBM-Z/07/2019/resiliency-gdps-
solu...](https://ibmsystemsmag.com/IBM-Z/07/2019/resiliency-gdps-solutions)

Don't know enough about current mainframe development practices to answer the
last two sorry, but I don't see why not.

(Edit: missing word)

~~~
andriosr
Cool! thanks for sharing, will check out.

------
soniman
Did a mainframe write this?

~~~
wmf
Poor mainframes can't run GPT-2 because they don't have CUDA.

------
classified
A consultant trying to convince an audience that his obsolete area of
expertise is still relevant to more than 100 people on Earth. Good luck, I can
relate.

------
Spooky23
Mainframe is not a modern platform for anything other than niche use cases.

It’s a sole source legacy platform with little or no new investment.

~~~
rpiguy
I also have a semantic quibble with the author's choice of words. It is an
ancient platform that can do some modern things very well.

------
gHosts
Sooo... one of these is going to cost me how much?

Just asking.

~~~
posix_me_less
This guy says $24,000. [https://blog.mainframe.dev/2019/05/buying-ibm-
mainframe.html](https://blog.mainframe.dev/2019/05/buying-ibm-mainframe.html)

~~~
unixhero
To be fair, over the span of a few years; I spend more on team dinners.

------
smabie
Oh man, we not only get to use COBOL on mainframes, we get to use modern
languages like Java and C too! When your idea of modern is a language created
in 1995 and 1972, you know you're out of touch.

Let's face it, everybody knows that mainframes are dying. IBM knows it, these
Enterprise System Media guys know it (whoever they are), and most importantly,
every one of these big fortune 500 companies stuck with COBOL apps know it.
How many new projects are started each year that target mainframes? Or,
alternatively, how many companies who don't have any mainframes are thinking
about purchasing some for their new service? I'm guessing close to zero, or
maybe even actually zero.

The insane premium (in cost, in difficulty to learn, in everything) that
you're paying for those bazillion 9s of reliability aren't worth it. Anyone
who actually needs that kind of reliability has the technical knowledge to
make it themselves using x86_64. According to his talking points, big tech
should be loving mainframes and exclusively use them. But in fact, it's the
opposite. The most savvy and powerful tech companies use commodity x86_64
while the not so savvy are stuck with their 1980s mainframes. In Emmanual
Derman's "My Life as a Quant", he talks about developing a new bond analytics
platform at Goldman Sachs. His team decided to build it on Unix (though Genera
was floated around as an idea as well), because it was the modern choice and
mainframes were legacy. And this was in the early 80s!

This article is so unenthusiastic, it's kind of sad. It's like the author
knows what he's saying is total bullshit. I predict that in the next 10 years,
IBM is going to stop selling hardware (I'm not even sure why they haven't
already, but then again, the company isn't exactly a paragon of good
management) and just release some virtualization package that can run all the
legacy crap on x86_64. Or maybe this has already happened, finding any
information on what IBM an product _actually does_ is quite difficult. I get
the impression that no one actually calls IBM to inquire about a product.
Instead, I'm sure some middle management guy sells out his company for a $60
steak and some wine.

~~~
pulse7
"everybody knows that mainframes are dying" Please name a single modern
machine which can reliably handle billions of financial transactions on
December 31 every year, when everybody is shopping? I know you can handle this
with cloud, but it's not so reliable and you need many servers... On the other
hand, you have a single machine with decades of up-time...

~~~
Qasaur
It is not impossible to build a system that can handle this on x86_64, it's
more a question of software architecture rather than hardware architecture -
modern computers are insanely powerful.

~~~
burntoutfire
That software architecture will be extremely hard to pull off if you really
want that kind of stability (distributed systems are HARD). Only the most
hardcore engineering organizations can pull this off (i.e. not banks or
airlines). Meanwhile, IBM is selling out-of-the-box solution that you just
need to buy and plug in.

~~~
zozbot234
It's less about it being hard (banks and airlines can pay for lots of software
engineers if they need to) and more about it not being necessarily appropriate
to every workload. Distributed systems must be designed assuming that any
single node might fail at any time; even communication among nodes cannot be
assumed to be reliable, and every communication step introduces latency. When
a random processing error means that some airplane might fall out of the sky
or some banking transaction might go unaccounted for, these problems become
very relevant.

------
timwaagh
I would say developing for java that ultimately will run on mainframe is worse
than developing for java for another platform (because deploying to your
development websphere is slow and not so reliable). The other problem is that
Java is the most 'modern' programming language available. Nobody wants to
write a web app in COBOL or C. But Java isn't that good at it either (even
without websphere, java does not deploy as fast as python, ruby, php, go). The
only misconception is that its 20 years out of date instead of 50. The best
reason to stay well clear of it is cost, though. Not just increased
development cost but those things are expensive. But for a developer it can be
good. Mainframe orgs tend to be stable and pay above average.

~~~
lboc
>The other problem is that Java is the most 'modern' programming language
available.

[https://developer.ibm.com/swift/2018/07/06/using-swift-
creat...](https://developer.ibm.com/swift/2018/07/06/using-swift-create-web-
services-z-os/)

[https://www.rocketsoftware.com/product-
categories/mainframe/...](https://www.rocketsoftware.com/product-
categories/mainframe/python-for-zos)

[https://developer.ibm.com/mainframe/2018/01/19/reasons-
host-...](https://developer.ibm.com/mainframe/2018/01/19/reasons-host-node-js-
applications-zos/)

~~~
timwaagh
The article did not mention those, so i wasnt aware.

