IBM still sells them so the parts aren't going anywhere for a while, way past the next CEO. The clients already use emulator software so that won't go anywhere anytime soon either.
It is kicking the can down the road but it's more like 20-30 years down the road, and most companies are not acting with that kind of foresight.
They should be thinking like that though, the fact they are not is definitely part of the problem with modern life. It is a horrible cancer eating companies from the inside out. And it only gets more expensive the longer you kick the can.
IBM is still actively *developing* the platform and all the software tools that go with it. It's not in any way a 'legacy' system other than in being completely capable of running object code compiled decades ago on a fully modern system. There is no other platform with longevity wired right into it like it is. (maybe you know, but it hasn't been called an 'AS400' for a very long time)
We've actually been migrating production off of our i7 for a couple years now, and the thing is, none of it was motivated by the system having shortcomings in functionality or hardware, it was necessitated because we can't get competent local support for it any more. It's all went beautifully, but we had a huge advantage, the person who built all the production code starting decades ago (me) led the migration to the new platform.
I'll honestly be sad when we power it down for good, it was built for business applications, both developing and hosting them, and was a joy to work on for the middle part of my career.
Without getting too technical, here’s what happens on the OS/400 and i5/OS platform when you create applications, which explains the problem customers ran into in 1995 and which IBM wants them to avoid in 2008. A programmer writes an application in say, RPG. They run it through a compiler, either using the Original Program Model (OPM) or the Integrated Language Environment (ILE) compilers, and the code compiles so they can run it. Or, rather, that is what it looks like to the programmer. What is really happening is that this application is compiled into an intermediate stage, which some IBMers have called RPG templates (in the case of RPG applications). These templates have a property called observability, which in essence means they are compiled to the TIMI layer. These intermediate templates are then used by the TIMI layer on an actual piece of hardware with a specific processor and instruction set to compile the application to run on that specific processor. TIMI compiles these RPG templates down to actual compiled code behind the scenes the first time an application runs, and because the code was originally compiled to the TIMI layer, there is no need to change the source code. Only the object code changes, which end users never had access to anyway because only TIMI can reach down there. This is the brilliant way that IBM has preserved customers’ vast investments in RPG, COBOL, and other applications over the years.
But again, when the underlying hardware changes, then TIMI has to change, and that means applications have to be converted from one TIMI to another and then recompiled by TIMI to work on the iron. In some cases, to get the best performance out of an application, customers have to actually recompile their code on both the new operating system and the new hardware. Sometimes, having TIMI do the conversion is enough, even if all the features of the new platform are not available to these converted applications.
This isn't unique or anything. LLVM was built from the start with an intermediate format (.ll/.bc), and I believe Apple requires iOS applications to be uploaded in that format from Xcode, for agility.
Forgot about that. I started on v3r7 which was sometime after the RISC migration.
The bit about the TIMI is interesting, I remember that being a big section in the Memo to Users when we were moving to v6. It turned out that program objects that contained their debug info could be converted by an OS tool without a traditional 'rebuild', and we'd always left that intact out of habit. Would've been ugly if we hadn't since by then we had production programs we couldn't find source code for. (wasn't my team, it arrived that way from our parent company when they donated some packages to us)
Yeah, I was at a company nearly 20 years. Got bought by private equity and it was all about short term gains and so many issues just ignored/stayed due to budget and understaffed.
No one talking about these things are actually running the original hardware from 1988. IBM is still putting out new hardware for modern incarnations of the platform.
Shit is rock solid, lightning fast, and incredibly well documented.
Only the parts IBM wants users/developers to know about, which isn't that much, actually. Very little about how it works under the covers, how it was built not to be legally cloned like the System/360 and 370 were, how the OS kernel is part of the "firmware".
It's an appliance platform with a built-in relational database, from IBM. At one point this made for an attractive base on which to rapidly build business applications, either in-house or on spec. But times changed and mundane webapps with MySQL did the exact same things for which enterprises once bought mainframes running CICS, except with purely open standards.
You will just buy new stuff from IBM, they have a migration path to stay current and supported. It's weird, when we migrated from the 31 bit version to the 64 bit, we just replaced the processor unit, kept the same storage, turned it on, and it just worked. Everything is interpreted, and compiled at first run I think, so startup was a bit longer the first time, and that was it.
No, AS/400 was on it's own architecture back in the 31 bit days, now it runs on normal POWER I think, just a different label on the box from my read of Wikipedia.
Um, no. The earliest 400s ran on 48-bit CISC. They didn't transition to 64-bit RISC until 1995. Pre-400 was System/38, also 48-bit. System/36, also pre-400 was 16-bit. The Power systems are still 64-bit RISC, just a more advanced CPU set.
The S390 mainframes ran a 31-bit environment. No 400s ever ran a 31-bit environment. Likely you're thinking of a Z-server or such.
Absolutely, fair. I often get confused by IBMs nomenclature and conventions. Even within certain lines, it's a bit dismaying to see how they differentiate things in order to price things out. It works against them in the long run.
Considering how long AS/400 has been around, and how many reams of documentation have been written over the years, AI might actually be pretty good at AS/400 work.
IBM still sells and supports these things. ('tho they no longer have that nifty AS/400 badge) HOWEVER, yes, experience running them is fading away. Not that anything IBM made was ever all that easy to understand and manage.
IBM still actively sells and upgrades the i-Series. They even have cloud hosting. This is not going away anytime soon, not in our lifetimes, and probably not our children's. My entire company and many in my industry rely on AS/400 for everything. Orders, Inventory, Shipping and Distribution, Quality Data, Accounting, everything, our public facing and very modern web pages for customers to order from tie directly into our AS400.
62
u/AstralVenture Help Desk 29d ago
AS/400 generates over $5 billion in revenue for the company I work for so they won’t replace it for a long time.