Did some development for a server application that supported RS/6000 among other platforms. AIX on RS/6000 was a nice enough Unix but, being used to Solaris, everything seems just slightly off. I think it performed slightly worse for the same price as Sparc hardware for our purposes, but some customers wanted an all IBM solution (we also supported an OS/2 client).
The main thing that stands out was a tool (smitty?) that could do system configuration and IIRC it could show you the steps to do it manually as well.
Don't forget the other cool feature of smit: the running man.
When you started an operation, there was animated icon of a man running. If your command succeeded, he'd stop and cheer. If you got an error, he'd trip and fall on his face.
Also, another advantage of AIX was that it included a volume manager and it was enabled by default. Back in the early 1990s, this was fairly unique. Some other operating systems offered, but only as an expensive add-on, so in practice you did without it. Being able to add a disk and just tell the system to move a filesystem over to it was pretty amazing.
Where I worked we got an early system as we made graphical desktops for workstations. IBM required that we have a separate locked room for the system!
Despite having over 20 different brands/Unix systems, AIX was the only one we had to pay a 3rd party consultant to come in and do installations and upgrades. That was back in the days of tapes. It used some convoluted volume management system where the tape contents got spooled into the disk and then the installation absorbed that.
smitty always felt so slow. There was a release where it was sped up. They didn't actually make it do the work any quicker - they just doubled the animation speed of the running man that was shown.
One of the big differences is that it is also COFF based like Windows, and Aix shared objects have similar capabilities, with private by default, import files, and having the capability to let the compiler handle delay loading of specific symbols.
I used Aix 5 series quite a bit, and looking at docs it seems to still have the same capabilities.
Yes, the sysadmin tool was awesome. There were 2 versions: one graphical (smit) and the other text/console based (smitty). Both versions had the same capabilities.
I think the other thing is the Object Data Manager (ODM)- configuration data about devices, networking configuration, etc. is stored as objects, as opposed (or in addition to?) to text files.
I also believe the AIX software package manager uses ODM.
`smit`, IIRC. Most workstation platforms, you mainly just had to know whether they were based on BSD or System V (or Apollo Domain, or the VMS of the VAXstations), but AIX had this interactive UI thing that was different.
Three other things nice about the RS/6000 and AIX:
* When it first came out, it was noticeably faster than the SPARCstations at the time.
* The hypertext documentation browser was nice. (This was slightly before the Web.)
* IBM would send two field technicians, in suits. (Which was funny, when they were meeting with frumpy nerdy teenager me.)
(We developed workstation software engineering tools for mil/aerospace/datacomm, which seemed to be wanted on everything except SGI. So, every time there was a new architecture, or a major OS change like SunOS 4 to Solaris 2, we'd get it immediately for porting.)
Eh, smitty could be irritating because it persisted some changes but not others. So it was unclear if things you did outside it would get undone at boot time.
The finest contribution of AIX to Unix, copied (with varying attempts at improvements) by its 90s competitors and eventually into Linux, was its jounal filesystem.
The order of magnitude improvements to fsck on bootup and overall filesytem reliability were non trivial.
SMIT was abit too non-unixy to catch on but I've always wondered in the back of my mind whether it influenced systemd...
As a sysadmin in a mixed shop in the early 1990s I found that I could do just fine with traditional CLI and scripting tasks without using HP-UX's SAM or Sun's Solstice tools, but AIX's SMIT and smitty really got in the way of that sort of cheap and dirty automation. I understood the purpose of all those tools, but AIX pretty well made SMIT and smitty obligatory and that did not sit well with me back then. In the context of what you've said comparing SMIT and systemd, I would agree based on my experiences of way back then.
Smitty didn't get in the way of scripting, you could just craft up what you wanted and was F9 iirc you could press and see your options all as they would execute in the command line. So could just go thru smitty to set what you wanted and instead of running it, just crib the command line sequence and pop into your script without even having to learn AIX nuances.
I liked smitty for the <ESC>4 that would show the script/command that smitty would use. I used this feature a lot in the beginning to learn the IBMisms of AIX.
AIX on RT PC had a rather interesting architecture: the AIX kernel ran on top of a microkernel called VRM. VRM also supported two other operating systems, AOS (IBM’s port of 4.3BSD) and PICK. VRM could run multiple operating systems simultaneously, with a hotkey to switch which had access to the keyboard, mouse and screen. Similar idea to Windows NT’s environment subsystems, and IBM’s later Mach-based Workplace OS (cancelled before it ever went GA, but shipped in beta form to customers as OS/2 PowerPC Edition).
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.
"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:
"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 knew about the TSS/370-based port but had forgotten its relevance
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
I hadn't heard about that UNIX "Princeton port" before. Thanks!
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."
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."
For those who were wondering what VRM stands for it's Virtual Resource Manager. I found a quick introduction to it[0]. It says it was programmed in PL.8.
A blast from the past! Years ago I worked on some J2EE nonsense to do e-commerce websites on top of a Pick application. It was I think called Mailbrain, I think running on HPUX though I could be mis-remembering. There was a horrible text based socket protocol for passing data records back and forth.
I do remember the Pick greybeards being dismissive of this new fangled SQL stuff: "we had relational databases before SQL don't you know"
Pick ran on a plethora of different platforms. Ultimate even had a port for IBM mainframes, PICK/370.
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 wonder how many customers IBM RT PC PICK ever actually had.
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.
Not mine. First Unix box I ever touched, in my first job, here on the Isle of Man 36Y ago.
It was a demo machine, but my employers, CSL Delta, never sold any AFAIK. It sat there, running but unused, all day every day. Our one had a mono text display on it, and no graphics ability that I know of.
I played around, I wrote "Hello, world!" in C and compiled it and it took me a while to find that the result wasn't called "hello" or "hello.exe" or anything but "a.out".
If I had the knowledge then, I'd have written a Mandelbrot generator or something and had it sit there cranking them out -- but I was not skilled enough. It was not networked to our office network, but it had a synchronous modem allowing it to access some IBM online service which we used to look up tech support info.
Synchronous modem comms, or serial comms, are very different indeed to the familiar Unix asynchronous serial comms used on RS-232 connections for terminals and things. Sync comms are a mainframe thing, more than a microcomputer thing.
That modem was a very specialised bit of kit that cost more than a whole PC -- when PCs cost many thousands each -- and it couldn't talk to anything else except remote IBM mainframes, basically.
The RT/PC felt more powerful than a high-end IBM PC compatible of the time, but only marginally. It had a bit of the feeling of Windows NT about 6-7 years later: when you were typing away and you did something demanding, the hard disk cranked up and you could hear, and even feel the vibrations, that the machine was working hard, but it stayed responding to you the same as ever. It's a bit hard to describe because all modern OSes work like this, but it was not normal in the 1980s.
Then, OSes didn't multitask or they did it badly, and things like hard disk controllers of the time took over the CPU completely when reading or writing. So on MS-DOS, or PC-DOS or OS/2 1.x or DR Concurrent DOS, when you typed commands or interacted with programs, the computer responded right away as fast as it could. But if you gave a command that made the machine work hard, like asked for a print preview or a spell-check of a multi-page document, or sorted a spreadsheet of thousands of rows, or asked it to draw a graph from hundreds of points of data, the computer locked up on you. The hard disks span up, you heard the read/write heads chattering away as it worked, but it was no longer listening to you and anything you pressed or typed was lost. Or, worse, buffered, and when it was done, then it tried to do those commands, and quite possibly did something very much not what you wanted, like deleted loads of work.
(Decades later something similar happened with cooling fans, and now that's going away too. But with hearing the fans spin up, there's a hysteresis: it takes time, and tens of billions of CPU cycles, for the CPU to heat up, so the fans come on later, and maybe stay on for a while after it's done. A PC locking up as the hard disk went crazy was immediate.)
The RT/PC was a Unix box. It didn't do that. No idea how much RAM or disk ours had: maybe 4MB if that, perhaps 100-200MB disk. A lot for 1988! But if I did, say,
cd /
ls -laR
... then it would sit there for several minutes with the HDD chuntering away, listing files to screen... but what was remarkable was that you could switch to another virtual console and it stayed perfectly responsive as if nothing were happening. That hard disk was SCSI of course, so it didn't use loads of CPU under heavy disk load.
The machine always felt a little slower, a little less responsive than DOS, but it never slowed down even when working hard. You had the feeling of sitting behind the wheel of a Rolls Royce with some massive engine there, but pulling a massive weight, so it didn't accelerate or brake fast, but could just keep accelerating slowly and steadily 'til you ran out of road... and you'd make an impressively large crater.
We sold a lot of IBM PS/2 machines with Xenix, and it was a Unix too and felt the same... but limited by the puny I/O buses of even high-end 1980s IBM PS/2 kit, so it sssslllloooowwwweeeedddd way down doing that big directory listing.
Whereas contemporary PC OSes responded quicker but just locked up when working hard. This included Windows 2, 3.x, 95, 98 and ME, and also OS/2 1.x, 2.x, and Warp. The kernels did not support multithreading and background I/O very well, so it didn't matter that the hardware didn't either.
Then Windows NT 4.0 came along, and it did. Suddenly the hardware mattered. But if you had a Pentium 1 machine, with an Intel Triton chipset on the motherboard, there was an innocent looking driver floppy in the box. On that was a busmastering DMA driver for the Intel PIIX EIDE controller. Install it on Win9x and it could see a CD-ROM on the PATA bus. Handy but not world-shattering.
Install it on an NT machine and once the kernel booted, the sound of the hard disk changed because the kernel was now using busmastering to load stuff from disk into RAM. As the machine booted the mouse pointer kept moving smoothly, with no jerkiness. When the login screen appeared it blinked onto the screen and you could press Ctrl-Alt-Del and start typing and your username appeared slowly but smoothly. The stars representing your password, the same.
It suddenly had that "massive computer power being used to keep the machine responsive" feeling of an RT/PC the decade before. Like that PIIX driver had made the machine's £100 cheapo IDE disk into a £400 SCSI disk.
Those things were always so expensive, even used for years after, and now hard to even find. I remember wanting one back in the day when I was running Gentoo on my old 500Mhz PowerBook G3. So loud though...
They are not that hard to find on eBay. Unfortunately, here in Europe they are quite rare, but I bet that, in the US, there are abandoned warehouses full of these.
I believe the Oracle 8 SQL Server we used at school in the starting of the '2000 was running on a RS/6000 system on AIX.
Nice system, had a good memory from it performance-wise. MySQL was not a serious competitor at that time.
The machine had often overheating issues starting from the beginning of june when ambiant temp rose above 24/25°. We did not have CVAC in the building.
One of the interesting things about these systems is that the early versions (like shown in the ads), didn't have a single CPU chip package. The CPU was on a card and was comprised of various chips and circuitry that you could see (not all hidden on the inside of a single CPU package). It was not until the P2SC (Power2 Super Chip) that everything made its way onto a neat and compact CPU form factor that we typically think of. This P2SC was first made available IIRC on the 7013 Model 595.
Oh, I have one of those behind my my desk at home ^_^ upgraded it with a video-card, so it boots into CDM now, should do a new video.. https://www.youtube.com/watch?v=c7bN1hYqD7Y
It explains the architecture of the 7011/250 in detail. When I was much younger I was working with a group to get Linux on there. We got to the point of making a boot floppy that would display a 3 digit number on the front panel.
I'll get back to it eventually, I have 8 7011s with the intention of circularly netbooting them to rapidly test kernel builds. Also have a bunch of others (several of each 7006, 7009, 7012, 7013 and then the newer prep, chrp, P4/5/6/7/8/9). Most my free time is spent working on FreeBSD networking right now.
Set up an eBay saved search, they are the most common of the MCA RS/6000s to show up. Price target $150-200. If that doesn't work out in a reasonable timeframe (say 1 year) contact me.. otherwise better to rescue from the market than other collectors, dollar for dollar, to keep more machines out of the landfill.
There is a 220, which have the interesting RSC chip (good for AIX 3.2.5, probably not a good target for anything else including NetBSD due to specialized CPU support that would be necessary):
https://www.ebay.com/itm/335464230008
You'd want a [250,25T,25W] (66 or 80mhz, hard to determine which without seeing the planar) for NetBSD or AIX up to 4.3.3 (5.1 will run but is a little heavy for the hardware).
There is a now rare 7248, this is a second gen prep system that is special because it can boot Solaris, OS/2, NT, AIX, NetBSD. It looks similar to the more ubiquitous 7043-140 which is also a good machine but can't do all those OSes. Price is close to reasonable for what it is:
https://www.ebay.com/itm/186792645248
The old ads were incredibly verbose as well. In fact, if you compare ads in say, 1955 National Geographics to ads in 1985 Byte, theyre not so different: headline, image, then 200 words of content. Something happened in advertising around 1988 to 1990 that totally upended this approach. (I wonder if it was the arrival of mature DTP that meant that much more visual layouts could be achieved for the same effort?)
Can you remind HN what was special about VUE? My dim memory of it was that it was very CDE-like, in contrast to other environments of the time, such as Sun OpenWindows. Did VUE have some particular special sauce?
It was a lot prettier. Fruitier colours, modern sans serif fonts. And it had a cool hp logo on the dock, it made it look like a little computer. It always made me happy when I logged in in the morning. Then CDE came and it felt like work.
When they partnered with sun and IBM to make CDE it got all boringified and businessy :P Serif fonts, boring designs etc.
But yea it was very CDE like because the UI for CDE was basically taken from VUE.
CDE had a few thingies that were a bit more advanced like more things you could just configure by clicking instead of messing with config files.
The main thing that stands out was a tool (smitty?) that could do system configuration and IIRC it could show you the steps to do it manually as well.