IBM i opened my eyes a bit, and made me a bit sad, when I decided to check it out after decades of working on what I now realize are entirely UNIX-y OSes. By that I mean that besides the many actual UNIX-derived systems like Linux, Solaris, HP/UX, macOS I worked on, IBM i made me realize that DOS, Windows, OS/2, and whatever else most people are probably aware of nowadays, are also UNIX clones to a much higher degree than I thought.
IBM i is completely different in many ways. It has a unified 128bit address space. It does not have the same concept of a hierarchical filesystem (by default, you can bolt one on, but it clearly does not "fit"), and it does not even strongly have the concept of having everything in "streaming" files (or their equivalent) to begin with. It also has a completely different "command line" concept for example, and countless other aspects that are hard to explain succinctly.
It is a bit like learning Haskell, where it used to feel like you thought you could learn every language in an afternoon (after C, C++, Java, JS, Pascal, perl, python, awk, shells, BASIC, and countless others), but then discover you have to relearn the very basics, and that what you thought of as universal actually isn't.
A lot of these concepts work really well. They are at a level of abstraction that I would not have thought possible in practice. They allow the system to be incredibly stable and low maintenance, and elegant. The underlying architecture was changed at least once (maybe twice, not sure), and it was entirely seamless for customers.
It made me sad because I discovered a computing world that could be widespread reality, but in all likelihood won't be. That's thanks to UNIX being so pervasive that it's now basically woven into the very fabric of computing, but that is of course in no small part thanks to IBM's extreme closeness. I once thought UNIX was the way to go, but I'm not so sure anymore. And now that it's everywhere, too many of its concepts are considered a "ground truth". UNIX won because it was hard to avoid getting exposed to it, while for IBM i you had and still have to fight for even just trying it out.
Interestingly, the IBM mainframe world, i.e. z/OS and its predecessors, do feel the same in terms of "you have to relearn everything", but with the opposite outcome. Where IBM i is presenting you with unique abstractions from the very base of the OS, it's amazing how little abstraction there is in the mainframe world. You clearly get a sense that mainframes come from a time where a lot of common concepts simply had not been invented yet, while on the other hand IBM i (or rather its predecessors) reimagined OSes at a much later time.
I've worked on old IBM systems (old by today's standards, back then they were top of the line), the 4381 to be specific, it ran very fast (the IO capabilities of those systems was quite impressive for the time and even today such a system would, besides it size be quite ok) compared to all of the UNIX machines I had played with but it wasn't elegant in the way that UNIX was, just tons and tons of little details to remember, whereas with the UNIX survival guide (about 15 commands) you could normally get through the day until you started to do crazy stuff. The IBM gear cam with absolutely amazing documentation though.
"everything is a file" is brilliant, but UNIX didn't take that as far as it should have, Plan 9 is much further along that road and I would consider it to be even more elegant than UNIX.
The way in which things work is just like you would expect them to work, including being able to compose stuff (for instance: in Plan 9 to run a new version of the window manager in a window in the old one) is what I really like about that particular system.
Between Plan 9 and Erlang we missed a bus somewhere.
> "everything is a file" is brilliant, but UNIX didn't take that as far as it should have
Agreed. The interface between applications and the operating system is not sufficiently abstracted. If it were software would be vastly better; faster, more secure, easier to manage, scale, migrate, troubleshoot, etc.
There is a lot of attention paid to programming language design and too little paid to the environment in which software has to operate. I think the low hanging fruit is improving operating systems and their abstractions. Solving this at the programming language level is not feasible; all that produces is a virtual machine that adds overhead, complexity and valueless diversity.
Be careful though, IBM 4381 is an example of the mainframe world, so very much not similar to IBM i. It's s/370 compatible and ran OS/VS1 and VM/370.
In terms of abstraction, almost the opposite in some sense, as I've noted in my last paragraph. In terms of usage as well: IBM i's command line model I also mentioned helps a lot in using the system even without external documentation (more than the UNIX shell does), which seems to be the opposite in the mainframe world.
Yes, that's true it is a completely different beast from IBM i. By the way, I'm not sure if you have just used these remote or virtualized or in person but they are quite impressive from a hardware perspective and built incredibly solid compared to almost everything else that I've worked with including VAXen from that era. We had two of them (cold spare...) maxed out Group 2 models.
That's still 'only' 32 MB of RAM which may seem tiny by today's standards but that machine happily served a few hundred branch offices of a fairly major bank all by its lonesome, so that's 1000's of concurrent users (https://en.wikipedia.org/wiki/CICS).
I never used the i series (formerly AS/400, and System/38 before that), but reading Inside the AS/400 by Frank G. Soltis made a huge impression on me. Highly recommended for anyone interested in the details.
If you'd like to try, there is a way to get a free user account at pub400.com. That got me interested enough that I set out to get my own AS/400.
It took me literally years until I stumbled upon an affordable machine with licenses. The machine I got is decades old and was decommissioned in 2008, after a long life.
IBM created something revolutionary and did everything to keep the public away from it.
The team behind it also tried to keep the rest of IBM away from it, for fear that The Suits From Armonk would come in and ruin their product and their culture.
I kind of wished I would have got a position at some company to work on an AS/400. Back in the day, my company was looking for a new "solution" and considered most everything, including an IBM. But eventually we went UNIX.
What I'm curious, though, is in the world of a random back office developer, how much of the, well, "inner beauty" of the machine would I have encountered.
Most of the cool Unix-y stuff happened mostly through ad hoc integrations with random Stuff as circumstances presented themselves, and I don't know how much of the AS/400 a random (likely) COBOL programmer would have delved into.
My impression from reading the book was that it had a beautiful internal architecture that I imagined would largely be hidden from the user. I think as a say COBOL programmer on an AS/400, one would pretty much see it as not much different from say a mainframe. This opinion is entirely formed without experience though.
It's still very different from a developer/"system user" perspective (I don't say enduser because then you are kept away from most anyway). A lot of concepts one takes for granted are different.
Exactly my experience when delving into the computer library at the university.
I was heading into some UNIX zealotry path, and then started diving into everything that happened before UNIX, what was going on at Xerox, DEC, Olivetti, ETHZ, and so forth, sunddenly UNIX wasn't that interesting as I once thought.
Never worked on IBM i, but Wang VS had a very unique system. It also expected the terminals connected to it to have a small CPU.
Too bad it never made it to the wild. In its last days it was ported to an IBM AIX System (RS6000?), but the company went bankrupt before that port made it out.
> ... on the other hand IBM i (or rather its predecessors) reimagined OSes at a much later time.
Yes. The System/38 - AS/400 - iSeries - IBM i (the lineage) resulted from a project called the "Future Systems" project which started in the late 1960s and tried to imagine computers as appliances, while recognising that hardware was changing fast.
Hardware architecture independence, encapsulation of software objects, a highly regular, helpful user interface, and minimal administration labor were all design goals of that project.
It succeeded too well. User-written programs were stored with their "intermediate representation" (think assembler). They could be, and were, retranslated automaitcally when moved to a new architecture.
Upgrades from a 36-bit processor with 20-bit addressing to a 48-bit processor with 32-bit addressing to POWER (64-bit / 64-bit) were essentially just a backup and restore[1] for customers.
As probably mentioned in the video, the system could be configured with a modem and would phone home to IBM if it detected a fault.
It was common that after a few years with turnover of accounting personnel, offices would not even know that they had an iSeries - this is probably still the case.
This lack of mindshare is probably what killed the i. That and IBM not wanting to sell it, to protect their mainframe business.
---
1. On backups: The OS stored a backup history (dates of the last 20 or so backups, from memory) with each object. It also stored each object's date of creation and the name and serial number of the system it was created on, as well as the dates of metadata modification (changes to access rights, for instance).
Not surprisingly with all the bookkeeping it was much harder on disk drives than IBM's comparable systems. Disk drives that lasted for many years when used with a 4300 series (cut-down mainframe) tended to die in 18 months used with the System/38. RAID-1 and RAID-3 (2 stripes plus a dedicated parity drive) was implemented in the early 80s, from memory. RAID-5 came a bit later IIRC.
Programs and files were objects. So were user profils and group profiles. Access control lists, objects that contained lists of users and groups and permission lists for each entry, were used to control access rights to other objects. They themselves were objects at the same level as these - created, manipulated, and backed up in just the same way.
It tried out a lot of things. It had a unified concept of "message queues". There were permanent ones like the QSYSOPR (system operator) queue, the equivalent of syslog. Processes each got a message queue. Programs within a process each got a message queue, so a program could tell its grandparent something and continue. As a programmer you could create your own message queues, the analog of named pipes in Unix. Message templates were predefined and stored in "message files", which allowed you to write "second level text" --esentially detailed help--for each message. The shell's built-in command prompting and menu system was built around message files and queues as well.
IBM i is completely different in many ways. It has a unified 128bit address space. It does not have the same concept of a hierarchical filesystem (by default, you can bolt one on, but it clearly does not "fit"), and it does not even strongly have the concept of having everything in "streaming" files (or their equivalent) to begin with. It also has a completely different "command line" concept for example, and countless other aspects that are hard to explain succinctly.
It is a bit like learning Haskell, where it used to feel like you thought you could learn every language in an afternoon (after C, C++, Java, JS, Pascal, perl, python, awk, shells, BASIC, and countless others), but then discover you have to relearn the very basics, and that what you thought of as universal actually isn't.
A lot of these concepts work really well. They are at a level of abstraction that I would not have thought possible in practice. They allow the system to be incredibly stable and low maintenance, and elegant. The underlying architecture was changed at least once (maybe twice, not sure), and it was entirely seamless for customers.
It made me sad because I discovered a computing world that could be widespread reality, but in all likelihood won't be. That's thanks to UNIX being so pervasive that it's now basically woven into the very fabric of computing, but that is of course in no small part thanks to IBM's extreme closeness. I once thought UNIX was the way to go, but I'm not so sure anymore. And now that it's everywhere, too many of its concepts are considered a "ground truth". UNIX won because it was hard to avoid getting exposed to it, while for IBM i you had and still have to fight for even just trying it out.
Interestingly, the IBM mainframe world, i.e. z/OS and its predecessors, do feel the same in terms of "you have to relearn everything", but with the opposite outcome. Where IBM i is presenting you with unique abstractions from the very base of the OS, it's amazing how little abstraction there is in the mainframe world. You clearly get a sense that mainframes come from a time where a lot of common concepts simply had not been invented yet, while on the other hand IBM i (or rather its predecessors) reimagined OSes at a much later time.