4 ms·

I've often considered AS/400 a "road not taken" in systems engineering, one that would have been much more influential had it come out 15 years sooner (though i

by Aloha 5y ago

I've often considered AS/400 a "road not taken" in systems engineering, one that would have been much more influential had it come out 15 years sooner (though if it had, the hardware would not have been performant enough to run it), particularity the abstraction between memory and storage being handled by the OS rather than the application. The machine independent codebases, and other features and bonuses and have allowed it to continue to live on at minimal cost.

ngcc_hk 5y ago
Given that system/34 and /38 is quite popular in 1980s or earlier not sure how early one can do for this platform. System 360 is 1960s.
skissane 5y ago
One of the big problems I see with 38/400, is while it had some very innovative features, it also had some very old-fashioned ones: EBCDIC, COBOL, RPG, etc. IBM has de-emphasised those old-fashioned aspects over time, but maybe it would have been more successful if they'd moved away from them at the start? I think it also might have been more successful if instead of porting it to POWER they'd ported it to x86 – they might have needed to add some tagged memory extension to x86 to do that, but I'm sure Intel would have been happy to talk. Indeed, the same idea has a history in Intel, if you look at the iAPX-432 and the i960, so Intel would certainly have understood the request–they might have even been excited about it. (Of course, given IBM's commitment to RISC and POWER, wasn't going to happen.) Like a lot of other IBM systems, it became more closed over time. The System 38 had huge amounts of very detailed technical documentation publicly available. With the AS/400, much of those details moved under NDA, and it has only got worse over time. Now, you can't even write a compiler for (non-PASE) AS/400 without signing an IBM NDA, the executable format is under NDA. How closed is that! I even wonder, what if instead they'd ported 400 to 370/390/z, or tried to make 38/400 and 370 more compatible from the start? Maybe some of these ideas might have cross-pollinated to MVS/VM/etc. A lot of what is most original about the 38 and 400 (single-level store, capability-based addressing) actually descends from the Future Systems project, a cancelled 1970s effort to design a next-generation successor to the 360/370. Maybe those technologies might have been more influential if they had a future on the mainframe? A merger of the AS/400 and 9370 (low-end mainframe) lines could have led to that.
- Aloha 5y ago
  I'm not in the hate COBOL camp, COBOL is very good at what it does, when I finally got exposure to system z and COBOL, I was astounded at how easy it was to work with record data there. It's something that's several orders of magnitude harder to do in the Unix world with its "bag of bytes" data paradigm. Everything that originated in the Unix world is really designed for that data model, and is really just a different way of thinking.
  - skissane 5y ago
    I don't hate COBOL either. And you are right, there are some positive aspects of COBOL, including some of the data modelling ideas in the DATA DIVISION. However, I think if you look at PL/I, you'll find most of the same ideas present, but on the whole it is a nicer language. Some people hate PL/I too, and no doubt it can be overcomplicated (which is part of why PL/I subsets were so popular in the 1970s and early 1980s), but I think PL/I has most of COBOL's strengths with fewer of COBOL's weaknesses.
    - Aloha 5y ago
      I think of PL/I as a systems programming language, and COBOL as an application programming language, much in the same way you'd look at C/C++ and Java in the Unix world, I think (I think that analogy is actually almost directly applicable, though maybe Pascal is a closer fit? I'm not sure). Different tools designed to do different things. I'd actually like to learn PL/I (or COBOL beyond a cursory knowledge), I'm someone who has a great deal of knowledge of the thought patterns of programming (as well as how you architect software, systems design, etc), without knowing any one tool well, I tend to learn a tool for a task, then forget the tool when I no longer require it anymore. My job is.. hard to explain, but its quasi programming, but also very much not aside from helper scripts I write now and again (I use all of the thought patterns of programming, without any of the tools). I enjoy writing software, but only have so many itches to scratch in my personal time.
      - skissane 5y ago
zozbot234 5y ago
P-code is essentially the same idea as AS/400 machine-independent code, and it didn't really work well on early machines because optimizing it to efficient binary/machine code, even AOT, was infeasible back then. It took time for compiler to become good enough. As for handling "the abstraction between memory and storage", that's what memory mapped files are essentially. It's being done routinely in modern systems.
- pjmlp 5y ago
  Actually it was quite feasible and a company was built on that in 1979. https://en.wikipedia.org/wiki/Corvus_Systems https://en.wikipedia.org/wiki/Corvus_Systems

by Aloha 5y ago

ngcc_hk 5y ago

Given that system/34 and /38 is quite popular in 1980s or earlier not sure how early one can do for this platform. System 360 is 1960s.

skissane 5y ago

One of the big problems I see with 38/400, is while it had some very innovative features, it also had some very old-fashioned ones: EBCDIC, COBOL, RPG, etc. IBM has de-emphasised those old-fashioned aspects over time, but maybe it would have been more successful if they'd moved away from them at the start? I think it also might have been more successful if instead of porting it to POWER they'd ported it to x86 – they might have needed to add some tagged memory extension to x86 to do that, but I'm sure Intel would have been happy to talk. Indeed, the same idea has a history in Intel, if you look at the iAPX-432 and the i960, so Intel would certainly have understood the request–they might have even been excited about it. (Of course, given IBM's commitment to RISC and POWER, wasn't going to happen.) Like a lot of other IBM systems, it became more closed over time. The System 38 had huge amounts of very detailed technical documentation publicly available. With the AS/400, much of those details moved under NDA, and it has only got worse over time. Now, you can't even write a compiler for (non-PASE) AS/400 without signing an IBM NDA, the executable format is under NDA. How closed is that! I even wonder, what if instead they'd ported 400 to 370/390/z, or tried to make 38/400 and 370 more compatible from the start? Maybe some of these ideas might have cross-pollinated to MVS/VM/etc. A lot of what is most original about the 38 and 400 (single-level store, capability-based addressing) actually descends from the Future Systems project, a cancelled 1970s effort to design a next-generation successor to the 360/370. Maybe those technologies might have been more influential if they had a future on the mainframe? A merger of the AS/400 and 9370 (low-end mainframe) lines could have led to that.

Aloha 5y ago
I'm not in the hate COBOL camp, COBOL is very good at what it does, when I finally got exposure to system z and COBOL, I was astounded at how easy it was to work with record data there. It's something that's several orders of magnitude harder to do in the Unix world with its "bag of bytes" data paradigm. Everything that originated in the Unix world is really designed for that data model, and is really just a different way of thinking.
- skissane 5y ago
  I don't hate COBOL either. And you are right, there are some positive aspects of COBOL, including some of the data modelling ideas in the DATA DIVISION. However, I think if you look at PL/I, you'll find most of the same ideas present, but on the whole it is a nicer language. Some people hate PL/I too, and no doubt it can be overcomplicated (which is part of why PL/I subsets were so popular in the 1970s and early 1980s), but I think PL/I has most of COBOL's strengths with fewer of COBOL's weaknesses.
  - Aloha 5y ago
    I think of PL/I as a systems programming language, and COBOL as an application programming language, much in the same way you'd look at C/C++ and Java in the Unix world, I think (I think that analogy is actually almost directly applicable, though maybe Pascal is a closer fit? I'm not sure). Different tools designed to do different things. I'd actually like to learn PL/I (or COBOL beyond a cursory knowledge), I'm someone who has a great deal of knowledge of the thought patterns of programming (as well as how you architect software, systems design, etc), without knowing any one tool well, I tend to learn a tool for a task, then forget the tool when I no longer require it anymore. My job is.. hard to explain, but its quasi programming, but also very much not aside from helper scripts I write now and again (I use all of the thought patterns of programming, without any of the tools). I enjoy writing software, but only have so many itches to scratch in my personal time.
    - skissane 5y ago

zozbot234 5y ago

P-code is essentially the same idea as AS/400 machine-independent code, and it didn't really work well on early machines because optimizing it to efficient binary/machine code, even AOT, was infeasible back then. It took time for compiler to become good enough. As for handling "the abstraction between memory and storage", that's what memory mapped files are essentially. It's being done routinely in modern systems.

pjmlp 5y ago
Actually it was quite feasible and a company was built on that in 1979. https://en.wikipedia.org/wiki/Corvus_Systems https://en.wikipedia.org/wiki/Corvus_Systems