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

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