I write some more about it here:
https://www.devever.net/~hl/ppcas
Interestingly this functionality is actually unlocked on the Raptor Talos II/Blackbird systems so you can play with it in full.
But you are right, and in that it has something in common with sandboxing of Java applets, for example – which didn't work out as well as its inventors had hoped.
That said, although classic applications all run in a single shared address space, newer versions have added support for isolated per-process address spaces (teraspaces), which have in turn used been to add an AIX compatiblity layer (PASE). If you write your apps against AIX compatibility layer, you get process-based security just like you do on AIX. And in that layer you aren't just limited to calling (a subset of) AIX APIs, you can also call into IBM i native APIs which don't exist on AIX – albeit at some performance cost, since the call has to be marshalled into the single shared address space.
IBM's original JVM ran in the classic single shared address space, and was deeply integrated into the OS. Then they replaced it with J9, their JVM for AIX/Linux/Windows/etc, and J9 runs under the AIX compatibility layer. Given they encourage Java for developing new apps – a lot of apps now contain a mixture of legacy RPG/COBOL/etc code along with Java code to implement web UIs and SOAP/REST APIs – more and more stuff is running outside of the shared address space.
Now that must be the most diplomatic understatement I've come across in a long time.
In the beginning (1978) was the IBM System/38, which had a custom CISC CPU architecture with 48-bit addressing (called IMPI), vaguely resembling the 360/370 mainframe instruction set, but incompatible with it, and having some rather high-level abilities like task switching in microcode (similar to hardware task switching on the 386). The System/38 had some very advanced features: single level storage, capabilities and programs compiled to byte code (which the OS then converted to the IMPI physical instruction set). However, IBM also had its System/36 "midrange" line (basically minicomputers but IBM preferred to call their business-oriented minicomputers "midrange"), which was incompatible and more of a traditional system architecture. So in 1988 IBM "unified" them by releasing the AS/400, which was basically a version 2.0 of the System/38, keeping the same basic architecture but adding a System/36 emulation subsystem so it could run most System/36 applications.
Separately, IBM had its RISC Unix RS/6000 line, which spawned POWER and PowerPC. And then in 1991, IBM came out with a new version of the AS/400 based on PowerPC instead of proprietary IMPI CISC. The fact that applications compiled to bytecode meant most applications could be ported to RISC seamlessly, since the new OS version translated the bytecode to PowerPC instructions instead of IMPI instructions. At the same time, much of the core of the OS was rewritten in C++ (having previously been in a proprietary PL/I dialect.)
But still, although RS/6000 and AS/400 now used the same CPU architecture, they were still physically different hardware. Originally, the AS/400 used its own PowerPC chips with additional instructions the RS/6000 ones lacked. Even after they unified the two lines on the same CPU models, they still had different firmware.
In 2000, there was a marketing-driven decision ("eServer") to rebrand RS/6000 to pSeries and AS/400 to iSeries. This was part of an attempt to present IBM's four distinct server platforms (mainframe, AS/400, RS/6000 and PC) as some kind of cohesive strategy (mainframe became zSeries and PC servers became xSeries).
Then, in 2006, the iSeries (formerly AS/400) and pSeries (formerly RS/6000) hardware lines were merged completely, to become IBM Power Systems. Now there was no physical difference between the hardware, it is just which OS you install on it. The IBM i (originally OS/400 and later i5/OS) operating system uses certain firmware features which AIX doesn't use – but all IBM Power Systems have that code in their firmware, it is just AIX and Linux don't call those functions. (There are now low-end Linux only machines which refuse to run AIX or IBM i, although possibly that's just a flag in the firmware license as opposed to distinct code.)
I has a fancy memory architecture, very smart disk controllers (essentially distributed intelligence, like an octopus), a virtual instruction set (that has been used multiple times to almost seamlessly jump huge under-the-hood processor changes), and historically a reliability record second to none (the old box in the wiring closet running for years upon years, completely untended). Z has even more toys, including some of the strongest clustering, partitioning, security found anywhere. Sysplex, LPARs, and RACF are all impressive, especially given how many decades ago they started. We won't even talk about the DBMS and transaction monitors, which are their own brand of crazy strong.
Those immersed in the higher-volume, standard microprocessor, Unix/Linux or Windows, cloud mainstream don't give "proprietary systems" much thought or respect. But we probably should. Those who knew the IBM I or Z, or the DEC VAX/VMS, HP MPE, Tandem NonStop, etc.—they were too expensive, too few in number, too quirky—but what they did well, they did outstandingly well in their purpose-focused, allopatrically speciated ways. Better in many cases that we can do today with the latest 2024 gear.
I think this is the biggest problem, plus the fact these systems tend to be tied to proprietary - and also very expensive - hardware platforms. If I want to learn about GNU/Linux or BSD, all I need is a computer (PC in most cases, but other options exist) and an Internet connection. These days, most people (at least in Europe and North America) have these anyway, so it's really easy to get started in the comfort of one's own home.
Having a free account on a public machine is cool, but it's not the same as having your own system, especially if you want to learn about system administration.
The killer, of course. As they say: anyone can build a bridge that stands, but it takes an engineer to build a bridge that barely stands. In this game, a solution that's too expensive is often not a solution at all.
It's an interesting introduction to the AS/400, up to the POWER transition.
There's also Fortress Rochester by the same author that goes into the iSeries / POWER4, but I haven't found a copy on line.
It seems like you and GP both have valid points.
Borrow-words usually (AFAIK) generally have the same meaning in the donor and recipient languages. So referring to the donor-language definition is a good way to figure out intended usage.
IIUC, virgule has different meanings in Latin, French, and English. I'm guessing that's what's throwing us off.