4 ms·

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 re

by apecat 11y ago

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.

nickpsecurity 11y ago
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 https://homes.cs.washington.edu/~levy/capabook/index.html
- cbd1984 11y ago
  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://people.cs.clemson.edu/~mark/fs.html http://www.garlic.com/~lynn/submain.html#futuresys 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.
  - Shivetya 11y ago
    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.
    - nickpsecurity 11y ago
      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.
  - nickpsecurity 11y ago
    I didn't realize it was that big. I found in there this link... http://www.jfsowa.com/computer/memo125.htm 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. ;)
Retric 11y ago
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.
- sreeramvenkat 11y ago
  Not sure if Teradata will classify under big iron, though it does provide channel based connection to mainframe. IIRC Teradata nodes are UNIX based.
  - Retric 11y ago
    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.
nickpsecurity 11y ago
Here's you a classic one I should've put in my other comment: https://scs.senecac.on.ca/~ibc233/MS400.html 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.

by apecat 11y ago

nickpsecurity 11y ago

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 https://homes.cs.washington.edu/~levy/capabook/index.html

cbd1984 11y ago
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://people.cs.clemson.edu/~mark/fs.html http://www.garlic.com/~lynn/submain.html#futuresys 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.
- Shivetya 11y ago
  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.
  - nickpsecurity 11y ago
    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.
- nickpsecurity 11y ago
  I didn't realize it was that big. I found in there this link... http://www.jfsowa.com/computer/memo125.htm 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. ;)

Retric 11y ago

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.

sreeramvenkat 11y ago
Not sure if Teradata will classify under big iron, though it does provide channel based connection to mainframe. IIRC Teradata nodes are UNIX based.
- Retric 11y ago
  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.

nickpsecurity 11y ago

Here's you a classic one I should've put in my other comment: https://scs.senecac.on.ca/~ibc233/MS400.html 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.