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

171–180 of 195 posts

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

#171

Post by rbanffy »

bcantrill wrote: post #118
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,…

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] ht…

IBM big iron is a thing of beauty. There is nothing ill-advised in pushing a platform that's comparable to it in the good parts, and lacking the icky ones is a huge plus.

And it's a shame POWER is soooo expensive. But, then, so are high-end x86 and ARM, so I guess it's not that it's expensive more than I'm not paid nearly enough to have one. And, between buying a high-end POWER box and a yacht, I'll always take the second.

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

#172

Post by neverartful »

rbanffy wrote: post #170
bob1029 wrote: post #109

Earlier quoted context omitted.

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…

I have tried numerous times to get a z/OS LPAR and an AIX VM without any luck. It's a complete mystery to me.

IBM probably doesn't make mainframe LPARs available over the internet because the cost of the LPAR would be cost prohibitive to any potential customer. On the other hand, a z/VM guest or an LPAR on POWER should absolutely be an option.

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

#173

Post by neverartful »

Scubabear68 wrote: post #152
neverartful wrote: post #144

Earlier quoted context omitted.

Call BS all you want, I don't care. I know what I witnessed. I don't know if the mainframes were owned are leased, but they were swapped out for new ones every few years.

I’d like to hear more then. Mainframes are traditionally a big investment where you consolidate tons of load and jobs and LPARs onto one honking big machine. A very expandable machine in terms of any resource you can think of. Why would you turn over something like that every few years? Your narrative sounds more like taking about ephemeral cloud stuff, not multi million dollar main frames.

I think in my former employer's case they leased the mainframes because they found it more favorable to have OPEX over CAPEX. Every few years IBM would pitch their latest and greatest and often times it made financial sense (lower costs) to upgrade to the newer models.

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

#174

Post by neverartful »

graycat wrote: post #161

Ah, good to hear that the IBM mainframes are still around, are more powerful , and that the software for the old IBM mainframes will still run on the new mainframes. So, yup, JCL still works! An 3270 series video terminals with 24 lines of 80 characters each driven with CICS (customer information control system or some such) is still used. But I didn't see that (1) Rexx, often a good replacement for JCL, (2) XEDIT, a…

The latest incarnation of VM/370 is branded z/VM. Most of my hands-on mainframe work was with VM/CMS and I enjoyed using it.

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

#175

Post by elzbardico »

The problem with most projects of mainframe migration that I've seen is that most of them suffered the bad luck of being started around the 90s and 2000s, a really complicated age in Enterprise Software, the age of COM/DCOM/COM+ and EJB 2.0.

Any normal person would prefer to program in S/370 assembly than be forced to use EJB 2.0 Entity Beans.

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

#176

Post by lproven »

mousetree wrote: post #21

> Today, IBM is the only mainframe manufacturer AFAIK Fujitsu still manufacture mainframes

It does, but AFAIK, while it has 1 or 2 mainframe OSes still in maintenance, still getting updated, they run under emulation on x86-64 processors now.

All the mainframe OSes I know of except IBM's run under software emulation nowadays.

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

#177

Post by tracker1 »

I remember in my late teens, working as a temp... literally looking up individual accounts from a "past due" report to make sure they were still past due before they received a call from collections dept. Why, because paying a temp was literally less expensive than re-running the report on the mainframe.

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

#178

Post by PeterStuer »

The trick to surviving in Enterprise environments is consistently and credibly beating the longest horizon dtrayegic rate of return budget (luck has it enterprise's stategic horizons are not that long). At any point it is still better to stick with the current than to change. You boil the frog, but very carefully.

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

#179

Post by tracker1 »

toyg wrote: post #123
colonwqbang wrote: post #57

Earlier quoted context omitted.

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.

I never cared much for the LINQ syntax myself either. But absolutely have enjoyed a lot of the extension methods for use with given data sets.

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

#180

Post by tracker1 »

mberning wrote: post #8
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…

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

Have you ever migrated a decades old application off of a mainframe?

Most of these kinds of systems have decades of codified knowledge that applies the legal requirements of many disparate jurisdictions in these systems. Laws vary from city to city, county to county and state to state, and that's only for the US. Some of these systems implement code that applies legal requirements for dozens of nations.

In general, you're going to have to spend at least a year just to document the existing system. Another six months to a year generating test cases and scripts for validation. And that's before even starting to build the new system. And that is ALL optimistic, assuming everything goes right.

I had to once write a relatively simple application for "vacation bidding" where in employees will get a position to request certain weeks off during the year. This was a legal requirement and happened to involve the company, two other companies that had been merged in and three unions. Each with different rules regarding how seniority is calculated. The contractual specifics were over two thousand pages long. That's just one very small piece of software in one of these very large companies. It took the better part of a year to implement. Now imagine taking that a couple decades later after it's evolved and migrating to an entirely new platform and paradigm. Now imagine the cost to do that.

Post reply on HN