[HN Gopher] The mainframe is alive and thriving
___________________________________________________________________
The mainframe is alive and thriving
Author : rbanffy
Score : 49 points
Date : 2021-03-11 14:25 UTC (8 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| xirbeosbwo1234 wrote:
| I certainly question the orthodox view that software should be
| fault-tolerant and horizontally-scalable. If programmer time is
| more valuable than machine time, then why can't my team get a
| single server with a few TiB of RAM and a few hundred cores and
| forget all the gnarly problems of distributed computing? Why do
| we accept that our hardware is unrelaible and then spend so much
| effort making our software tolerate failure?
|
| I do not know whether or not mainframes are the right solution,
| though. I don't really know anything about them. I don't know
| whether or not the architecture is the correct approach.
|
| >IBM has grown usage as measured by MIPS, a method of calculating
| the raw speed used, by 350% over the past ten years.
|
| That's an awful metric. MIPS isn't even a good way of measuring
| aggregate performance and aggregate performance is a terrible way
| of measuring adoption.
| KaiserPro wrote:
| I know its not trendy, but, if you want to not bother writing
| software to handle redundancy, you can pay IBM to do it in
| hardware.
|
| Seriously. if you pay IBM for a couple of z series machines, you
| can link them together in step, and literally blow one up, and
| you'll only loose a certain number of CPU cycles.
|
| sure they are expensive, but its cheaper than buying a team of
| ten engineers for x years to make K8s do the same thing.
| bearjaws wrote:
| Later in the article it describes many companies stance on
| mainframe, hybrid cloud and cloud.
|
| Hybrid cloud just means you have all the security problems of
| hosting your own infra, AND all the security problems of the
| cloud. Not to mention other non security problems of both
| systems.
|
| When these CIO / CTOs make this "middle of the road" decision,
| they are dooming their tech budget to spend more on
| infrastructure and processes than actual product.
|
| It's one thing to have a "we are both until we finish migrating
| to one" but to try and maintain both forever is just punting the
| problem to the next person.
| gumby wrote:
| The very first sentence contains a glaring error when it lists
| the "seven dwarves" (the other mainframe companies) as being
| "Burroughs, Unisys...". Unisys was formed in the 1980s from the
| two remaining "dwarves", Burroughs and Sperry (which itself had
| previously merged with Remington Rand).
|
| By that time there were a few other mainframe class
| manufacturers, most notably Tandem and Amdahl.
|
| Notably missing (and most relevant to the 2020s tech scene) was
| DEC, who by the late 60s was making smaller mainframes as well as
| minicomputers. What makes them different was their decision to
| tae a different, and what Clay Christainsen would call disruptive
| path. And while highly influential they were themselves nuked by
| a new class of disruptive companies.
|
| IBM has reinvented itself several times over in its almost 150
| year history. Not sure the current one is successful, but I
| suppose it's still too soon to tell.
| srameshc wrote:
| Since most of the mainframe projects goes to big tech consulting
| cos, as a developer with many years of mainframe experience who
| these companies don't want to hire or have moved to unrelated
| work, what can that developer do provide consulting or other
| business opportunity around mainframes ? Asking for a friend.
| 656565656565 wrote:
| Root causes of the perceived mainframe problem as I see it are:
|
| 1. It's difficult to obtain skilled personnel, that's it.
|
| Why, because you can only truly learn mainframe technologies on a
| mainframe. Hercules and all the things that IBM have done
| themselves such as MTM, VS Code extensions are not enough. The
| barrier to learn mainframe technologies is too high.
| the_only_law wrote:
| Curious what VS Code extensions have been made for mainframe
| stuff? Sounds like fun to play with.
|
| I agree with your main point though. Occasionally I'll see
| someone recommended people to learn COBOL to get a job as if
| the language is the most relevant part of that industry.
| 656565656565 wrote:
| Zowe and Z Open Editor for integration into Z/OS datasets and
| UNIX services and support for native datasets and file type
| editing.
| taylodl wrote:
| New development on the mainframe started tapering off in the mid
| 1990's. So here's my take on IBM's list:
|
| - 45 of the top 50 banks
|
| - 8 of the top 10 insurers
|
| - 8 of the top 10 telcos
|
| - 7 of the top 10 retailers
|
| - 4 of the top 5 airlines
|
| All had significant operations prior to the mid 1990's and so
| have extensive mainframe investments that are very difficult and
| costly to migrate from. I know. I work for one of the top
| electrical utilities in the United States and at the heart of our
| customer operations lies an IBM mainframe. We're in the midst of
| launching a multi-year, billion dollar program to replace that
| mainframe. We've been talking about doing this for _years_ and
| are just now pulling the trigger on it. There 's still time to
| tell whether we actually go through with it or not, or get $100
| million into the project and realize we're looking at a $1.5
| billion - $2 billion effort and abandon the project.
|
| I would not call this state of affairs _thriving._ Is the
| mainframe alive? Yes. Is it thriving? No. Most CIOs are looking
| for a means for retiring those assets.
| Pet_Ant wrote:
| I'd be interested in when was the last time an organisation
| with no existing mainframes adopted them. Do they have a net-
| new value proposition?
| taylodl wrote:
| Given the cost of mainframe operations vs. cost of cloud, no,
| I can't imagine anyone adopting a mainframe. The mainframe is
| extremely _expensive_ compared to say, AWS - especially if
| you 're running AWS' auto-managed services. Let me put it
| this way - we're looking at a multi-year, $1 billion project
| and we're able to justify it. Keep in mind too that we're a
| regulated utility and the regulators agree with our analysis.
| Trust me, whatever your AWS bill is it's a pittance compared
| to what your IBM bill would be.
| closeparen wrote:
| I'm too young to have used one, but from what I've read, it's
| the programming model of a single machine with the scale and
| resilience of a distributed system.
| dralley wrote:
| A mainframe is effectively a mail-order on-premise cloud,
| from the hardware up, developed 3 to 4 decades before
| things like OpenStack or Kubernetes. Mainframes supported
| hardware-accelerated virtualization way back in the early
| 1970s. You could have thousands or tens of thousands of VMs
| running on a single machine (granted, a machine the size of
| a room).
|
| One of my older greybeard coworkers tells stories of how
| sometimes an IBM employee would show up at 6 AM to replace
| a water pump (or some other component) that had phoned home
| the night before to report that it was beginning to fail.
| The hardware is super reliable and resilient but also
| heavily instrumented to detect & resolve failures before
| they caused problems. And they would send their techs out
| to pre-empt those problems before the customer ever noticed
| anything.
|
| Not that it would have been too much a problem if it had
| failed - because there was so much hardware redundancy
| built into those machines.
|
| One of his other stories, is a tech demo that IBM did for
| his company, where they put a mainframe in the back of a
| trailer and would drive it around to customer sites. The
| demo consisted of starting a huge computation on the
| machine, and pulling up a screen that showed the available
| hardware resources, then a tech would reach into the
| machine and start pulling out CPUs and RAM, and you'd watch
| live as it detected that the hardware had disappeared and
| shuffled the jobs around to other hardware resources
| without crashing. And then the tech would start swapping
| hardware back in, and it would add the resources back into
| the pool and start doing work with them once again.
|
| All handled by the hardware and the OS.
| 908B64B197 wrote:
| > Basically, rather than handling redundancy in software,
| they have a ton of hardware-level redundancy to get the
| high uptime #s.
|
| But at what cost? Instead of getting suppliers to out-bid
| one another you are now stuck in a single supplier
| situation. [0] Building the redundancy in software allows
| you to run on commodity hardware that can be purchased
| from anyone.
|
| [0] https://www.gwern.net/Complement
| closeparen wrote:
| Writing a cloud-native distributed system for everything
| is not free; software development is a bigger expense
| than raw capacity for many use cases.
| nn3 wrote:
| I worked at a place that had a little mainframe
| (essentially a large server) from IBM to port some
| software to. Most of the people didn't know anything
| about mainframes.
|
| On a hot day they had an air condition problem in the
| data center and had to turn off a lot of machines. They
| tried to turn off the mainframe using the big button, but
| it just kept running. Then they decided to pull the power
| plug. System still kept running. It turned out it had an
| built-in UPS. After some more attempts they finally
| managed to turn it off.
| rbanffy wrote:
| One of the reasons for that instrumentation is that they
| used to be operated in a cloud-like environment where the
| machine is sliced into smaller ones and time on them is
| billed much like cloud computing is billed today.
| tablespoon wrote:
| > One of the reasons for that instrumentation is that
| they used to be operated in a cloud-like environment
| where the machine is sliced into smaller ones and time on
| them is billed much like cloud computing is billed today.
|
| IIRC, that's still true. I think IBM mainframes are
| typically leased, and the customer is billed on usage.
|
| There's some complexity to this, where I think the
| metering only applies to programs in the "traditional"
| mainframe environment, while things running on the
| mainframe Linux environment are exempt from metered
| billing.
| rbanffy wrote:
| They still pay for licensed capacity when running things
| like z/OS. The machine is shipped "full" but the hardware
| has to be activated by paying a license.
|
| One of the interesting features I heard when they
| launched z15 was that, if one needed to restart a
| partition, it could tap unlicensed CPUs to start faster
| and then go back to its licensed capacity.
| ghaff wrote:
| I don't know the details of billing these days; it's been
| a while since I followed the space. But when Linux came
| out on Z, it ran on something called IFLs. These were not
| AFAIK physically different from the processors running
| more traditional IBM workloads. They were simply priced
| at a lower level. I don't remember if there was capacity
| on demand for Linux workloads or not.
| zozbot234 wrote:
| > it's the programming model of a single machine with the
| scale and resilience of a distributed system.
|
| Single-system-image clustering delivers on that promise
| with no dependence on proprietary platforms. Linux is now
| slowly getting the underlying features needed to enable
| this (e.g. process migration and checkpointing, namespacing
| of all system resources), largely as a side-effect of
| earlier developments such as cgroups. You can already
| experiment with Linux-CRIU to see what the basic tech is
| like, it's not fully mainlined yet but it's slowly getting
| there.
| KptMarchewa wrote:
| Just imagine if cloud provider gave you same problems, and
| moving from GCP to AWS ment 5 years and billion dollars
| project.
| kjs3 wrote:
| Anecdata. I work for a top 10 bank. The mainframe isn't going
| away here. We're investing in new development, new tools, and
| just (last 2 years or so) had a hiring spree to support those
| efforts. I am also very familiar with strategy at several other
| peer banks (they're doing the same thing), a number of the
| telcos (same) and 2 of the major airlines (who will look at you
| like you're insane if you suggest they get rid of their
| mainframe).
|
| I've been hearing "mainframes are dead" since the 1980s. The
| market for them has dramatically changed, but by the same token
| there's just more people in IT who have no clue what the
| mainframes do from a business perspective, so "obviously" it's
| a dead end.
| paol wrote:
| That doesn't make it thriving though. It's a niche that
| continues to get smaller, albeit at a very slow rate.
| kjs3 wrote:
| I don't dispute that; every niche has a growth phase and a
| decline phase. See: Minicomputers or RISC workstations.
| However, given a nearly 60 year run so far, and an
| expectation that there's a couple more decades of life it
| it, we should be so lucky if whatever niche we work in
| 'fails to thrive' like that.
| wbl wrote:
| The replacement for a RISC workstation was an Intel one
| serving the same role for the same kind of customer. The
| mainframe doesn't have that sort of path.
| zozbot234 wrote:
| > The mainframe doesn't have that sort of path.
|
| Datacenter-scale compute on non-proprietary platforms
| (e.g. leveraging OCP standards and best practices, which
| have been developed w/ significant input from FAANG and
| 'cloud' vendors) can easily tackle any mainframe
| workload. The implied path is obvious.
| meepmorp wrote:
| Their anecdata beats your unsourced generalization.
| kjs3 wrote:
| No, mine is anecdata too, just more of it. And neither
| wins because there's actual data out there about the size
| and velocity of the mainframe market. I just don't much
| care to look it up every time someone makes an unfounded
| declaration that mainframes are dead. And, since we're
| keeping score, zero content snark is bottom of the heap.
| meepmorp wrote:
| I was saying your anecdata beats the other guy. I
| definitely agree the mainframe ain't dead.
|
| > And, since we're keeping score, zero content snark is
| bottom of the heap.
|
| That's just hurtful, man.
| Guest42 wrote:
| I think the difference is that the mainframe isn't going
| anywhere and the large companies themselves have been
| thriving and will likely continue to do so. My employer has
| a number of them and they work great although it's
| challenging to find the developers. If it was my decision
| to migrate I'd be hesitant because it seems as though
| infrastructure is priced low enough to convince people to
| switch but then will likely creep up over time in either
| prices or lock-in.
| ralphc wrote:
| To someone going into IT or programming at a young age (so,
| not me), would you recommend them to get into COBOL and
| mainframes? Will it be a career option for 10+ years?
| konjin wrote:
| Cobol is alive the same way Latin is. Unless you're sure
| you can get a job in the Vatican you're screwed if you
| learn it.
| gumby wrote:
| I understand and agree with your point but hey, I got a
| lot of benefit from learning Latin, arguably more than I
| got for learning Lisp (which was is what I used for the
| first 10 years of my career. It was a fun and quite
| lucrative period).
|
| For graduates of my (very small) high school, Classics
| was the number one choice of college major and though I'm
| not in close touch with all of them I never heard any of
| them claim that they had made a mistake.
|
| Cobol is sort of like Lisp* in that regard: the options
| are quite limited, but as the supply is too you'll
| probably do better than fine financially.
|
| * wow is it painful to write that.
| aduitsis wrote:
| Unless your job is to teach Latin :). Quite a few schools
| around the world are teaching Latin or even Ancient
| Greek.
|
| Are Latin and Ancient Greek dead? Ostensibly yes. But not
| useless. Besides teaching, there is a tremendous amount
| of books and texts written in Latin and Ancient Greek. To
| study them, one would invariably need to learn the
| language.
| hindsightbias wrote:
| System Z is not just COBOL. C/C++, etc and Linux has run
| over there for years.
|
| If I could go back 30 years, I'd have made more money,
| slept better and would have more hair on Z. Not that I can
| say for a new generation but now that everyone is a "full
| stack" developer and the stack changes every few years, I'd
| still prefer longer term niches if I was 22 again.
| retrac wrote:
| The following is hearsay based on a few people I know in
| that field, so take it with a grain of salt.
|
| These days, most companies seem increasingly
| resigned/accepting of the fact that they're not going to
| find young, dynamic COBOL programmers in the wild. On top
| of that, old-school COBOL has a knack for creating
| idiosyncratic software architectures. Learning how some
| particular monstrosity was taped together is more important
| than the language itself, which is brain-dead simple. And
| there are few such COBOL codebases out there in the wild to
| read.
|
| The result is a move towards hiring and training good
| programmers in-house, quite counter to the general trend in
| the industry. Which makes for good job security but also
| makes it hard to enter directly.
| monocasa wrote:
| Out of curiosity, given the nine figure migration costs you're
| throwing around, why bother? How is it hurting you day to day
| (to the tune of a billion dollars) enough to migrate. Obvs all
| else being equal there's no way you'd start on mainframe today,
| but now that you have it why jump off?
| was8309 wrote:
| 'Vendor Lock in' was also a problem. When it came time to
| renew leases/licenses, IBM could say whatever. There was no
| recourse but to pay. Funny/sad that we believed Oracle when
| they said they were the solution to 'Vendor Lock in'. The
| billion+ dollar grift was thick.
| tannhaeuser wrote:
| It's also not very clear what target environment to migrate
| to with costs in that ballpark and expectations for longevity
| comparable to mainframes. Java? Cloud (lol)? Web (lol)? Just
| blinks of an eye compared to what these are supposed to
| replace. And last decade's post-standards rush hasn't exactly
| helped either so POSIX etc might not help much.
| taylodl wrote:
| You're not wrong. Oracle is making a big play in the
| utility space and so they have a lot of solutions available
| that can be hosted on-prem or in their "cloud" - which
| really is somebody else's data center. Their solutions are
| all JEE based and run on WebLogic.
|
| What gives me pause for concern is the JEE/WebLogic
| platform is now as old as COBOL was in the 1980's when we
| were calling it "dead" and we're still looking at 5-7 years
| of development and migration time to get to the new system.
| What will we think of JEE/WebLogic in 2030? My biggest
| concern is they're going to spend all this money to get
| onto another soon-to-be-legacy platform that they're going
| to realize on day 1 they need to start planning on getting
| away from. This is why mainframes have been so "sticky."
| varikin wrote:
| I worked for a large retail company that had mainframes, our
| own DCs, and a large cloud presence. There was and still is
| an ongoing project to retire the mainframes. From what I
| heard, the mainframes don't always solve the problems we have
| today, such as realtime information about all the stores and
| inventory. They are also harder and harder to get people that
| know and understand them to fix issue or work on integrating
| them into newer systems. Finally, there was a serious power
| outage at a DC after I left and the backup generators did not
| kick in properly. And the mainframes and other older hardware
| was not booting properly. That is a major risk that you don't
| have with the cloud, or even more modern application design
| with your own hardware. As long as you have the data, you can
| just provision new hardware and go. It would be expensive and
| time consuming, but this is a Fortune 50 company and they can
| pay the cost if it happens.
| neverartful wrote:
| "harder and harder to get people that known and understand
| them"
|
| This is not surprising. IBM could fix this overnight if it
| wanted to. How? By providing no-cost educational licenses
| for its mainframe software for use on Hercules. Why don't
| they do this? I believe that there are 2 reasons why: (1)
| they're terrified of people running their production
| mainframe workloads on a non-mainframe, and (2) I believe
| that some of IBM's existing mainframe customers keep
| pressure on IBM to prevent them from opening up the
| 'mainframe secrets to the world'. The second point is the
| belief in security through obscurity. I don't have any
| evidence to back up this belief, it's just my theory.
|
| The other thing that IBM could do is provide low-cost (or
| even no-cost) options to real mainframe environment over
| the internet. I know that they have some of this, but it's
| too restrictive. I'm talking about opening it up like AWS
| did with free for 1 year. But that's expensive? It wasn't
| free for AWS to do it, and it wouldn't be free for IBM to
| do it. However, it would eliminate the biggest barrier to
| entry for new talent.
|
| Getting back to my theory of security through obscurity, I
| believe that this is also in play with AIX and iSeries
| (AS/400). A number of years back, I bought a used RS/6000
| workstation on eBay for the purpose of learning and I
| contacted IBM to get a licensed copy of AIX 4.3. It was as
| if I were speaking in tongues trying to get through to
| them.
|
| IBM: "Sir, what's your IBM customer number?" Me: "Umm, I
| don't have one. I'm just an individual who bought a used
| RS/6000 on eBay." IBM: "We can't sell you an AIX license
| without a customer number." Me: "Ok, well give me one."
| IBM: "What's the name of the company?" Me: "There is no
| company. It's just me as an individual who wants to learn
| about the technology." IBM: "We have to have a company
| name." Me: "Put my name as the company name." ... ... ...
| Eventually, get assigned an IBM customer number and did
| finally get AIX CD-ROMs from IBM.
|
| I can only imagine that it would be 10x worse to do
| something similar with their iSeries (AS/400). When you see
| this over and over, I'm left with the conclusion that IBM
| doesn't want individuals getting their hands on their
| hardware or their software.
| pickle-wizard wrote:
| IBM does have the zPDT for running an emulated mainframe
| on Intel hardware for development, and education
| purposes. However it is not free. IIRC it is about
| $1K/year. Not a bad cost for a business, but too
| expensive for someone to go learn on their own.
|
| You are absolutely right about how hard it is to do
| business with IBM. I worked for IBM for nearly 7 years,
| running a small datacenter. It was such a pain in the ass
| every time I needed to order something. IBM sales and
| support process is very high touch, and is designed for
| the large enterprise that has a team of IBM sales people
| supporting them. If you are that customer it is not a big
| deal because you have someone to navigate the process for
| you. If you are a smaller customer, they want you to go
| through a VAR. Which is still a pain in the ass.
|
| Windows NT and the AS/400 are about the same age. This
| pain in the ass sales process is a big part of why
| Windows NT won. The IBM sales people didn't want to sell
| it because you didn't need to buy services with it and it
| was too hard to buy on your own. Where as if you wanted
| Windows NT, you just bought a copy of Windows NT and
| installed it on an easily available PC.
|
| We won't even talk about the time I tried to use IBM
| Smart Cloud Enterprise.
| goatinaboat wrote:
| _They are also harder and harder to get people that know
| and understand them_
|
| Bootcamps saturating the market with webdevs armed with
| skills that barely last a year, when they could be training
| people with skills that would see them employed for a whole
| career.
| wnevets wrote:
| Could you even have bootcamps for mainframes?
| rbanffy wrote:
| There is a yearly Master The Mainframe competition for
| students (but anyone can participate, get an account and
| do the exercises and go through the materials). It's fun.
| z/OS is completely alien for someone who grew up in a
| Windows/Unix ecosystem.
| lotsofpulp wrote:
| The pay for people who know and understand mainframes is
| insufficient to incentivize people to become
| knowledgeable and familiar with mainframes.
|
| It has nothing to do with bootcamps. If the mainframe
| knowledge was in sufficient demand, then they would be
| selling mainframe training too since people would be
| wanting to buy it.
| goatinaboat wrote:
| _The pay for people who know and understand mainframes is
| insufficient to incentivize people to become
| knowledgeable and familiar with mainframes_
|
| Maybe, but it may also be true that people simply aren't
| aware that mainframes exist or these jobs exist.
| tablespoon wrote:
| > It has nothing to do with bootcamps. If the mainframe
| knowledge was in sufficient demand, then they would be
| selling mainframe training too since people would be
| wanting to buy it.
|
| A large part of that is probably due to American
| management practices, where the preference is to skimp on
| maintenance until they find themselves in a crisis. They
| don't want to pay for what they need, they want to pay
| for whatever is cheap.
| [deleted]
| taylodl wrote:
| That's a good question!
|
| The reason given is it's getting difficult to find COBOL
| programmers and the platform isn't as agile as other
| platforms. I have to admit that IBM is working to make the
| platform more agile and you can do more than run COBOL - you
| can run Java and Linux on Z. I've been in IBM training
| sessions where I've been running Linux on Z and then running
| Docker on top of that and unless you had told me otherwise
| the experience was normal: you're running bash, running
| Docker and everything runs as you'd expect.
|
| BUT - the problem is the core of our system is written in
| COBOL. There's still CICS, JCL, Copybooks and DB/2 and those
| who can work with those technologies are now within 10 years
| of retiring and the new generation doesn't know them or have
| much of a desire to learn them. Heck, I'm part of the first
| generation of PC developers from the mid-1980's and I've
| never done any mainframe development!
|
| The thinking then is we'd better jump off before all these
| people retire and you end up having to pay $300+/hr for
| resources capable of working with these legacy technologies.
| Pay now and buy yourself a new technology set and new
| capabilities or pay later and just keep the system running.
| ghshephard wrote:
| Re: The reason given is it's getting difficult to find
| COBOL programmers
|
| Cobol programming is a skill that is trivially taught. Any
| student with a Cmpt. Science degree from a credible
| institution, given a curriculum, can learn any programming
| language in a month with a bit of focus/appropriate
| curriculum. Can pick up the necessary frameworks in a
| reasonable period of time. Then it's just a matter of
| teaching them the line of business, and the practices and
| procedures.
|
| I would claim that, given twelve months, you could teach a
| cohort of recent Cmpt. Science graduates all the skills
| they needed to be successful in any
| Insurance/Banking/Finance programing environment.
|
| And these are developers that you can then pay a very
| reasonable salary - say, $150K/year - which is $75/hour,
| not $300/hr, at the cost of 1 year of salary as they come
| on board, come up to speed (say at an out-of-college salary
| of $100K/year.) - You need 1,000 of those developers -
| that's an up-front cost of $100mm, at which point you have
| your developers.
|
| Compared to a multi-billion dollar transition cost off of a
| mainframe, I know which one I would chose if I were the
| PHB.
| throwawayboise wrote:
| > Cobol programming is a skill that is trivially taught.
|
| And this used to be very common. My first job out of
| school in the early 1990s was with a "big consulting
| firm" they had a boot camp where they taught COBOL to
| batches of new hires. You did that for a month, and then
| were deployed to a client site writing COBOL about 50
| hours a week.
| xirbeosbwo1234 wrote:
| Why ditch the mainframe? It sounds like the software is the
| problem here, not the hardware.
| OldHand2018 wrote:
| > the new generation doesn't know them or have much of a
| desire to learn them
|
| On one hand, I'd say that this is true. But on the other,
| I'm not so sure.
|
| 15 years ago, I interviewed for a job that turned out to be
| for building software on OpenVMS running on Alpha.
|
| I had honestly never heard of either thing.
|
| The interviewer, who would be my manager, said that isn't a
| problem, it's just a computer that works a little different
| than others. Do you want to learn it? I said ok.
|
| Over the years, the hiring process changed, and there is no
| way that someone like me would even be sitting at that
| interview where they could ask if I wanted to learn.
|
| So companies can go ahead and spend all that money on
| legacy consultants and all that money on migrating their
| systems.
| bluGill wrote:
| Companies that want to hire new people haven't change. If
| you want a standard web app you can demand someone with
| experience in the framework of your choice and get it. If
| you want someone to write in your custom language - you
| know they have to learn it so you hire people who can
| learn.
| monocasa wrote:
| And not even a super custom language. Get out of the bay
| area and you'll see tons of job postings that ideally
| want Go or Scala experience, but will gladly teach you if
| you have the right fundamentals. That's the only way to
| get their hiring top of funnel large enough to fill
| seats.
|
| I really think big iron's customer's problems are that
| they don't want to pay for quality engineers, but for
| some reason will pay those higher rates or more for some
| overpriced consultants. Literally just accepting that the
| outsourcing dream of 2000 was not a great move and using
| that money on internal engineering would go soooo far.
| You see even .gov getting the hint with 18F and the US
| Digital Service building and supporting non contractor
| government engineers.
| eb0la wrote:
| A lot of mission critical systems are Java on the
| mainframe. Not just Cobol.
|
| Why don't people switch, then?
|
| The mainframe gives you a predictible runtime. Long running
| jobs don't get rescheduled or hogged by other loads.
|
| I know about a firm that uses a mainframe to control a
| factory line.
|
| The problem with replacing stuff that works (and the
| mainframe does) is then your job is on the line if the
| transition fails, and there are a lot of business moving
| parts inside.
| closeparen wrote:
| How hard is it, really, to learn? Big Tech is constantly
| hiring people to work in technologies they don't know yet.
| We were all in on Go before anybody off the street knew it.
| Facebook has its own language. I'm sure businesses would
| _prefer_ instant productivity, but is the training expense
| really bigger than the migration expense?
| brendoelfrendo wrote:
| Yeah, but... can you hire for it? Plenty of forward-
| looking developers are willing to learn Go, or whatever
| new hotness the SV scene is cooking up. I think pitching
| mainframe development to that same crowd is a much harder
| proposition.
| lotsofpulp wrote:
| A more expensive proposition. Dangle some high six figure
| salaries and it will also be the new hotness.
| denimnerd42 wrote:
| nah, I think both ideas are wrong. that crowd would never
| want to work for a bank or insurance company in the first
| place unless desperate. due to their org structure they
| can never get any real value out of any 1 person,
| especially an engineer. so that salary will never exist
| in the first place.
| guenthert wrote:
| Might not be the same crowd, but some of us wouldn't mind
| to learn COBOL and get our hands on a mainframe (while at
| the same time wondering whether the world really needed
| Go).
| tartoran wrote:
| The question isn't how hard it is to learn but who is
| willing to embrace an old technology which for now it
| doesn't even make financial sense. When $300/hour becomes
| the norm you'll have plenty of resources. For now COBOL
| jobs aren't very attractive
| rbanffy wrote:
| > BUT - the problem is the core of our system is written in
| COBOL.
|
| This is the key issue. You can migrate it off the mainframe
| or you can migrate it to sexier tech on the mainframe.
|
| > and the new generation doesn't know them or have much of
| a desire to learn them.
|
| One of the barriers is that these companies are not willing
| to pay the same money we (I think we are from the same
| generation - I was paid to write Apple II software) can get
| from working with anything that's not COBOL.
|
| I'd love to spend some time with mainframes - they are the
| fastest Linux machines you can get - but don't want it
| enough to combine COBOL and JCL with a significant pay cut.
| ghaff wrote:
| I think that's often the case with "skills shortages."
|
| If banks routinely started paying Google salaries for
| good COBOL developers, you'd see those shortages
| disappear in a big hurry.
| rbanffy wrote:
| Unfortunately, banks don't see mainframe-based
| applications as a competitive differential. If they did,
| they would invest more heavily on that.
| dralley wrote:
| Yeah, RHEL and SLES have supported mainframe for a long
| time. Tons of mainframe users are running "modern"
| software stacks on top of the hardware. You can even do
| it in parallel with running the legacy stuff (and they
| do).
| albroland wrote:
| >One of the barriers is that these companies are not
| willing to pay the same money we (I think we are from the
| same generation - I was paid to write Apple II software)
| can get from working with anything that's not COBOL.
|
| As a younger person (graduated 2012) who entered the
| mainframe space for my first job then left after 2y, I
| can very much vouch that compensation for software devs
| working on zOS systems writing COBOL or HLASM is peanuts.
| You'd be looking at 1.5-2x'ing your income even if you
| took a job at a series A startup writing CRUD apps in
| Rails/etc.
| azinman2 wrote:
| Perhaps you just need to wait 10 year for everyone to
| retire and then the market supply will jack up these
| rates!
| 908B64B197 wrote:
| > the new generation doesn't know them or have much of a
| desire to learn them
|
| No top 50 CS program teaches these tech. No unicorn uses
| them. Not a single FAANG or FANNG+ if you include other
| large players.
|
| Finally, no engineering-centric company uses these tech.
| That's the difference between learning Go vs COBOL.
| pjmlp wrote:
| That is a very tiny employment market.
|
| There are only a couple of FAANG+, with crazy hiring
| practices, and most businesses aren't engineering
| centric, the world is bigger than that.
| 908B64B197 wrote:
| True, but it's the one that's getting the most attention.
|
| It sets the trends and build what's next. RandomBigCo
| just follows.
| pjmlp wrote:
| Most RandomBigCo just sees any kind of software
| development as a cost center, and eventually outsources
| it, to keep their focus on selling their actual products,
| while some else writes CRUD applications for stock
| management.
| tyingq wrote:
| Some of that list is at risk. "4 of the top 5 airlines" for
| example. Amadeus finally shuttered their TPF mainframe, so
| Sabre can't be that far behind.
| [deleted]
| NotSammyHagar wrote:
| Why don't people migrate the systems to vms, then you could run
| them on vastly cheaper hardware? You have all this data across
| the complex storage system, but all of that _could_ be
| virtualized if they wanted. The vms I worked on in the 1980s
| had so many different os variants, cics etc but if I was
| working on this approach I 'd try to run things in vms,
| eventually teeze out the pieces I could into new services. But
| the parts that are too hard could just keep running in vms. You
| have to virtualize your data sources and provide apis to read
| those old disk drives or virtualized tape drives etc.
|
| But if you are spending a billion dollars, how much code do you
| have? Also, on the lack of programmers, just pay them more and
| you'll get a lot more applicants.
| twunde wrote:
| To add on to this, this results in an odd job market where
| demand for COBOL programmers is pretty low most of the time
| since there isn't a ton of work, but when a company does need
| to hire COBOL programmers its much more difficult to find them
| and hire them. Which leads to these common stories about COBOL
| programmers being in demand, when the reality is that most have
| a hard time finding new COBOL jobs, especially without needing
| to move.
|
| Off-topic but do you work for Eversource? An ex-coworker of
| mine found a bug that he immediately recognized as a COBOL bug
| while working with Eversource CT's EDI
| tablespoon wrote:
| > We're in the midst of launching a multi-year, billion dollar
| program to replace that mainframe. We've been talking about
| doing this for years and are just now pulling the trigger on
| it. There's still time to tell whether we actually go through
| with it or not, or get $100 million into the project and
| realize we're looking at a $1.5 billion - $2 billion effort and
| abandon the project.
|
| I work at a company that basically built its current business
| on mainframes in the 70s/80s/90s. The migration effort to get
| off them has been going on for more than _20 years_ and still
| isn 't done yet.
| pickle-wizard wrote:
| Sounds about like Interstate 35, by the time you're done, it
| is time to do it again.
| meepmorp wrote:
| >We're in the midst of launching a multi-year, billion dollar
| program to replace that mainframe. We've been talking about
| doing this for years and are just now pulling the trigger on
| it. There's still time to tell whether we actually go through
| with it or not, or get $100 million into the project and
| realize we're looking at a $1.5 billion - $2 billion effort and
| abandon the project.
|
| So, you're looking at a high risk, multi-year, multi-billion
| dollar project to remove your own mainframe dependency. And the
| business isn't fully committed to it.
|
| > Most CIOs are looking for a means for retiring those assets.
|
| And finding extremely expensive, high risk, long duration
| software projects are the usual alternative, per your own
| experience. Why waste prestige and budget on that when you can
| keep all the critical LOB software running exactly as it is (or
| faster) forever? Mainframes are the OG backward compatibility
| and virtualization platforms.
|
| Given that, why do you think the mainframe business isn't
| thriving, especially given the billions in revenue that the
| companies you list in your post undoubtedly bring in for IBM?
| It's not sexy, and they're probably not winning new customers.
| But they're making a shit ton of money on a long lived,
| successful product and continuing to fund research and
| development on the platform.
| jameshart wrote:
| Yes, the mainframe business is 'thriving' in that
| environment. Much like how SARS-CoV-2 has been 'thriving' in
| a non-immunized population who don't like wearing masks...
| marcosdumay wrote:
| > Why waste prestige and budget on that when you can keep all
| the critical LOB software running exactly as it is (or
| faster) forever?
|
| Hum... Probably (and that was the case at my workplace)
| because business as usual has higher risks and ongoing costs
| than the migration. It's not like mainframes are cheap to
| own, or guaranteed to stay in existence in the future.
|
| > why do you think the mainframe business isn't thriving
|
| "Thriving" on my lexical implies on growing or at least
| sustainable. A market where new players don't want to buy at
| any cost and old players are all trying to get out is not
| this.
| meepmorp wrote:
| Your definition thriving isn't too far from mine, I think
| we just differ as to the expectations we have about the
| platform in the future.
|
| IBM offers a compelling option:
|
| - yes, your software will continue to run, because that's
| what the mainframe is for
|
| - yes, it will scale with whatever transaction volume you
| need in the future, because that's what the mainframe is
| for
|
| - yes, you can get 99.999999999999999% uptime, because you
| have reliability built into the platform in astounding
| depth
|
| - yes, we'll happily help develop new functionality and
| support your in house staff in managing this system; the
| mainframe can actually detect faults and arrange a service
| call.
|
| It's expensive, but it's a safe bet in at very least the
| medium term. The alternative is quite risky in most cases,
| and perhaps less expensive over the medium term if it works
| out.
|
| Nothing is sustainable forever, but that sounds like a
| pretty hopeful story for IBM over the medium term. Long
| term, who knows, but eventually we're all dead anyway.
| marcosdumay wrote:
| > - yes, your software will continue to run, because
| that's what the mainframe is for
|
| Maybe if you are using zos without any niche
| configuration. IBM has discontinued many mainframe
| platforms in the past, and there's no guarantee that next
| year they won't approach you with a 10x markup on your
| renting costs, that will become 50x in a couple of years
| and will keep going up until you decide to stop paying.
|
| > yes, it will scale with whatever transaction volume you
| need in the future, because that's what the mainframe is
| for
|
| Only if you gave-up on data dependency from the
| beginning. Transactions here means independent data
| processing, with possible rollbacks, not the relational
| concept people got used to on databases. If one needs
| relational data, it won't scale. NoSQL can scale with
| non-relational data too, it's not an exclusivity of
| mainframes.
|
| > yes, you can get 99.999999999999999% uptime, because
| you have reliability built into the platform in
| astounding depth
|
| That one is ridiculous. Uptime is limited by business
| code bugs, network and power outages, integration
| problems, and well, all that causes 90% of the downtime
| on a single-server shop. All the mainframe promises is
| that the hardware won't be a problem.
|
| > yes, we'll happily help develop new functionality and
| support your in house staff in managing this system; the
| mainframe can actually detect faults and arrange a
| service call.
|
| Yes, mainframes come with support contracts. You can get
| support for other platforms too, with the advantage that
| you won't need to hire IBM.
|
| Anyway, none of that changes the fact that nobody wants
| to start using a mainframe nowadays, and that the people
| using them are either looking on how to replace them or
| avoiding increasing their usage. IBM will certainly be
| able to milk that market over the medium term, even more
| if they keep increasing their prices. They revenue may
| even go up for a while. But that's not thriving.
| meepmorp wrote:
| You are completely missing the point. I'm not arguing
| that any other solution can't offer the same kinds of
| things that the mainframe can.
|
| Imagine you are a CIO. You have mainframe apps.
| Everything I said is true of your existing solution. If
| you keep it as is, it works just fine for the foreseeable
| future. Every other way forward requires a total rewrite
| of systems that have been stable for years and are
| typically mission critical financial and transaction
| processing systems.
|
| That's what I mean by IBM having a compelling offering.
| bluGill wrote:
| Problem is you can't keep it long term. As CIO you are
| also aware that the code has some ugly parts that are
| hard to maintain. You are also well aware of the cost to
| update the code (tax laws, or new features). You are very
| well aware of how hard it is to hire anyone competent who
| is willing to work in the language that it uses -
| mainframe languages are seen as a dead end. There is a
| lot less risk long term in leaving the mainframe behind,
| the only question is can you there without destroying the
| company.
|
| There are advantages to the mainframe, but there are
| disadvantages too. As a CIO your job is to consider both.
| azinman2 wrote:
| Do mainframes only run on COBOL? What are these
| languages? Or is it that some program written in 1972 is
| still running everything at United Airlines today?
|
| My understanding is at least Java is well supported on
| mainframes. It's not the latest greatest language, but it
| sure beats ALGOL.
| pjmlp wrote:
| Java, C, C++ and Fortran, POSIX environments as well.
|
| Then Algol, COBOL, RPG, NEWP, PL/I.
| NoSorryCannot wrote:
| If they're not gaining enough new customers to offset the
| losses of those that eventually leave the platform or go out
| of business, and if we take it as a given that over long
| periods of time all businesses will eventually disappear or
| reshuffle their technology stack, then the mainframe market
| is shrinking. Possibly very slowly but it's still attrition.
|
| That might make it good business for a long time but it would
| be a stretch to call it thriving, and it provides gentle but
| salient cause for businesses to consider migration.
| agumonkey wrote:
| Do you think it's technically sounds to migrate ? or is it just
| a trend to get away from old tech ?
| azinman2 wrote:
| So we know that these large companies use mainframes, in part,
| because they've always used mainframes. But it also seems like
| there are compelling reasons now in terms of large amounts of
| memory & compute & I/O & speciality co-processors. So how come
| it's not a sexy thing now? Having a ton of compute + memory + I/O
| in AWS/GCP/Azure can be really, really expensive... I'd love to
| know a cost comparison.
|
| Is it even possible for an ordinary person to rent a VM on one of
| these machines and do some compute? If I have a startup that
| needs to crunch a bunch of models or would have an easier time
| running some system centrally versus having to have the skills &
| time to create a purely distributed system, why aren't mainframes
| a good/better/easier option? How come AWS doesn't have any? Does
| IBM have quick/easy on-ramps to hosted mainframes via Softlayer
| (I can't find them if they do)?
| tyingq wrote:
| Pretty sure commodity servers have now eclipsed any compute,
| IO, etc, advantage mainframes ever had. With perhaps a few
| exceptions for some really niche things...like VISA using TPF
| (which is an unusual OS on a mainframe) because it's basically
| a huge, high transaction rate, distributed NoSql database.
|
| The only real remaining advantage is probably the overall
| reliability, redundancy, engineering, etc. Like being able to
| swap out a CPU while the system is running.
| azinman2 wrote:
| Surely you can get more memory/IO/CPU on a mainframe than a
| commodity server, no?
| wolf550e wrote:
| No. A mainframe is not a supercomputer. You can get more
| cores, more dram, more iops for less money if you don't
| need high reliability in a single machine (because your
| software handles nodes failing) and if you don't need
| compatibility with binaries from the 60s.
| tyingq wrote:
| Max cores is 190, so no on CPU. Memory and IO, perhaps, but
| it's unusual to put more into a single partition than you
| would into a typical large X86-64 server. And it's a lot
| more pricey.
| zozbot234 wrote:
| A true "cost comparison" would have to include existing on-prem
| platforms, and account for new players like Oxide Computer
| Systems who are working to bring newer, cloud-native
| technologies to the on-prem datacenter. The mainframe may be
| competitive with "cloud" solutions, but that's not where the
| most obvious comparison is.
| greedo wrote:
| Hah no. When my company was looking to justify buying a new
| mainframe, they tried to leverage our server team by saying
| "You can run Linux in LPARs just like you do on VMware etc." So
| we met with the sales guys. They asked the size of our average
| Oracle VM (RAM mostly), and when they heard 256GB, they smiled.
| Then the mainframe manager asked how much it would cost to
| provision that much RAM for 10-12 LPARs. I wish I had taken a
| photo of his expression. Needless to say the meeting ended
| shortly after, and we didn't pursue spending almost 100x the
| amount we were spending on our ESX hosts...
| forgotmypw17 wrote:
| I can think of two reasons why:
|
| 1) the Lindy Effect: https://en.wikipedia.org/wiki/Lindy_effect
|
| 2) The mainframe's reliability-centric culture vs. today's flaky
| software design culture
| EricE wrote:
| >2) The mainframe's reliability-centric culture vs. today's
| flaky software design culture
|
| Very underrated comment! Ran into the same thing with VOIP vs.
| traditional PBX systems. The IP Telephony guys were sloppy with
| uptime and reliability, and that's being generous :p
| BXLE_1-1-BitIs1 wrote:
| Right now we're seeing a proliferation of states, counties, local
| health authorities, hospitals and drug stores all setting up
| their own individual Covid19 vaccination booking applications.
| Just about every single one is falling flat on its face when
| confronted with demand. No mainframes involved.
| danans wrote:
| What, from a black box perspective (i.e. performance,
| reliability, cost/compute, maintenance-cost/compute)
| distinguishes a modern mainframe from a modern onsite private
| compute cluster?
|
| Let's say both are running the same OS and application using VMs,
| and neither is doit specialized types of compute (i.e GPU stuff),
| just processing gobs of transactions.
|
| Obviously there are big internal architectural differences, but
| ultimately these must manifest in some quantitative and
| qualitative differences and tradeoffs from a black box
| perspective.
|
| Please discuss.
| marcosdumay wrote:
| You want to know from what point of view?
|
| From the buying manager POV, one is cheap commodity and the
| other is expensive single vendor equipment.
|
| From the programmer POV, one is a proprietary environment with
| uniformly addressable memory (not UMA, just addresses) and the
| other is a distributed blank canvas where you must write the
| IPC yourself (or use a library, of course). Both have a huge IO
| capacity, but mainframes can integrate data much faster (and
| usually, process it much slower).
|
| From the ops POV, one is a single machine (a heavy one), and
| the other is an entire datacenter.
___________________________________________________________________
(page generated 2021-03-11 23:01 UTC)