Utilities exist, but they tend to be different.
There’s also oddities like the compiler (xlC) emitting code that is able to dereference null pointers, with the zero page. It’s a valid but odd choice of undefined behavior. [1]
Now, nearly three decades later, we have even more automated and integrated mechanism 'systemd' and I think that there would be still features worth adopting from AIX. Not the first time i have such thoughts with an OS slowly vanishing.
The first version of AIX, for the IBM RT PC, actually ran on top of a microkernel written in PL/I, called VRM - how’s that for alien.
Subsequent versions moved closer to the Unix mainstream by dropping the PL/I microkernel.
As for standard Unix tools - or rather "Linux" or OSS tools these days - they are not that difficult to find and are for the most part readily available. IBM used to supply a lot of that directly, but these can be found elsewhere and for myself I work on AIX more or less as I would on Linux.
When that's said, if you don't actually need the AIX-specific features you can as well run Linux. But if what that site indicates is correct then I'm a bit surprised - IBM seems to have invested a lot in those "differences" the last couple of decades and it's strange if they're abandoning that, or planning to - yes, you can run Linux on IBM hardware, but then.. why? Sounds to me they'll lose HW sales if they abandon AIX. Their strategy has been to make the system more and more Linux-like in many ways (compiler has gcc-compatible options, as one example), but at the same time add large-scale features which Linux doesn't have. Which is clearly why AIX has survived while none of the others have (IRIX, Solaris, Tru64..) - those Unix systems didn't really bring anything more than a Linux system could. AIX does.
Don't know if this counts, but you get much memory with fewer cores. For software where licensing is coupled to cores this quickly gets cheaper.
And for what I see in production the hardware is more reliable in comparison to two large x86 vendors. This is of course based on a small number of systems (n~100)
Hit this really weird bug - on AIX, errno is not thread-safe by default!
Solution is simple: add -D_THREAD_SAFE or -D_THREAD_SAFE_ERRNO to CFLAGS. Took me a few hours of scratching my head before I worked it out though.
Isn't that a conforming implementation?
(IIRC[1], errno is thread-local, not necessarily race-safe. i.e. it's visible to interrupts, which could change it)
[1] No doubt someone will correct me if that is wrong.
When the Linux glibc 2.x/NPTL ABI was taken into use, it was clear that threads were not a passing fad and stuff was made multi-thread (to the extent the API can enable that, of course) by default, so there was no need for carrying around both a single-thread ABI and a multi-thread ABI.
On AIX, errno is not thread-local by default, it is a global variable shared by all threads. Only if you set one of those two defines, does it become a thread-local variable. On every other platform I’ve ever written code for, errno is thread-local by default and no special define is needed to make it so. Hence, when you port to AIX, if you don’t know about those defines, you can get all these weird race condition bugs related to error handling, because suddenly errno isn’t thread-local any more
So you also get shared libraries with private by default and import libraries for example.
It also supports lazy loading of dynamic libraries, where the OS implicitly loads dynamic libraries when it hits an import stub.
AIX was a steaming pile of shite for a Linux or Free BSD power user.