[HN Gopher] The IBM mainframe: How it runs and why it survives
___________________________________________________________________
The IBM mainframe: How it runs and why it survives
Author : rbc
Score : 202 points
Date : 2023-07-24 11:35 UTC (11 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| grishka wrote:
| > 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 wrote:
| Some examples:
|
| https://aws.amazon.com/solutions/case-studies/monzo/
|
| https://www.avaloq.com/solutions/products/avaloq-core
| elric wrote:
| 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.
| shrubble wrote:
| 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...
| larrik wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bcantrill wrote:
| Yes! There are lots of ways in which we are nothing like
| these big IBM systems (we are, for example, entirely open --
| like POWER, but very unlike AS/400 or Z series machines), but
| we definitely admire the robustness of these machines!
| Indeed, arguably to a fault, as I likened us to the AS/400 in
| a VC pitch[0] -- which (despite the potential accuracy of the
| historical analogue) is as ill-advised as it sounds...
|
| [0] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2216s
| Melatonic wrote:
| 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
| hinkley wrote:
| I do like the idea that parts of a system can simply be
| turned off and when a number of faults have accumulated, a
| tech is assigned to deal with them all at once, amortizing
| the maintenance costs over more tasks.
|
| Better overall to replace three drives at the same time,
| especially if the servers are a half hour away from you.
| neverartful wrote:
| "using a dedicated stack of hardware and software owned by one
| company"
|
| advantage - one throat to choke
|
| disadvantage - they've got you by the balls when it comes time
| to pay the licensing and maintenance fees
| Yasuraka wrote:
| One has to wonder if the most optimal throat-choking to ball-
| holding ratio can be modeled
| bob1029 wrote:
| I have a really hard time with the game theory around this.
|
| Every time I run the numbers, I arrive at: I would _much_
| rather be in a situation where I can place blame at the
| feet of one party, especially if they are under some
| contract to provide a certain level of service. There are
| things that I absolutely cannot control and I 'd rather
| push as much of this as possible into one bucket.
|
| What I _can_ control is how we actually use the technology
| relative to the business. If our sole vendor doubles the
| price on a certain service, then we will explore
| alternative services (within the same vendor) or ways to
| use that service less (maybe we send emails instead).
|
| I know the vendor is going to try to turn the economic
| screws. That I can work with. Business as usual. What I
| don't enjoy are those "unknown unknowns".
| sb-alien wrote:
| 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.
| kencausey wrote:
| Have there been any machine learning related deployments on a
| modern mainframe? Would there be any value in doing so?
| CraigJPerry wrote:
| 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.
| mberning wrote:
| It persists in many places due to the deeply ingrained belief
| that, for one reason or another, it would be technically,
| practically, or economically impossible to migrate
| functionality off the mainframe. Somehow the people in charge
| of these systems have managed to convince large enterprises of
| this for _decades_. And now we are in a situation where their
| long held beliefs have become true because nobody is around
| that understands how or why the software works the way it does.
| It 's a disgrace.
| KennyBlanken wrote:
| Notice they didn't mention how incredibly outdated all these
| applications are? Our financial money transfer system is an
| ancient joke. The IRS has systems that are hopelessly out of
| date and limited in capabilities. It's really easy and safe
| to sign a contract for a newer mainframe; porting a legacy
| app is fraught. Middle-upper management goes for what's safe,
| not what could torpedo their career.
|
| The hardware might be whiz-bang but the legacy applications
| are slow, outdated, and extremely hampered in functionality.
|
| In my state, the birth records system is electronic, and so
| is our RMV. But in order to get a RealID, I had to get a
| paper copy printed out to bring to the RMV because they can
| not, or will not, integrate the two systems. Meanwhile other
| countries have things like electronic ID cards with personal
| certs so you can electronically sign documents and identify
| yourself.
|
| The whole thing is a giant puff piece for IBM, reading like a
| sales presentation transcript.
| adamc wrote:
| I have worked on an RFP for migration. It persists because
| the cost for migrating can be quite high -- many mainframe
| environments have many applications with complex sets of
| dependencies (after decades, not surprising). No one doubts
| that it could be migrated, but it is not a trivial
| undertaking.
|
| When folks have replaced significant enough chunks with other
| apps, or otherwise made the prospect less daunting, then it
| may happen. It just comes down to cost and risk management.
| ghaff wrote:
| Or the people in charge are of the belief that things work
| and they're a tiny part of the overall organization's costs--
| and any massive migration will run over schedule and budget,
| won't necessarily be better at the end, and will be
| unnecessary and disruptive. They may or may not be correct
| but it's not an irrational belief whatever those advocating
| for moving everything to a distributed platform think.
| ibiza wrote:
| Migrating a suite of programs written w/ COBOL, CICS, DB2
| from z/OS to Linux is fairly straightforward. MicroFocus
| COBOL compiles IBM COBOL, DB2 runs on Linux or you can swap
| out another RDBMS. The CICS part requires a simple runtime
| easily implemented in C plus a new scanner to replace the
| calls in your programs.
|
| I was part of a 4 person team that knocked this out in under
| a year. 1,000's of mainframe programs running w/o change (at
| the time) on Unix. This was in the 90s.
| hermitdev wrote:
| > DB2 runs on Linux The DBA's I interned with would yell at
| you for this claim. They'd say UDB runs on Linux, but DB2
| only runs on z/OS.
|
| I worked with both DB2 & UDB during my internship 2 decades
| ago, and while largely compatible with core SQL
| functionality, that changed quickly after you got off the
| "normal" path. UDB was released at a much faster cadence,
| and if you developed to the latest features of UDB, you'd
| often find yourself unable to deploy against DB2.
|
| A few of my last projects as an intern: 1) storing BLOB
| objects in DB2 from a .Net app and 2) porting an
| "interactive" batch-processed COBOL app to ASP.Net form 3)
| getting DB2 Connect clustering on windows working (I never
| did get this working despite spending an entire summer on
| the phone with IBM support).
|
| I've some fond memories of working with the mainframe. Like
| the time I managed to crash the entire development LPAR
| with a specific SQL query that broke the DB2 query
| optimizer... The phone call from the NOC was immediate and
| went something along the lines of "I don't know what you
| did, but don't do it again, you just took down all of
| development". Development was something like +10k users...
| rvba wrote:
| What company had 10k developers on a mainframe?
| ibiza wrote:
| Re DB2 vs UDB, thank you, it's been too long. Well done
| breaking DB2!
|
| We actually targeted Oracle on Unix. Fortunately, the app
| developers never got too deep into DB2-isms, so it worked
| out fine.
| radiator wrote:
| From z/OS to Oracle. Good Lord!
| stcroixx wrote:
| What replaces JCL?
| ibiza wrote:
| The env I helped set up was online only, no batch jobs.
| JCL is essentially a declarative shell language, so it's
| not that hard to map to Bourne shell et. al.
| redandblack wrote:
| perl scripts. sorry
| zitterbewegung wrote:
| The greatest hurdle for a project to be replaced is that if
| its works. I assure you that the users of IBM mainframes
| would be looking at at least a multi million dollar project
| to perform a decommission and if even approved it would be
| first on the chopping block to pause / eliminate the project.
| josho wrote:
| You are correct. There was a time when companies ran
| projects to replace their mainframes. They all largely
| failed. The trend now is to integrate around the mainframe.
| Build new functionality on modern systems and leverage the
| mainframe where it makes sense.
|
| I worked at one company that is trying to replace their
| mainframe. The project is now in its second decade. The
| company has the burden of supporting the mainframe
| application and now the 'modern' application. The project
| is still a few years away from being able to completely
| shut off the mainframe.
|
| Oh and the modern application is also showing its age as
| the business has changed and the modern system built
| assumption in from the mainframe system and in many ways is
| just as inflexible to change as the mainframe app was.
|
| This is why companies aren't scrambling to replace their
| mainframe systems. They are happy to continue paying for
| the high cost of compute on these systems because its still
| cheaper and less risky than replacing the system.
| elzbardico wrote:
| I bet that the "modern" application, given its 20 years
| vintage, is probably a J2EE application running on
| whatever is the modern incarnation of IBM Websphere and
| it was written as a mind-boggling soup of EJB 2.x Entity
| and Session beans.
| technofiend wrote:
| I've been on a couple of successful migration projects,
| both of which moved things to unices. One was motivated
| by the $5 million/yr costs to maintain the mainframe,
| which was replaced by a handful of lowest cost bidder
| unix boxes. The second was regulatory-agency-mandated
| cleanup after a financial fallout, and unlike the
| previous two or three times that company had tried and
| failed to consolidate their risk reporting onto a single
| system, this time it worked. Because it had to. The
| threat of an external regulator was sufficient to break
| down the previous barriers of balkanized system owners
| protecting their turf.
| Melatonic wrote:
| Exactly. Java layer written on top of COBOL.
| ElectricalUnion wrote:
| > It persists in many places due to the deeply ingrained
| belief that, for one reason or another, it would be
| technically, practically, or economically impossible to
| migrate functionality off the mainframe.
|
| It is never technical or pratical reasons, always economic
| reasons. To use contemporary vocabulary, you "just" need to
| replicate a "multi tenant HA cloud environment" to migrate
| from a mainframe at great cost.
|
| > And now we are in a situation where their long held beliefs
| have become true because nobody is around that understands
| how or why the software works the way it does.
|
| Statistically unlikely, most of the business software that
| goes onto said mainframe is in fact very simple and
| straightforward and can be easly ported out, however, the
| real deal is all the integration and high availability logic
| built-in into "the mainframe platform". You're not porting
| that out without replicating said "multi tenant HA cloud
| environment" at great cost.
| wredue wrote:
| >most of the business software that goes into said
| mainframe is in fact very simple and straightforward
|
| Yeah no. I worked on mainframe code for 15 years of the
| last 20 and can tell you that you're wrong. Even reasonably
| simple business lines have cobbled together insane cobol,
| batch and cics screens that would make spaghetti blush.
|
| When you open up a 100,000 line batch program that's just 1
| of 30 cobol programs in that run which is a mess of gotos,
| global mutable state and basically every single other
| generally frowned upon software practice we know about, you
| start to understand the issues.
|
| Moving off of mainframe is practically impossible because
| of it. That other person being voted down is actually
| correct, nobody in the organization actually knows how any
| of it works.
|
| When organizations try to transition away, what ends up
| happening is they get these insane promises of "5 years"
| from vendors (like IBM. Ask me how I know!), but then it
| takes 10 years to transition single systems.
|
| Nothing is documented. So you have business people who have
| no clue how anything works providing high level work flows.
| But then there's always 50 random edge cases or
| interactions they never considered cause the 40 year old
| code just does it.
|
| IT contains most of the business knowledge, but the
| mainframe grey beards are... stubborn. The business hangs
| on to these people because they're seen as insanely
| valuable, not realizing that the grey beards have actually
| been actively suppressing knowledge to only their hidden
| documents, and they've got 8 years till retirement and are
| going to make sure that their job exists at least until
| then by actively sabotaging efforts to change. But also,
| for some reason, the business manager love the saboteurs.
| It's insane to watch.
| znpy wrote:
| > Ask me how I know!
|
| how do you know?
| mschuster91 wrote:
| > But also, for some reason, the business manager love
| the saboteurs. It's insane to watch.
|
| Because they keep the shit running. If you're a bank and
| responsible for _trillions_ of dollars in assets and
| billions of dollars in daily transactions, the absolutely
| last thing you can afford is downtime or, even worse,
| data loss. You 'll not just have to handle a ton of angry
| customers, but in the worst case attract regulatory
| attraction or getting dragged in front of Congress and
| the courts.
|
| Here in Germany, Deutsche Bank is integrating 12 million
| accounts from Postbank to their own IT systems, and it
| has been an utter utter shitshow [1], attracting a lot of
| bad press and the banking regulator BaFin is also
| investigating [2].
|
| [1] https://www.merkur.de/leben/geduldsprobe-fuer-
| postbank-kunde...
|
| [2] https://www.sueddeutsche.de/wirtschaft/deutsche-bank-
| postban...
| pmontra wrote:
| What happens when there are new requirements? An example,
| fiscal legislation changes and programs dealing with
| money have to adapt. Of course a way out is to lobby for
| changes that don't touch the software, but what happens
| when the software must be touched?
| wredue wrote:
| The estimate for carbon tax legislation was 700 hours and
| it took 1600 hours and didn't work correctly for 9 months
| following.
|
| Edit: and for the record, at that point, we were already
| splitting off carbon transactions for their own
| processing because, surprise, energy has lots of
| regulation.
| Zigurd wrote:
| The risk in a reengineering project that comprehensively
| replaces the mainframe is enough to discourage most people
| making that decision. It _could_ be a $3M project that pays
| pack in 4 years after scrapping the mainframe and running
| out the maintenance contract, or it could go over budget
| and take forever to pay back. Your IBM rep has undoubtedly
| run the numbers.
| TheRealDunkirk wrote:
| >> It persists in many places due to the deeply ingrained
| belief that, for one reason or another, it would be
| technically, practically, or economically impossible to
| migrate functionality off the mainframe.
|
| > It is never technical or pratical reasons, always
| economic reasons. To use contemporary vocabulary, you
| "just" need to replicate a "multi tenant HA cloud
| environment" to migrate from a mainframe at great cost.
|
| When your business processes are so ossified by a mainframe
| that you have, say, groups preparing Excel spreadsheets --
| with data formatted from one mainframe screen in 3 columns
| -- for use by another group to input back into the
| mainframe -- with the data reformatted in 4 columns -- you
| know you're never escaping the gravity well of the black
| hole at the center of IT that is "The Mainframe." This is
| just how it's going to be until the company is so
| technically irrelevant that the remains are picked up in a
| fire sale by some PE to sell off to some other,
| tangentially-related company, solely for the IP assets.
| ojhughes wrote:
| I'm not sure how much water the multi tenant HA argument
| holds, these institutions are already doing that on AWS /
| Azure / k8s for the more modern apps. Rewriting all the old
| crusty COBOL code might be a different story.
| dralley wrote:
| Getting the same performance out of AWS as a local
| mainframe is neither trivial nor cheap for a lot of the
| workloads these systems are running.
| jeffbee wrote:
| Getting stupefying amounts of I/O on AWS is as simple as
| turning a knob and getting out your credit card. The kind
| of throughput quoted in the article--48GB/s--is
| achievable on AWS for $250k/year, list price.
| ElectricalUnion wrote:
| I thought such throughput would cost around 30 274 560
| USD/year (60 * 60 * 24 * 365 * 48 * 0.02) on data transit
| fees alone.
| jeffbee wrote:
| Obviously it would be very foolish to use an AWS storage
| backend for an application that was not also in AWS.
|
| That said, it is not at all clear to me that the TCO of a
| maxed-out IBM DS8900F is less than $30 million/year.
| shrubble wrote:
| That is one channel of throughput, and a mainframe can
| have many channels, though.
| dralley wrote:
| But let's say you want that data compressed and/or
| encrypted, you're going to need an awful lot of compute
| to exploit that 48GB/s if it's possible at all.
|
| Whereas on mainframe the service processors can deal with
| it transparently to the CPU using specialized hardware.
|
| And let's say it's financial transactions - fixed-point
| decimal arithmetic. On mainframe, that can be hardware
| accelerated too.
| jeffbee wrote:
| Yes, and it's interesting how Intel is moving in that
| direction with their Xeon line, integrating the QAT
| peripheral for compression and encryption offloading.
| Unfortunately these things are unicorns and that aren't
| generally available in the cloud, either.
| ghaff wrote:
| Well, the general approach over the past 30 years or so
| has just been to mostly go with generic x86 hardware
| which would get predictably faster year-over-year and
| software could be written pretty generically for those
| platforms. With performance growth slowing, one of the
| answers has been to have more heterogenous and special
| function hardware and the software people will just have
| to deal with it.
| WJW wrote:
| Getting (and maintaining) a local mainframe in the first
| place is also not cheap though. I won't hazard a guess to
| which one might be easier to keep up and running, but at
| least in my bubble it would be 100x easier to hire more
| k8s admins than to hire qualified mainframe admins.
| jmartrican wrote:
| Before we even get to the costs of a migration, what is the
| reason for the migration?
| ghaff wrote:
| It's what would be cool and would look good on my resume.
| (Only half /s)
| TheRealDunkirk wrote:
| Over my 30 years, mostly in Fortune 250's, I've seen 3
| mainframe migrations fail. If you're part of the team,
| the trick is to get another job before people realize --
| in year 4 of your "5-year" migration -- that it was never
| going to work, because managers in other parts of the
| business will never allow their headcount to be reduced
| by better IT workflows.
| jmartrican wrote:
| Nailed it ^^^
| mberning wrote:
| People may assume that a lot of this mainframe software is
| "running just fine" but nothing could be farther from the
| truth. Often you will find that this software was fine when
| it was written 40-50 years ago, but now it has a lot of
| deferred maintenance and upgrades which are now a "big
| problem". Is it a problem that an application that can move
| millions of dollars is only secured by a strictly 8
| character alphanumeric password? You be the judge.
| justapassenger wrote:
| Updating the software to support stronger passwords or
| rewrite it from scratch, on a totally different platform?
|
| I don't think you're making argument think you're making.
| mberning wrote:
| You have no idea. This is not some database field that
| you can just alter with one statement and update a field
| on a screen. Things like this get hardcoded into hundreds
| of thousands of lines of assembler and cobol and need to
| be changed and tested everywhere. With no automated
| testing or other tools to mitigate the risk. It is an
| absolute nightmare. And 5 or 10 years from now it will be
| way worse because working on a mainframe is a deadend
| career and very few people are learning it.
| justapassenger wrote:
| I'm not saying it'll be easy. But what's even harder is
| rewriting 50 year old software, with all the bugs that
| others relay on now (both people and software), wanky and
| complex business logic, etc, etc.
|
| I'm not saying that you should stick to mainframe. But
| rewriting it because you need to support strong password
| is not a reason to do it.
| ghaff wrote:
| Certainly. A _good_ reason for a migration is that we are
| in a place where we need to do _something_ major--whether
| that 's modernizing the software on the mainframe that
| isn't doing the job, moving everything to new platform(s)
| (including potentially cloud), or some combination of the
| two--the latter being a pretty common strategy these
| days. At that point, just adding more duct tape is
| probably the wrong approach, at least in the medium to
| long term.
| sofixa wrote:
| Well, for one, lack of capable personnel. Nobody learns IBM
| Mainframes in school, and most jobs for them want
| experience. Furthermore, they're not sexy but boring, with
| paywalled docs and similar shitty "enterprise" techniques,
| making it so very few people actually want to or manage to
| learn them. And it's a dead end, career-wise (very few
| companies use them, so changing jobs isn't as easy as more
| widely used tech).
|
| So what will happen when in 10 years the last people you
| have that know how it works are retired?
|
| Not to mention tech debt.
| Solvency wrote:
| Completely untrue. Listen to everything Cameron Seay has
| ever said about the subject. Mainframe programmers are
| wanted more than ever.
|
| https://www.youtube.com/watch?v=hxxyORcU3Hs
| https://blog.share.org/Article/mainframe-visibility-ibm-
| cham...
| sofixa wrote:
| Which part is untrue? That there isn't enough personnel
| or that it's a severely limiting career choice? Because
| what you're saying confirms the first one, and for the
| second one, not a lot of people dream of working on
| legacy stuff in a big organisation, and those are your
| only choices if you're a mainframe programmer. Say in the
| US, for mainframe work, there are what, 30 banks? 5
| airlines? 20 insurance companies? Not a lot of choice,
| and it's doubtful they'll offer "perks" such as remote
| work.
| lotsoweiners wrote:
| Lots of government too. I worked at a government agency
| that ran it's business off of mainframe. I worked there
| as a web developer and we had to consume data from the
| mainframe in our web apps. Very tedious process.
| hindsightbias wrote:
| Some people just like to see the world burn. Move fast,
| break things. Like my bank, ATM, pharmacy, shipping mgmt,
| hospitals, paycheck services, utility grids...
|
| And then in 5 years someone can rewrite it all again
| because something else will be cooler and my code will be
| technical debt.
| gumby wrote:
| > 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.
|
| The Main Frame of yore was ... one of the 19 inch racks the
| computer was made out of (the main one, typically with the ALU
| and registers in it). And those racks were used because that
| was how phone systems were built (phone systems had a lot more
| repeated / regular structure than something like a computer,
| though of course everything has converged). The "frame"
| nomenclature came from the phone system too.
|
| So "normal servers today" got the rack from the mainframe, the
| mainframe didn't adopt it because of how datacenters were
| built. All the familiar stuff (raised floors, chillers, backup
| power, fire suppression, controlled access doors and so on)
| come from the mainframe world.
| electroly wrote:
| The granddaddy of mainframes, System/360, was never in 19"
| racks. IBM first introduced the use of 19" racks in their
| midrange lines. What we currently call IBM z didn't adopt
| standard racks until the 21st century.
| hinkley wrote:
| Most of this Cloud technology we like to go all atwitter about
| is a retread or a redesign of software that's been on
| mainframes for thirty years. The old farts must laugh
| themselves silly looking at us acting like we discovered a
| large white object orbiting the earth.
| jjtheblunt wrote:
| SUN used to say The Network is the Computer...that always
| reminds me of what is called "cloud" the last 10+ years.
| dbcurtis wrote:
| Oh yeah, in a past life I was a CPU logic designer for walk-
| in, refrigerated mainframes. I was always amused by
| youngsters thinking they had invented things like pipelines
| and branch prediction. Seymour Cray and Gene Amdahl were
| prolific inventors.
| Tuna-Fish wrote:
| I posit that this retreading of old paths was very good for
| the industry.
|
| All the truly important CPU design features were first
| invented using discrete logic for mainframes and
| minicomputers. Then, 20 years later when it became possible
| to fit them onto a single chip, they were all out of
| patent, which is precisely what made the early
| microcomputer industry so competitive. When none of the
| important stuff could be patented anymore, you could only
| compete on merit, not by getting a government enforce a
| monopoly on some critical piece of your design.
| dbcurtis wrote:
| I think you make a good point. Although I have seen
| patents for reinventing something in an expired patent :)
| dbcurtis wrote:
| And Bob Barton deserves mention for being extremely far-
| sighted.
| queuebert wrote:
| I posit that most tech companies make money by poorly
| recreating old technologies for use by younger people
| ignorant of the old ones.
|
| E.g. how many variants of IRC have we had now? Usenet? VMs?
| hinkley wrote:
| I think we need history classes in programming, and
| possibly comparative literature classes but for code.
| vyrotek wrote:
| Can confirm. My old father who works on these mainframes
| laughs every time.
| reacharavindh wrote:
| I think its hardware is what enables such reliable software.
|
| Hot plug CPUs, memory modules, and DASDs. All survive the
| failure scenario gracefully.
|
| Good luck trying to do that on a rack of x86 servers.
|
| I think as in most engineering things. They do a different
| trade-off and cater to a different niche while x86 servers are
| the mass market consumables that most workloads -should- be
| using. The mainframe CPUs go for the widest IO capabilities,
| insane cache sizes and hardware offload because that's what
| their target audience(banks, insurance companies, airline
| ticket systems) need.
|
| Their parallel sysplex clustering solution is an engineering
| marvel but also tightly coupled to their hardware.
|
| In some ways, the IBM mainframe is the Apple of niche critical
| enterprise computing. They are also the ancestor of cloud
| computing in paving the way for "pay per use" cost models and
| multi tenancy.
| bombcar wrote:
| x86 just made it so the whole computer could drop out of the
| "cluster" which greatly simplifies the hardware design but
| the result is NOT a "virtual mainframe" as the software
| becomes exponentially more complicated if you want "all
| power".
| xahhkakappy11 wrote:
| 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 wrote:
| Check out C# LINQ, or Haskell postgresql-typed.
|
| https://learn.microsoft.com/en-
| us/dotnet/csharp/programming-...
|
| https://hackage.haskell.org/package/postgresql-
| typed-0.6.2.4...
| toyg wrote:
| God, I hate LINQ. When dealing with code that uses it, it's
| like you're reading a detective story where suddenly TYGER
| TYGER BURNING BRIGHT IN THE FOREST OF and then back to
| murders until WHAT IMMORTAL HAND OR EYE and then murders
| again.
| leprechaun1066 wrote:
| Or q:
|
| https://code.kx.com/q4m3/9_Queries_q-sql/#93-the-select-
| temp...
| SoftTalker wrote:
| pl/SQL has good support for inline SQL.
| bob1029 wrote:
| I've always looked at IBM like an even more extreme version of
| Microsoft. I'd probably have us on their path if the cost and
| knowledge weren't a massive barrier to entry. I know IBM has
| some cloud thing for us baby startups, but I sure as hell can't
| figure out how to use it or if our customers are even aware of
| it.
|
| Vertical integration of the business into one magic box is a
| perpetual dream of mine. Bonus points if I can yell at exactly
| one vendor if anything goes wrong.
| redandblack wrote:
| Used to be great for vector processing for numerical analysis,
| although not sure anymore
| js8 wrote:
| Since z13 vector instructions are supported again. But I
| doubt anybody uses them.
| edelsohn wrote:
| The original vector facility is gone, but the Z Vector
| Extension (VX) is utilized by AI/ML software, such as
| NumPy, OpenBLAS, etc.
| Scubabear68 wrote:
| 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.
| SoftTalker wrote:
| I had always heard that most companies leased their mainframes.
| Sort of how most airlines lease their aircraft.
|
| Maybe a few really big organizations would buy them outright.
| neverartful wrote:
| 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 wrote:
| 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.
| lasermike026 wrote:
| "A bank's lifeblood isn't money--it's data." Yeah, tell that to a
| failed bank.
| kkielhofner wrote:
| "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
|
| [1] - https://uptime.is/99.99999
| eeegnu wrote:
| I would guess that they did the calculations, but interpreted
| it as "5 nines after the decimal point", when it's really "5
| nines in total".
| coleca wrote:
| 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.
| ooterness wrote:
| Looks like they've updated the article to correct this. It now
| says, "a bit over five minutes' worth of outage per year".
| rob74 wrote:
| > _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.
| hinkley wrote:
| 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.
| dralley wrote:
| 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 wrote:
| 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/Intel_SHA_extensions
| madmulita wrote:
| 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 wrote:
| 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.
| StillBored wrote:
| "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 wrote:
| 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.
| Tomte wrote:
| IBM teaches you to use and program those:
| https://www.ibm.com/z/resources/zxplore
| AlbertCory wrote:
| 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.
| filereaper wrote:
| 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 wrote:
| > 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-...
| rawgabbit wrote:
| 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).
| mousetree wrote:
| > Today, IBM is the only mainframe manufacturer
|
| AFAIK Fujitsu still manufacture mainframes
| timbit42 wrote:
| Also HP NonStop (Tandem).
| osullivj wrote:
| Yes, I've worked on Fujitsu ICL clones running VME.
| dralley wrote:
| 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.
| steveklabnik wrote:
| 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.
| zozbot234 wrote:
| 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.
| msh wrote:
| I think its only IBM people who calls computers midrange ;)
| hindsightbias wrote:
| 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.
| pdw wrote:
| This is an interesting overview of mainframe vendors and how
| many customers they might have:
| https://arcanesciences.com/os2200/app1.html Most of the
| "dwarves" are now using emulation...
| stuff4ben wrote:
| 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.
| dreamcompiler wrote:
| 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.")
| lizknope wrote:
| 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?
| toast0 wrote:
| I started my tech career as a student worker at my school
| district's office. They had a Unisys mainframe managing student
| and employee records; around 1998, they replaced the old system
| which was about 3 feet tall and maybe 20 feet long, with a 4U
| dual processor Pentium Pro running NT 4 with a Unisys emulator.
| Seemed to work just about as well, but the operator console
| seemed a lot less fun. Still interfaced with the giant impact
| printer to print out grades and payroll.
| dboreham wrote:
| > I've never used or even seen a mainframe in 26 years in the
| tech industry.
|
| 40 years here. Although in theory I've used a mainframe in
| college, but it wasn't IBM (Burroughs) and just seemed like "a
| computer" at the time. I also worked a bit on a terminal
| emulator for ICL mainframes, so probably at least logged in. So
| 40 years of saying "I wonder if the mainframe people already
| have a solution to this?"
|
| Probably mainframes haven't been much used for HPC since the
| transition to Cray in the 70s.
| osullivj wrote:
| Also 40 years, 25 in banking. Done several Unix to Z/OS, and
| Windows to VME integration projects.
| Hikikomori wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Solvency wrote:
| Listen to this episode "Mainframes are still a big thing" --
| 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.
| tyingq wrote:
| 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 wrote:
| 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 wrote:
| It is already available, https://www.ibm.com/products/z-and-
| cloud-modernization-stack
| ghaff wrote:
| 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 wrote:
| 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.
| denton-scratch wrote:
| 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.
| sedawk wrote:
| Thank you for sharing, it was an excellent read!
| brianzelip wrote:
| 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
| myth2018 wrote:
| 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.
| NelsonMinar wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-24 23:02 UTC)