Hacker News Reader

Comment by apecat | Hacker News Reader

Please feel free to share some of these nightmares. These systems are so surrounded by an air of mystique and vague hints of danger, and I've mainly tried to read up on the supposed benefits of using mainframes to get why anybody would use them.

I'm honestly interested in all kinds of IT horror stories, I need a reminder every now and then to keep the IT part of free from things that break and require tinkering (starting with unnecessary on-premise servers in small biz settings). Mainframes are obviously nine orders of magnitude beyond what I ever to, but still: the lessons of expensive and proprietary can be somewhat universal.

View on HN

Once you get them running, they stay running. Like OpenVMS systems, you'll occasionally hear stories of how people lost them. They'd run without maintenance for so long that people would forget where they were when they needed it. My company has one that's been running all the critical stuff for years. It's the only thing that always works.

Btw, the original design was an awesome capability-secure system called System/38:

https://homes.cs.washington.edu/~levy/capabook/index.html

It was originally part of an even more awesome concept called Future Systems, which was supposed to replace the entire IBM universe with capability-based single-level storage systems.

http://people.cs.clemson.edu/~mark/fs.html

http://www.garlic.com/~lynn/submain.html#futuresys

It never got off the ground. System/38 and AS/400 are the only visible remnants of it, survivors from an alien world.

working on the iSeries (AS/400) currently and to be honest, I don't know of an easier to maintain system. DB2 is nearly automatic in maintenance and the only time we suffer an outage is paranoia when a multiple level redundant system went out and they wanted to replace the backup units with the failed. The size of these machines range from barely seeming bigger than a PC to 64 way and hundreds of terabytes. IBM was smart in that pSeries and iSeries share hardware, though running a Linux VM/partition/etc is more for sheer fun of it than work.

I used to joke that slackers should specialize in AS/400 "repair" with revenue coming from support and maintenance contracts. I predicted it would be a really easy job. Just regularly run reports or something to hand management to justify your salary. Take credit for the uptimes. And so on. :)

"though running a Linux VM/partition/etc is more for sheer fun of it than work."

I thought that was to get benefits of modern stacks running side-by-side with legacy OS/400 apps. You don't use it that way? And while we're at it, did they ever provide an easy, machine-usable interface between those instead of a web app simulating a terminal typing individual characters in like some mainframe places do? That seemed kind of ridiculous.

I didn't realize it was that big. I found in there this link...

http://www.jfsowa.com/computer/memo125.htm

...that illustrates the difference between knowledge and wisdom very well. Soya has a number of wise observations and recommendations that apply in enterprise software projects today. I've seen the same arguments. Just usually not that many at once given the narrow scope of any given enterprise tech.

He's definitely made me consider the Single-Level Store a weakness until proven otherwise. His argument that the customers saw no benefit except the performance tradeoff is disturbing and probably still applies a lot. I mean, the ability to avoid crashes, hacks, much technical debt, and many failed integrations with high-level machine are huge enablers. All people cared about was price for raw performance ratio, though.

Interestingly, I've been thinking similar to him on a number of angles as I look at these new projects. It's why I pushed CHERI processor over SAFE despite liking SAFE more. It's because CHERI is compatible with FreeBSD and MIPS while probably having less overhead. It's also why I pushed Java processors like JOP or Vega3 over another Secure Ada Target (or even Rust target) for embedded or enterprise servers. Python runtime or machine over LISP. And so on.

Time shows the path of least resistance with greatest performance and legacy integration must be taken. So, anyone wanting high-reliability or high-security has to work in a box. That's been rained on continuously for decades. ;)

Big Iron still has a place between commodity clusters and super computers. My dad used to work on them and he once referenced doing some operation on his local PC circa 2000 realized it would take several hours, so moved data to the TeraData machine where it took "Approximately how long it took my finger to lift off the enter key."

For some things having silly amounts of RAM and a few hundred disk drives and multi gigabit interconnects just works really well.

Not sure if Teradata will classify under big iron, though it does provide channel based connection to mainframe. IIRC Teradata nodes are UNIX based.

Not really my area of expertise.

IMO, it's less about OS than it is specialized hardware, you don't see multiple terabytes of RAM on normal motherboards. As such plenty of mainframes ran on a flavor of UNIX just like plenty of supercomputers used UNIX.

But, I can see people using other definitions.

Here's you a classic one I should've put in my other comment:

https://scs.senecac.on.ca/~ibc233/MS400.html

I still poke at them over this. Another was them running Hotmail on FreeBSD instead of Windows. Lots of problems when they switched. Least both experiences were good for debugging purposes. ;)

Note: The only thing better would be finding out Apple ran on a mainframe or AS/400 given Jobs' hatred of IBM. I doubt I'll get the satisfaction.

Reply on news.ycombinator.com