Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The IBM mainframe: How it runs and why it survives

arstechnica.com

Post reply on HN
Print view View original

121–130 of 195 posts

Re: The IBM mainframe: How it runs and why it survives

#121

Post by TheRealDunkirk »

ghaff wrote: post #13
jmartrican wrote: post #12

Earlier quoted context omitted.

Before we even get to the costs of a migration, what is the reason for the migration?

It's what would be cool and would look good on my resume. (Only half /s)

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.

Re: The IBM mainframe: How it runs and why it survives

#122

Post by Tuna-Fish »

dbcurtis wrote: post #111
hinkley wrote: post #85

Earlier quoted context omitted.

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.

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.

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.

Re: The IBM mainframe: How it runs and why it survives

#123

Post by toyg »

colonwqbang wrote: post #57
xahhkakappy11 wrote: post #6

Earlier quoted context omitted.

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.

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...

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.

Re: The IBM mainframe: How it runs and why it survives

#124

Post by SoftTalker »

xahhkakappy11 wrote: post #6
CraigJPerry wrote: post #4

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 world…

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.

pl/SQL has good support for inline SQL.

Re: The IBM mainframe: How it runs and why it survives

#125

Post by hinkley »

queuebert wrote: post #108
hinkley wrote: post #85

Earlier quoted context omitted.

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.

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?

I think we need history classes in programming, and possibly comparative literature classes but for code.

Re: The IBM mainframe: How it runs and why it survives

#126

Post by SoftTalker »

Scubabear68 wrote: post #84

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.

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.

Re: The IBM mainframe: How it runs and why it survives

#127

Post by dbcurtis »

Tuna-Fish wrote: post #122
dbcurtis wrote: post #111

Earlier quoted context omitted.

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.

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 p…

I think you make a good point. Although I have seen patents for reinventing something in an expired patent :)

Re: The IBM mainframe: How it runs and why it survives

#128

Post by hinkley »

Melatonic wrote: post #115
hinkley wrote: post #88

Earlier quoted context omitted.

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,…

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

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.

Re: The IBM mainframe: How it runs and why it survives

#129

Post by radiator »

ibiza wrote: post #100
hermitdev wrote: post #68

Earlier quoted context omitted.

> 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 o…

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.

From z/OS to Oracle. Good Lord!

Re: The IBM mainframe: How it runs and why it survives

#130

Post by reacharavindh »

CraigJPerry wrote: post #4

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 world…

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.

Post reply on HN