2 ms·

> I like to joke there are platforms that were so ahead of their time they are still ahead of ours. The AS/400 is one such thing In some ways really advanced,

> I like to joke there are platforms that were so ahead of their time they are still ahead of ours. The AS/400 is one such thing In some ways really advanced, in many ways really backward. An “object-oriented operating system” in which the OS vendor can define dozens of classes (object types), even for their most obscure add-on products-but third party vendors and end-customers can’t define any at all, they can only use the ones IBM defines (very rarely, third party vendors might have some kind of deal with IBM, where IBM engineering defines a class for them) An “object-oriented operating system” with no concept of inheritance - except many of the classes have defined some kind of “subtype” field/attribute which amounts to the same thing, except in an adhoc rather than general way. Has this great “technology independent machine interface” (TIMI) idea-programs are compiled to byte code, and the OS translates the bytecode to machine code before running it - so moving a binary to a new CPU architecture doesn’t require a recompile. Except turns out the latest version of that bytecode (the ILE version) is completely undocumented outside of IBM, and IBM won’t release that documentation (except possibly under NDA and with $$$$ license fee)-which means nobody but IBM can write a compiler for it. Documentation is available for the original late 70s/early 80s version of the bytecode (OPM), but it has problems supporting languages like C (it works much better for 1970s versions of COBOL or RPG). Nowadays IBM will say “use PASE instead”-which is an AIX emulation environment, meaning kissing the whole bytecode idea goodbye and compiling to POWER machine code A system whose native filesystem doesn’t even support nested directories (which it calls “libraries”)-although it has since added a POSIX filesystem that does, but lots of core functionality uses its native filesystem instead To say nothing of EBCDIC, 5250 green screens, or RPG And the OS itself is written in a grab-bag of different languages, including Modula 2, and two different top secret IBM-only dialects of PL/I - although the newer parts are written in C++ instead But yeah it has also got other cool stuff like capabilities, tagged memory and a single level store (although many apps now run in private address spaces instead)

sillywalk 4y ago
You seem to know a lot about the system, thanks for sharing. Do you have any idea the reasoning behind the no nested libraries & objects can only have a 10(?) letter name?
- skissane 4y ago
  Some of it is backward compatibility with earlier systems - S/36 and S/38 had roughly similar limitations. It is a design decision that dates back to the 1970s, and in the time they made it, they were hardly the only system to have made such a decision. Back then, truly hierarchical file systems were still a new idea - Unix was popularising it, Unix got the idea from Multics - it was primarily associated with research/academic systems and hadn’t yet spread much to commercial ones, which is where they were situating the product. On the other hand, S/38 adopted other highly novel research ideas, so why not this one? Another factor is the UI: 5250 and 3270 block terminals work really well with fixed width fields, they don’t have good support for arbitrary length ones. Fields can’t be scrolled - if the field has a maximum value length of 255 bytes, it has to take up that many bytes on the screen. That is likely a factor which discouraged them from longer names and multi-level hierarchy. OTOH, MVS datasets have max 44 character names. They are pseudo-hierarchical, with 4 levels of “qualifiers” then a name, each max 8 characters, separated by dots. So I don’t know why they didn’t do something closer to MVS-maybe they thought “we are not a mainframe we are midrange machines that’s overkill for us” The 8 or 10 character limit wasn’t uncommon for the 1970s. In those days, most Unix filesystems had a 14 character limit which is only a bit better. They could have enhanced the core system to support nested libraries and longer library and object names. It would have caused backward compatibly issues for older apps but there are workarounds for that, like Windows having both short names (8.3) and long names for files; they could have some system to make nested libraries look like unnested ones on an app-by-app basis. They decided never to make those investments-they decided to just slap a POSIX filesystem on the side and leave the core alone.
  - sillywalk 4y ago
    That was my guess - the Green Screen thing, though I didn't know the fields couldn't scroll. It just seemed like with everything else sort of 'overkill' - 128bit address space - it would've been sort of an arbitrary amount. Thanks again for the info
    - skissane 4y ago
      > It just seemed like with everything else sort of 'overkill' - 128bit address space - it would've been sort of an arbitrary amount. It is kind of bizarre how they overkilled / went bleeding-edge in some areas but held back in others. It makes for a strange, retrofuturistic system

sillywalk 4y ago

You seem to know a lot about the system, thanks for sharing. Do you have any idea the reasoning behind the no nested libraries & objects can only have a 10(?) letter name?

skissane 4y ago
Some of it is backward compatibility with earlier systems - S/36 and S/38 had roughly similar limitations. It is a design decision that dates back to the 1970s, and in the time they made it, they were hardly the only system to have made such a decision. Back then, truly hierarchical file systems were still a new idea - Unix was popularising it, Unix got the idea from Multics - it was primarily associated with research/academic systems and hadn’t yet spread much to commercial ones, which is where they were situating the product. On the other hand, S/38 adopted other highly novel research ideas, so why not this one? Another factor is the UI: 5250 and 3270 block terminals work really well with fixed width fields, they don’t have good support for arbitrary length ones. Fields can’t be scrolled - if the field has a maximum value length of 255 bytes, it has to take up that many bytes on the screen. That is likely a factor which discouraged them from longer names and multi-level hierarchy. OTOH, MVS datasets have max 44 character names. They are pseudo-hierarchical, with 4 levels of “qualifiers” then a name, each max 8 characters, separated by dots. So I don’t know why they didn’t do something closer to MVS-maybe they thought “we are not a mainframe we are midrange machines that’s overkill for us” The 8 or 10 character limit wasn’t uncommon for the 1970s. In those days, most Unix filesystems had a 14 character limit which is only a bit better. They could have enhanced the core system to support nested libraries and longer library and object names. It would have caused backward compatibly issues for older apps but there are workarounds for that, like Windows having both short names (8.3) and long names for files; they could have some system to make nested libraries look like unnested ones on an app-by-app basis. They decided never to make those investments-they decided to just slap a POSIX filesystem on the side and leave the core alone.
- sillywalk 4y ago
  That was my guess - the Green Screen thing, though I didn't know the fields couldn't scroll. It just seemed like with everything else sort of 'overkill' - 128bit address space - it would've been sort of an arbitrary amount. Thanks again for the info
  - skissane 4y ago
    > It just seemed like with everything else sort of 'overkill' - 128bit address space - it would've been sort of an arbitrary amount. It is kind of bizarre how they overkilled / went bleeding-edge in some areas but held back in others. It makes for a strange, retrofuturistic system