Get the top HN stories in your inbox every day.
icedchai
jacquesm
As drive packs come those were pretty compact already. Prior to that a 200 meg pack + drive would be the size of a top loading washing machine. Packs were removable, you'd screw them into place with a handle at the top and after closing the lid they'd spin up. Massive gear, a pack of 11 platters weighed a couple of kilos and would spin up to several K rpm, and woe to you if the pack was written on a drive with a different alignment, then you'd have to get the heads re-aligned.
This was one of the reason why most machine to machine data transfer was done using tapes. Slower, but more reliable and much, much cheaper. Packs would usually stay within the same datacenter, and likely would be assigned to the same drive though theoretically there was no reason why they couldn't be moved to a different one that had been calibrated with the same calibration setup.
teh_klev
Back in the 90's I worked as a field engineer and had a few of these on contract. They're really nice machines to work on and a common task was replacing these hard disks when they failed. The IBM field service manuals were pretty good and you could repair/replace pretty much anything on-site. They look like monsters but they're actually really friendly to field service techs.
markus_zhang
Considering the power of mainframes, I wonder why there are few games made.
racingmars
To be nitpicky -- The AS/400 is not a mainframe, it's what IBM calls a "midrange system" positioned between commodity x86 servers and mainframes. Today, the AS/400 OS (OS/400, or as it's known now, IBM i) runs on IBM's POWER servers. For a typical IBM i system you're talking a couple 10s of thousands of dollars, for a typical mainframe you're in the hundreds of thousands.
Also regarding the power of mainframes: in the case of AS/400, it's definitely not what I would call fast. Everything runs on what is essentially a virtualization layer... the AS/400 instruction set (MI, or "machine interface") doesn't exist in any hardware, it's just run on top of a translation layer on top of (these days) POWER. It's a very weird system from top to bottom.
As for actual mainframes, traditionally the power came not from raw CPU power, but from an architecture that efficiently handles parallel I/O. Definitely powerful for batch processing of large amounts of data, but not necessarily optimized for something like games.
skissane
> Everything runs on what is essentially a virtualization layer... the AS/400 instruction set (MI, or "machine interface") doesn't exist in any hardware, it's just run on top of a translation layer on top of (these days) POWER
To nitpick your nitpick – MI isn't interpreted, it is compiled to machine code. Not JIT, AOT: when you compile a program, it actually goes through two steps. First it compiles the source code to MI, and saves that in the executable (program object). Second, it compiles the MI to machine code, and saves that in the executable too, in a different section of it. At runtime, the MI is ignored and the machine code is run. There is even a command to delete the MI part of the executable (called deleting the "observability"), and your program will still work after the MI is deleting because it isn't actually used at runtime.
When they transitioned from custom CISC [0] to POWER, if you still had the MI in your executable, the system would automatically recompile it to POWER machine code. If you had deleted the observability, it wouldn't run, and you'd have to recompile it from source. Theoretically, the same would apply if IBM ever decided to move IBM i to some other platform than POWER (such as ARM or x86), although I doubt that is ever going to happen.
Also, there are actually two versions of MI, old MI and new MI. Old MI (OMI) was used with OPM (Original Program Model) executables. OMI was the original AS/400 machine interface, and is in fact descended from the System/38 machine interface. Around the same time they moved to RISC, they introduced a new program model (ILE, Integrated Language Environment) and new MI (NMI) to go with it. OPM programs still run, but now the system translates OMI to NMI, and then NMI to machine code. Now, the interesting thing about NMI – OMI was indigenous to the 38/400, whereas NMI was actually just the internal intermediate language used by IBM's compilers on other platforms (such as AIX and OS/2), known as "W-code", with some 400-specific extensions. So, in the contemporary ILE world, MI is really just a compiler intermediate language, like LLVM IR is, and so isn't really anything that different from what happens on AIX or Linux or Windows or z/OS – the history and the marketing make it sound a lot different.
Now, I agree that IBM i isn't necessarily that fast. It has a very complex software stack, and while I find that complexity fascinating, no doubt it imposes performance costs. But the "virtualisation" aspect in itself doesn't cost much at all. I think the widespread use of 128-bit pointers is likely a bigger issue – although, the 128-bit pointers don't get used directly, they get converted to 64-bit pointers before actually being used – still that has to have some performance cost which other systems don't have to deal with.
But you can opt out of that by running your code in a "teraspace", in which case you just use 64-bit pointers and the 128-bit pointers are not used. If you are running Java code or PASE code (AIX compatibility subsystem), both use teraspaces, and if you avoid invoking OS services (as in a compute-heavy workload), your performance should be close to that of AIX on the same hardware.
[0] the CISC instruction set, IMPI, was inspired by the 370 instruction set but not compatible with it. For AS/400, I don't believe it has ever been publicly documented, but I'm led to believe the 400 CISC instruction set was just an evolution of the 38 CISC instruction set, which was publicly documented in this manual: http://www.bitsavers.org/pdf/ibm/system38/SC21-9037-3_IBM_Sy...
Aloha
I've often considered AS/400 a "road not taken" in systems engineering, one that would have been much more influential had it come out 15 years sooner (though if it had, the hardware would not have been performant enough to run it), particularity the abstraction between memory and storage being handled by the OS rather than the application. The machine independent codebases, and other features and bonuses and have allowed it to continue to live on at minimal cost.
sterwill
Thanks for all those technical details! For anyone else who'd like a broader tour around the AS/400, I can recommend "Inside the AS/400: Second Edition" by Frank Soltis. I bought it used for just a few dollars and really enjoyed learning about the evolution of the platform from one of its original designers, even though I doubt I'll ever put my hands on one directly.
monocasa
I don't think the parent said that it's interpreted, only that it sits on a translation layer which is true.
trasz
Does that mean part of the compiler is security-critical?
hindsightbias
Depending on the server generation, i is supported on bigger Power servers (E980).
Yuioup
Is AS/400 Open Source?
skissane
No, it is a closed source IBM product. I've seen copies of its installation media on "warez"/"abandonware" sites before, but there is no emulator for it so you can't run it unless you have real hardware. IBM has recently got quite keen on porting open source software to its Unix compatibility environment (PASE) – it is a way for IBM to make it feel fresher and more modern and more accessible to mainstream developers, for only a modest investment of resources.
Even if you download the installation media from one of those sites, you can't run it because there is no emulator for it. Now, it is POWER, so in principle there could be an emulator, but QEMU only supports running Linux and AIX, not IBM i. Probably if someone wanted to, they could enhance QEMU to support running IBM i, but it would be a lot of work – IBM i exploits various obscure features, not just of the CPU, but also of the firmware, which AIX doesn't, and so understandably QEMU/etc don't implement those obscure features. Commercial emulators don't really exist either, because if you start selling a commercial emulator, it is almost guaranteed IBM will sue you.
I think an emulator for the classic CISC hardware would be really cool – probably make the most sense to start by emulating System/38, then try to extend it to CISC AS/400. Who would ever carry out such a gargantuan and pointless task? Probably some day, eventually, someone will do it. And it will be cool.
There were commercial third party emulators, of sorts, for the System/38, such as California Software Products' Baby/38 package. However, Baby/38 wasn't full system emulation, it was actually just an RPG compiler which supported the System/38 dialect, and had a limited emulation of OS services which RPG programs commonly used. They later followed up with a successor, Baby/400. I'm sure it was quite useful to people back in its heyday of the 1990s, trying to port their RPG business applications to Windows. Practical, but not very interesting from a technology perspective.
kej
I would imagine there's a lot of overlap between places that use mainframes and places where anything unauthorized, let alone games, will get you fired.
ASalazarMX
Definitely any company that could afford a (then) AS/400 wouldn't look kindly on using it for gaming.
That being said, some did, otherwise these little games wouldn't exist. At one of my previous jobs, the end of the year was boring, no clients and projects would be on hold until January. One of those years I wasted a week making a crude reversi game complete with CPU player, and it was well received among the other programmers.
We tried to make a checkers game, but turns out a checkers CPU player is a lot harder than reversi for business programmers.
Accujack
We still have two of them in production, running old heavily regulated applications from decades past.
If we loaded games on them, I doubt anyone would notice for a while.
Honestly though, I've had to take care of these dinosaurs for so long I can't stand to look at them much less log in if I don't have to do it.
markus_zhang
Is it possible to make a gui game?
123pie123
many moons ago, I was lucky enough to have root (QSECOFR) access and treat the box as my personal play thing - even while running prod stuff.
we could have put games on it, if we trusted the developer - well may be just the dev server.
Windows NT 4 and Windows 3.11 was more interesting at the time with AOL dial up access
markphip
You would be surprised. I worked for an AS/400 ISV and while the customers were all huge companies, the part of the company that ran an AS/400 was usually very small and had a lot of autonomy.
markus_zhang
Agreed, that's my thought too.
jacquesm
Because they cost a ton of money to own and operate, and because they typically lacked graphical output, either in real time or at all.
But that didn't stop programmers from writing games for them, those just didn't enter distribution, they were typically just run locally.
Lutzb
I remember IBM mainframes being used as a backend for the MMO Taikodom by Hoplon entertainment. https://en.m.wikipedia.org/wiki/Taikodom
Jondar
I worked for a company that had Tetris and an analog clock app installed on their AS/400
Get the top HN stories in your inbox every day.
Back in the 80's and early 90's, my uncle's company had an IBM System/36, which was a predecessor to the AS/400. They used it for accounting. The thing was a monster, and it looked exactly like the top photo on wikipedia: https://en.wikipedia.org/wiki/IBM_System/36
It had 8 terminals attached, and a couple of huge line printers. We opened up the main system cabinet one day, and the hard drive (about 200 megs?) was over a foot wide. The system also used "disk cartridges" which were several 8 inch floppies in a box. Supposedly the system cost almost $200K (in 80's money.)
In the mid 90's they replaced it with PCs.