3 ms·

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

by 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. ;)

by cbd1984 11y ago

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