[0] https://ardent-tool.com/615x/The_Virtual_Resource_Manager.pd...
How much use all these different ports saw, I don’t know. Obviously some of them were pretty big (you mention Prime, I’ll mention R83) - others less so. I wonder how many customers IBM RT PC PICK ever actually had. Probably significantly less than PICK ever had on AIX for RS/6000 (at one point several different PICK vendors offered Unix ports, and AIX was commonly on the list of supported Unix flavours)
I hate it.
According to Wikipedia:
Approximately 23,000 RTs were sold over its lifetime, with some 4,000 going into IBM's development and sales organizations. Pick OS sales accounted for about 4,000 units.
I do remember the Pick greybeards being dismissive of this new fangled SQL stuff: "we had relational databases before SQL don't you know"
One ran on top of Sperry/Univac OS2200 EXEC-8 (and this was the first SMP UNIX AFAIK):
https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf
"The UNIX system for the UNIVAC 1100 series was built as an integrated development environment for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain services that would normally be provided by device drivers, and some process creation and management services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system."
A Bell Labs port to an IBM mainframe ran on top of TSS/370:
https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
"Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the base for our UNIX system implementation. The choice of TSS/370 was a controversial one; it is a little known and inadequately documented system. Still, it came the closest to providing the structure and function needed to support UNIX system processes, and it appeared that it could be enhanced to provide any missing functions with reasonable effort. In 1979 we proposed to IBM that they make the necessary modifications to the TSS supervisor to support UNIX system processes, according to our design. IBM agreed to do so under a program license agreement, and the first version of the enhanced TSS was delivered in 1980."
I can think of another: the University of Wollongong’s port of Unix V6 to the Interdata 7/32 started out running under Interdata’s OS/32, until the port advanced to the point that they could get rid of OS/32 and run it directly on bare metal. I suppose this differs from these other ports in that it was only ever intended as a temporary stopgap while the port could be completed, not as a final destination: http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
The Princeton port that evolved into Amdahl UTS maybe also counts, since early versions could only run under VM, not bare metal. That meant they could use VM’s simplified paravirtual device API (hypercalls via DIAG instruction), that hid some of the complexity of mainframe IO-running on bare metal required dealing with those complexities directly
Also TIL: Eric Schmidt worked on that port apparently ( https://en.wikipedia.org/wiki/Amdahl_UTS ), in addition to or around the same time as his ?summer? internship work at Bell Labs as co-author of Lex (https://en.wikipedia.org/wiki/Eric_Schmidt). That would have been before he went to Berkeley and then joined Sun as its first software manager.
Tom Lyons's 3-part blog post on the port (which he worked on) adds nice context and some fun to read technical tidbits and commentary: https://akapugs.blog/2018/05/12/370unixpart1/
Aparently Eric didn't just work on the port, he recognized the technical pieces were in place enabling a port and organized the collaboration to carry it out. Although in a funny line in that same piece, Tom notes: "Eric, in a display of his future managerial potential, did not participate in the actual technical work, but deserves a lot of credit for working the system to make things possible."
I actually went over the Univac and TSS ports in my parallel xargs article:
https://www.linuxjournal.com/content/parallel-shells-xargs-u...
In my workplace, we still have fully-supported OS2200 running the DMS hierarchical database.
We are also running VAX VMS on the Charon emulator, but there are plans to replace the VAX's functions with Rockwell's "Factory Talk Production Center."
VRM was written, not in C, but in a PL/I dialect (not sure which, but probably PL.8). So AIX for RT PC is a rare example of a Unix whose kernel is (partially) written in a language other than C. The only other example of that I know of is IBM z/OS (which most people don’t think of as a Unix, but officially it is one, since it passes the certification test suite and IBM pays The Open Group the Unix trademark license fees.)
I say partially because the actual AIX kernel is in C, but it then calls to the VRM microkernel which isn’t in C. But a lot of basic functions which normally belong in a Unix kernel are in the VRM instead and the AIX kernel is just a thin wrapper over them.
When AIX moved to the RS/6000, the VRM microkernel was dropped, and AIX from then onwards was a classic monolithic kernel all in C.
Well, historically “AIX” has been a brand for (many but not all) IBM Unixes, with several unrelated code bases being labelled “AIX”. One of those, AIX/ESA (for IBM mainframes), was actually based on OSF/1, and hence used the Mach microkernel. But it was discontinued in the first half of the 1990s, when MVS gained Unix compatibility support. And all the other “weird” AIX variants are also now long dead, so in practice AIX for RS/6000’s descendant is the only AIX left.
AIX is a bit like DB2, in that both were brand names for multiple distinct code bases. The difference is all but one AIX code base died, whereas multiple DB2-branded code bases are actively supported today.