I've read that in AS/400, everything is an object, rather than a file. Could you expand on that at all?

kjellsbells 4 days ago | parent | next [-]

It's quite tricky to explain, but yes, everything in AS/400 is an object. There is also the notion of a context, called a library, that these files-as-objects exist in. AS/400 files very frequently act in a way that today we would describe as databases (like sqlite files, say) and the library context guides how information ('records') in them is returned, eg FIFO, LIFO, etc.

I think the best explanation is contained in this very old porting guide from IBM that explains how to move UNIX programs to AS/400. It's written in a remarkably un-IBM fashion, not at all straitlaced.

https://www.redbooks.ibm.com/redbooks/pdfs/sg244438.pdf

For any experts out there, please correct me, it's been 30 years...

▲

linksnapzz 4 days ago | parent | next [-]

I just finished reading "Fortress Rochester" by Frank Soltis, the designer behind the IBM System38/OS400/iSeries sw.

It's a fascinating book, very approachable for the density of the technical detail contained, and shows how very different choices were made w.r.t. how OS/ 400 system software was designed, and how hardware was developed to support it.

As I understand from reading it, there's like three layers to the software-

-->Things you'd think of as applications on Unix, running in user space...this includes the DB/400 database engine, queue systems etc.

-->Machine Interface (MI) components, which include the management of the single-level store, I/O devices (OS/400 still supports dedicated mainframe-style I/O channels to an extent), and compilers/interpreters. All of this layer and above are considered "Technology Independent" software, where programs written in C/C++, RPG IV, COBOL, Java etc. are compiled into 128-bit object code that gets translated into PPC instructions on the fly.

-->the SLIC (System? Licensed Internal Code) which is referring to both some of the iSeries firmware, stuff that might be considered part of the kernel in Unix, as well as the PowerVM hypervisor.

The craziest thing (to me) about the single-level store is that there's no user-visible filesystem to administer; objects created in memory are automatically persisted onto permanent storage, unless you explicitly tell the system otherwise.

The OS/400 objects also have capabilities built-in; i.e. things like executables can only be run, and not edited at runtime; these are flagged during memory access by setting bits in ECC memory using a dedicated CPU instruction on Power CPUs that was added explicitly for OS/400 use.

For someone who is used to Unix, iSeries a really fascinating thing to learn about. Pity that it's not more accessible to hobbyists, but as the Soltis boook makes clear, the purpose of the design was to satisfy a specific set of customers, who had well-defined line-of-business applications to run.

	▲	sillywalk 4 days ago \| parent [-]
		> I just finished reading "Fortress Rochester" by Frank Soltis, the designer behind the IBM System38/OS400/iSeries sw. There's a copy of the previous version, Inside the AS/400, also by Frank Soltis on archive.org https://archive.org/details/insideas4000000solt/

▲

bombcar 4 days ago | parent | prev [-]

I’m not ready for 1995 to be 30 years ago …

▲

pjmlp 4 days ago | parent | prev | next [-]

Also it is one of the successful bytecode OSes, were userspace is mostly bytecode based and AOT compilation takes place at installation time, or after updates.

▲

anyfoo 4 days ago | parent | prev [-]

Honestly, it's a bit much for a single HN comment. But I've look around, and I found this, which upon first glance gives a good (and not too long) overview: http://www.varietysoftworks.com/jbaldwin/Education/single-le...

Crucially, it also describes the "single level store" that everything lives in. In short, the boundary between "main memory" or "hard disk" or other things is abstracted away, and you just have pointers to "things" instead. While in UNIX accessing some piece of main memory is fundamentally different from, say, opening a file.

Even though UNIX has a little bit of the opposite concept of trying -- but in my mind failing -- to represent as much as it can as a "file".