IBM AS/400: Databases all the way down (2019) [video]
youtube.com
youtube.com
BTW, I've been trying to set up a small AIX box to do some software testing (and not make the mistake of making a Unix app dependent on linuxisms) on IBM cloud and, even when you navigate the confusing UI and metaphors (there is no "give me a POWER10 AIX VM with this many vCPUS, this much memory and this much disk" option), it's failing for me for unfathomable reasons while trying to create a storage volume with the default options. On a side note, I can create a Linux VM running on s390x from the same flow I create x86 ones, but I can't select a z/OS disk image, or a POWER processor. If I want a z/OS machine, I have to go through an entirely different workflow (one I went through, only to never be able to figure out the IP addresses I could ssh to).
Once I managed to bring a couple Itanium boxes we had from retirement because their then humongous caches were perfect fits for our working dataset and, therefore, for that specific workload they were 10x faster than our Xeons.
It seems like Linux always wins in terms of licensing, so does it currently lose in any of those metrics?
Also, since Linux runs on IBM POWER systems, it looks a lot like IBM's AIX has very little place to stand: Even if the hardware is better (which, judging from experience with other proprietary workstation vendors like Sun, I'd be surprised about) the value proposition of running Linux as opposed to a proprietary OS with less effective support and expensive licensing appears insurmountable.
https://en.wikipedia.org/wiki/PowerLinux
So, I'd be willing to believe that IBM's hardware is better in some ways, but I'm more skeptical about IBM's software in a realm where an apples-to-apples comparison is possible.
https://utcc.utoronto.ca/~cks/space/blog/unix/PCsAreUnixWork...
https://utcc.utoronto.ca/~cks/space/blog/unix/WorkstationMyt...
In short, I'm not sure IBM Power machines have any special hardware, and if they do, I'm reasonably sure Linux supports it. It is, after all, a smaller and more stationary target than the weird crap that ended up inside and hooked to commodity PCs that Linux ended up supporting.
As for special hardware, the processor drawer of an E1080 looks a lot like the one of a z16 (without the distributed virtual cache of the Telum, or the insane water cooling blocks):
The other thing is that like mainframe, you can lease CPU on demand. So if your business is cyclical, it may be better to increase CPU November-January by 20%.
Why should a couple of hackers working out of the proverbial garage building the next unicorn consider IBM as their infrastructure vendor?
What are their offerings? How do those stack up against the defaults of aws/Azure + Linux + Postgres/MySql?
Assume said hackers are broke.
To me, it's absolutely nuts they don't have entry paths to their crown jewels. What will IBM's competitive advantage if everyone migrates from AIX and IBMi to Linux? While there is no IBMi emulator, there are commercial environments that can compile and run COBOL and PL/1 code made for i on x86 Linux machines.
There's no way z/OS is going to be free or open-source (if for no other reason than if they open sourced it, you'd still need a mainframe, which means you're going to pay IBM for cloud time), so if hobbyists are going to start with something they'll probably start with Linux. Once they are no longer a hobbyist, IBM will be there to help.
I never said that.
What I said is that there aren't any onboarding routes to z/OS (or AIX, or IBMi). You either already are running one or more z/OS boxes, or you'll just deploy to cloud, CentOS, Kubernetes, OpenShift, on commodity CPUs (x86 and ARM), or any of the other stack that rivals a mainframe in some capabilities (and carefully avoid business requirements only a mainframe can fulfill)
This is probably why IBM mainframe OSes until the 1980s are public domain: You can't run MVS without an IBM mainframe, so why bother even copyrighting the source code? The Hercules people are grateful for that bit of pragmatism.
http://www.hercules-390.org/hercfaq.html
Not sure if big-blue ever had that kind of person in abundance to be honest. Was recently reading up on the DEHOMAG thing recently, and well probably not. At least Watson tried to give the Nazi medal back, haha.
The only exception is in the defense space, there are some things from a segmentation perspective that are cheaper to achieve on mainframes. But that isn’t a startup scenario, and those advantages are eroding as well.
IBM has huge margins on this stuff, so the typical play is use margin on the mainframe to win software and services deals. Startups need fast time to market, so it makes sense to overpay AWS by the drink than to overpay for a feast from IBM.
After noodling out how to make my docker images work on aarch64 and amd64, it was trivial.
This hardware is expensive and not as performant as any modern competitor. The software is arcane, confusing, and it is a pain for IBM themselves to keep supporting it. AS/400 is a costly legacy. AIX has no reason to be in a world that Linux and BSD exists - IBM owns Red Hat after all.
It was a cool technology. But it's definitely a thing of the past.
Replacing failing RAM sticks live are also something that, while quite cool and impressive, it happens to be quite pointless in today's world of clusters.
Current AS/400 is almost retrofuturistic in both its cool factor and disconnection from current actual needs.
But instead of managing a fleet of x86 servers, switches, routers, storage boxes (you may need a few of those), all liable to fail without warning, you have an exquisitely built datacenter that fits in half-a-dozen 19" racks (counting 2 for storage) where redundancy, failover, and easy maintenance are built-in at the hardware level.
If you design your APIs to be versioned from the start, you don't need to be overly concerned with that. Also, if maintaining a deprecated API is too resource-consuming (either developers or API translation logic) you can always make it return a message informing the user the said API will cease to function on a given date (you need to make the app display that, even if not updated) and shut it down after that. Any mobile app should have a way to be placed in degraded functionality mode for a number of reasons, API deprecation being just one of them.
It never works. There are insurmountable problems you notice once you try to design such a system. And yeah, AS/400 is an example of it not working too, as it was only usable as a hidden database layer and never survived contact with the users.
On the other hand, the obvious extension of the concept into development tools is a great idea that has been used to create novice-friendly toolsets all over. The tools always seem to "mature" away from it for some reason, and usually lose popularity on the process.
https://blocksandfiles.com/2022/07/19/ibm-storage-revenues-q...
There are still Aix features that aren't available on Linux and BSD, let alone what IBM i and z/OS offer.
As for IBM owning Red-Hat, it has come full circle, Linux only started taking off on big shops as IBM, among others, entered the game back in 2000.
AS/400 was based on the System/38 which had a capabilities-based OS and persistence built into the system from day one. (I remember the bad old days of JDK 1.0 before there was serialization which was awful for writing applets because more than half of your applet might be serDes code. I think Sun panicked when Netscape came out with a serialization library before they did.)
In the 1980s there was a fad for complex architectures like the Lisp machines, stack machines, the iAPX 432, etc. Common Lisp and the JVM put those to rest showing you could implement a featureful virtual machine in a mainstream CPU. My understanding is that was what System/38 was from the beginning.
IBM's methods have let them maintain compatibility despite moving the iSeries through several generations of hardware. It originally ran on their IPMI cpu, then later was migrated to the RS64, and now runs on POWER series hardware, the same as AIX (and in fact virtual instances can share chassis hardware with AIX instances).
So in fact there are services to companies still running today that originally ran on IBM's mainframes that have been migrated and migrated again, and have essentially always been up and available. The companies aren't forced to spend the money and time to plan upgrades because their previous hardware and OS isn't supported any more (contrast to Microsoft).
Lots of companies advertise upward compatibility. Some of them manage it for a single generation of hardware... after all, virtual machines are a thing. Continually migrating upward over a span of 45+ years is a technical achievement not matched by any other company.
The down side to this is that they're bound in some sense by technical decisions made long ago... so they can't modernize their software environment like e.g. Apple can.
Great idea - but with PASE they’ve effectively killed it. With PASE the abstraction is gone and everything compiles to POWER machine code, which makes it no more “abstracted” than AIX or Linux or Windows is. And they keep on encouraging customers and ISVs to do more with PASE, and more of their own products rely on it. Which means IBM i is going to die on POWER, and the whole hardware abstraction stuff, while used to great effect once (the CISC-to-RISC transition), is now pointless
A mainframe is usually running a hypervisor (VM) and underneath that hypervisor there are various operating systems running, z/OS is one of them. Circa 1989 I was in the Computer Explorers and we got to use VM/CMS on an IBM 3090 which is basically a single-user OS a lot like MS-DOS (though it is really the other way around.). To do software development on such a beast you would create a VM and log into it.
Of course you can run Linux or Java applications in a VM on z too so you can consolidate legacy applications on the same server with more mainstream workloads.
z/VM and PRSM are just virtualising (relatively) mainstream hardware, fundamentally no different than what VMware/Xen/KVM/VirtualBox/HyperV/etc do.
The rest are either (1) hardware architectures whose ISAs are much further from mainstream than 360/370/390/z is–aiming to provide high-level capabilities which are normally provided in software, making the distance between the hardware ISA and HLLs much smaller than normal; (2) software architectures which could be implemented in hardware (and occasionally were) to become instances of (1).
Hell, at one point I worked for IBM and even I couldn't get access to any decent entry-level resources (let alone beyond!).
https://en.m.wikipedia.org/wiki/ES_EVM
I wonder if the Hercules emulator runs their custom OS/360.
There were many later models, but compatibility isn't mentioned.
In some ways really advanced, in many ways really backward.
An “object-oriented operating system” in which the OS vendor can define dozens of classes (object types), even for their most obscure add-on products-but third party vendors and end-customers can’t define any at all, they can only use the ones IBM defines (very rarely, third party vendors might have some kind of deal with IBM, where IBM engineering defines a class for them)
An “object-oriented operating system” with no concept of inheritance - except many of the classes have defined some kind of “subtype” field/attribute which amounts to the same thing, except in an adhoc rather than general way.
Has this great “technology independent machine interface” (TIMI) idea-programs are compiled to byte code, and the OS translates the bytecode to machine code before running it - so moving a binary to a new CPU architecture doesn’t require a recompile. Except turns out the latest version of that bytecode (the ILE version) is completely undocumented outside of IBM, and IBM won’t release that documentation (except possibly under NDA and with $$$$ license fee)-which means nobody but IBM can write a compiler for it. Documentation is available for the original late 70s/early 80s version of the bytecode (OPM), but it has problems supporting languages like C (it works much better for 1970s versions of COBOL or RPG). Nowadays IBM will say “use PASE instead”-which is an AIX emulation environment, meaning kissing the whole bytecode idea goodbye and compiling to POWER machine code
A system whose native filesystem doesn’t even support nested directories (which it calls “libraries”)-although it has since added a POSIX filesystem that does, but lots of core functionality uses its native filesystem instead
To say nothing of EBCDIC, 5250 green screens, or RPG
And the OS itself is written in a grab-bag of different languages, including Modula 2, and two different top secret IBM-only dialects of PL/I - although the newer parts are written in C++ instead
But yeah it has also got other cool stuff like capabilities, tagged memory and a single level store (although many apps now run in private address spaces instead)
It is a design decision that dates back to the 1970s, and in the time they made it, they were hardly the only system to have made such a decision. Back then, truly hierarchical file systems were still a new idea - Unix was popularising it, Unix got the idea from Multics - it was primarily associated with research/academic systems and hadn’t yet spread much to commercial ones, which is where they were situating the product. On the other hand, S/38 adopted other highly novel research ideas, so why not this one?
Another factor is the UI: 5250 and 3270 block terminals work really well with fixed width fields, they don’t have good support for arbitrary length ones. Fields can’t be scrolled - if the field has a maximum value length of 255 bytes, it has to take up that many bytes on the screen. That is likely a factor which discouraged them from longer names and multi-level hierarchy. OTOH, MVS datasets have max 44 character names. They are pseudo-hierarchical, with 4 levels of “qualifiers” then a name, each max 8 characters, separated by dots. So I don’t know why they didn’t do something closer to MVS-maybe they thought “we are not a mainframe we are midrange machines that’s overkill for us”
The 8 or 10 character limit wasn’t uncommon for the 1970s. In those days, most Unix filesystems had a 14 character limit which is only a bit better.
They could have enhanced the core system to support nested libraries and longer library and object names. It would have caused backward compatibly issues for older apps but there are workarounds for that, like Windows having both short names (8.3) and long names for files; they could have some system to make nested libraries look like unnested ones on an app-by-app basis. They decided never to make those investments-they decided to just slap a POSIX filesystem on the side and leave the core alone.
It just seemed like with everything else sort of 'overkill' - 128bit address space - it would've been sort of an arbitrary amount.
Thanks again for the info
It is kind of bizarre how they overkilled / went bleeding-edge in some areas but held back in others. It makes for a strange, retrofuturistic system
I think one of my favorite things about it is actually IBM's Data Description Specification (DDS) [0]. You use it for the same reason you'd use a `CREATE TABLE` statement in SQL, but the syntax is much more legible / suited for that purpose, and the file is stored permanently (and used to spool up a "physical file" with the given format, where the data is actually stored).
Definitely encourage anyone who is curious about these / esoteric OS's in general to look into them - you can get hands on through IBM's "Cloud for Co-Creation and Enablement" (I believe it's been renamed) or PUB400 [1].
[0]: https://www.ibm.com/docs/en/i/7.3?topic=files-describing-usi...
https://www.reddit.com/r/UnreleasedGames/comments/133ukrl/co...
FTA: "AS/400 handled the verification and distribution of every order... [of a N64]"
This is a link to an Italian ad for Nintendo+AS/400 Advanced series[1] and the English one [2]
[0] https://www.reddit.com/r/lostmedia/comments/12m6yru/found_19...
[1] https://archive.org/details/lastampa_1997-05-08/page/n3/mode...
Once IBM i was ported to PowerPC, the vertical microcode was mostly rewritten in C++ and became known as the "Licensed Internal Code" and the PPC instruction set essentially replaced the role of the horizontal microcode.
[0] https://www.scss.tcd.ie/SCSSTreasuresCatalog/hardware/TCD-SC...
Bundling microcode with hardware, on the other hand, was standard practice.
The designers' idea was to build and sell the hardware and software stack as an integrated product, never to implement an operating system or RDBMS "in hardware".
For an explanation of this integrated architecture from one of its original designers, see
https://archive.org/details/insideas4000000solt/page/75/mode...
(registration and check-out required)
I heard once from someone who used to work for IBM, that although the most important parts of the “vertical microcode” were rewritten in C++, a lot of less important bits stayed in PL/MP (the PL/I dialect which compiled to the CISC IMPI native instruction set)-they just built a new PL/MP compiler which spat out POWER machine code instead of IMPI machine code-and so lots of PL/MP code is still there. And then there is also PL/MI, which is used for the higher level OS components which run above the “Licensed Internal Code”-it compiles to MI bytecode-and apparently that’s still around too. And still parts of the OS written in Modula 2. But brand new stuff, they prefer more mainstream languages such as C++
Not sure about the CISC-based AS/400, but current ones have bytecode translation (AOT compilation, IIRC) and run on POWER. In hardware terms, a pSeries and an iSeries are the same, with different microcode customizations loaded into the processors. I think it's even possible to run AIX partitions side by side with IBM i ones, if the processors (or TPM's, not sure) have a valid license.
https://bitsavers.org/pdf/ibm/system38/GA21-9331-1_System_38...
This instruction is either not present or not documented in the current Machine Interface[1], but I have no idea when or if it was removed.
[1] https://www.ibm.com/docs/en/i/7.5?topic=interface-machine-in...
That’s not actually the current Machine Interface, that’s the legacy one. The current one isn’t documented outside of IBM. IBM still supports the legacy MI, which is translated to the current MI - and high-level language programs compiled to current MI can even embed legacy MI calls as a kind of “in-line assembly” - but all that is converted to the new MI as part of the compilation process
I don’t think the microcode is different. It is true there are a few CPU instructions (memory tagging related) which were added for IBM i, but they are documented and there is nothing technically stopping some other OS from using them.
I thought the difference was that AIX, IBM i and Linux use different firmware. The firmware isn’t CPU microcode, it is just ordinary (albeit privileged) POWER machine code. Or to be more accurate, the POWER firmware has this concept of loadable modules (LIDs), and IBM i needs certain special firmware modules loaded which aren’t required for any other OS. This is why, even though QEMU can run Linux for POWER fine, and even AIX, it can’t boot IBM i-no one outside of IBM really knows what those special firmware modules do or their API, but without them the OS can’t boot. It is unlikely to ever happen without some serious reverse engineering, which would likely upset IBM and cause them to unleash their army of lawyers
This is a thing that always gets me thinking. How is it possible that the firmware has never been dumped? It's not like there wouldn't be some market for a machine that could emulate an IBM i in jurisdictions where requiring IBM hardware to run the OS is illegal.
From a business perspective, in most major markets, too much risk of being sued by IBM. There are some countries in which you don’t have to worry about that - but those countries have few or no IBM i systems, so are likely too small a market to make it worthwhile
I’m sure some hobbyist somewhere will build an IBM i emulator eventually - IBM probably wouldn’t bother suing a hobby project, even if the law was on their side. But it is a pretty niche thing, so the intersection of sufficient skills and sufficient interest is likely to be quite small - that eventually may take a long time. I myself think about it sometimes, but I doubt I’d ever do it - don’t have the time, other things I’d rather work on, don’t have any actual IBM i hardware and I think you’d really need that for reverse engineering
It is not dead.
You can absolutely add new fields to database tables on the system without updating every program - if you architect the software properly. Use embedded sql, explicitly select field names (ie don't do "SELECT *"), and put default values on new fields. I haven't written a new RPG program using the old file-specs in years - all new code has been embedded sql.
Not willing to give up SELECT *? Fine - create views on top of the real database tables to do your SELECT * from. Then you can still add new fields to the database tables without changing everything else.
Edited to add - if you want to add new fields to a table and not change all your old programs to use SQL, create a new table, transfer your data, and then create a view with the old table name using the same fields. You just have to test a little to make sure your view has the same record format id as the old table. Honestly it's pretty easy once you get the first one done and see how to do it.
We have the same thing and are currently migrating off as there are no RPG developers available for hire. Most of them are retiring. There are very few schools teaching RPG 3, 4, and Free.
The programming model for transaction managers like CICS on the 360 was similar in some ways to back end web frameworks, they even had clever code generation systems (see “X macros”) for writing serialization/deserialization in assembly language.
Later on, I briefly came to be in possession of an AS/400 that allegedly originally belonged to WKQX Chicago. I held on to it for a couple months but I didn't even have the slightest idea about how to go about hooking it up, let alone the proper cables, so I eventually let it go to another scraphound.
Then I met MCP, where everything is both hard to navigate AND deeply alien. ;-)
I'm sure Alan Kay is on my side on that one.
Nit, but you're not describing something that's "user-hostile," just something that's unfamiliar to the user that is you.
Alien could actually be very good and user-friendly, since a lot of the stuff we're used to frankly sucks, and we're stuck as at an inferior local maxima that's very hard to get out of.
True, but unfamiliar and hard to learn combine to make it forbidding to newcomers.
Case in point: https://retrocomputing.stackexchange.com/questions/26398/how...
> Case in point: https://retrocomputing.stackexchange.com/questions/26398/how...
Though that's MVS, which probably should no be conflated with OS/400. The former is all kinds of trouble because it maintains compatibility with stuff from really old and limited systems, while the latter is quite a bit newer than UNIX so could have alien-advanced "science fiction" features.
OS/400 has much newer ones and some of those are futuristic even now (the single memory map that encompasses fixed storage is a pretty cool one, even though deeply alien for most people).
The TRON MCP was definitely hostile. Not sure if its victims could have been considered "users", though.
https://www.google.com/search?q=tron+mcp
Master Control Program
But you can run a terminal in the browser. It’s a pretty common way to interact with cloud servers. And as long as the server isn’t on the other side of the planet it’s not noticeably slower than a local terminal.
The problem isn’t the technology, its the sad state of UI engineering.
I'm sure you can emulate the same performance in a modern webbrowser, it's just that no one cares, because no system administrator relies solely on web interfaces to get work done.
Increasingly, they do. And prefer to, because if it's in a browser, it's probably someone else's cloud system that they don't have to administer.
Our staff can run our ERP on a browser on a phone at the airport. I imagine it's hard to get 5250 on an iPhone. =D
I like the more modern stuff I work with now, but I truly miss the multivalue world some days.
Every once in a while I install the UniVerse personal edition and build something for fun. I will definitely check out scarletdme!
A quick guide to getting started with scarletdme: https://nivethan.dev/devlog/scarletdme.html
Unfortunately I never ported my editor and shell to scarletdme so this will be UniVerse/UD/D3 specific:
An editor like vim: https://github.com/Krowemoh/eva
A fish like shell: https://github.com/Krowemoh/nsh
scarletdme in the browser(this will be a 500mb download as it runs debian under v86.js): https://nivethan.dev/projects/v86/scarlet.html
The two things I do to start playing in a new MV environment both worked exactly as I hoped they would:
LIST VOC
And ED BP BLAH
I
PRINT "THIS IS A TEST"
FIBR
The environment feels very normal and reasonable, as far as a multivalue system goes. The only differences I came across are minor, like compiled programs going in BP.OUT instead of BP.O or the debugger being called DEBUG instead of RAID.I definitely need to set this up and seriously play with it! I periodically download a new copy of UniVerse PE to play with, but this is something I could actually do real work in.
Believe it or not, I actually like working in ED and/or AE.
At one point (back in the UniVerse job), I wrote my own shell. It was basically a REPL that passed whatever you typed to EXEC, except for one nifty trick. The trick was that there were two REPLs in the program - one which worked normally, the other executed within a BEGIN TRANSACTION/END TRANSACTION block and had commands to commit and rollback. Having two REPLs was a concession to get it to even compile because BASIC required that BEGIN TRANSACTION and END TRANSACTION form a block, you couldn't just arbitrarily call those commands. I didn't even bother building a history mechanism, it was literally just a REPL that could work within the context of a transaction. It was incredibly useful.
Honestly the best programmers are out here using ED. 0 syntax highlighting and you can only see 40-60 lines at a time. Insanity.
There is a 64bit version of scarletdme in the dev branch and the instructions are the same, it should work on both debian and centos.
No indentation. Cryptic op codes. Rigid fixed-column OP1/OP2/operation/result. Assembler without the power.
"Repulsive Programming Garbage".
I did a walk of shame around each desk apologizing profusely.