Hacker News Reader

I've installed OS's on plenty of AS/400's for a prior job.

When everything goes perfect, they are still a complete nightmare. I can't imagine how you pulled it off, frankly.

Please feel free to share some of these nightmares. These systems are so surrounded by an air of mystique and vague hints of danger, and I've mainly tried to read up on the supposed benefits of using mainframes to get why anybody would use them.

I'm honestly interested in all kinds of IT horror stories, I need a reminder every now and then to keep the IT part of free from things that break and require tinkering (starting with unnecessary on-premise servers in small biz settings). Mainframes are obviously nine orders of magnitude beyond what I ever to, but still: the lessons of expensive and proprietary can be somewhat universal.

Once you get them running, they stay running. Like OpenVMS systems, you'll occasionally hear stories of how people lost them. They'd run without maintenance for so long that people would forget where they were when they needed it. My company has one that's been running all the critical stuff for years. It's the only thing that always works.

Btw, the original design was an awesome capability-secure system called System/38:

https://homes.cs.washington.edu/~levy/capabook/index.html

It was originally part of an even more awesome concept called Future Systems, which was supposed to replace the entire IBM universe with capability-based single-level storage systems.

http://people.cs.clemson.edu/~mark/fs.html

http://www.garlic.com/~lynn/submain.html#futuresys

It never got off the ground. System/38 and AS/400 are the only visible remnants of it, survivors from an alien world.

working on the iSeries (AS/400) currently and to be honest, I don't know of an easier to maintain system. DB2 is nearly automatic in maintenance and the only time we suffer an outage is paranoia when a multiple level redundant system went out and they wanted to replace the backup units with the failed. The size of these machines range from barely seeming bigger than a PC to 64 way and hundreds of terabytes. IBM was smart in that pSeries and iSeries share hardware, though running a Linux VM/partition/etc is more for sheer fun of it than work.

I used to joke that slackers should specialize in AS/400 "repair" with revenue coming from support and maintenance contracts. I predicted it would be a really easy job. Just regularly run reports or something to hand management to justify your salary. Take credit for the uptimes. And so on. :)

"though running a Linux VM/partition/etc is more for sheer fun of it than work."

I thought that was to get benefits of modern stacks running side-by-side with legacy OS/400 apps. You don't use it that way? And while we're at it, did they ever provide an easy, machine-usable interface between those instead of a web app simulating a terminal typing individual characters in like some mainframe places do? That seemed kind of ridiculous.

I didn't realize it was that big. I found in there this link...

http://www.jfsowa.com/computer/memo125.htm

...that illustrates the difference between knowledge and wisdom very well. Soya has a number of wise observations and recommendations that apply in enterprise software projects today. I've seen the same arguments. Just usually not that many at once given the narrow scope of any given enterprise tech.

He's definitely made me consider the Single-Level Store a weakness until proven otherwise. His argument that the customers saw no benefit except the performance tradeoff is disturbing and probably still applies a lot. I mean, the ability to avoid crashes, hacks, much technical debt, and many failed integrations with high-level machine are huge enablers. All people cared about was price for raw performance ratio, though.

Interestingly, I've been thinking similar to him on a number of angles as I look at these new projects. It's why I pushed CHERI processor over SAFE despite liking SAFE more. It's because CHERI is compatible with FreeBSD and MIPS while probably having less overhead. It's also why I pushed Java processors like JOP or Vega3 over another Secure Ada Target (or even Rust target) for embedded or enterprise servers. Python runtime or machine over LISP. And so on.

Time shows the path of least resistance with greatest performance and legacy integration must be taken. So, anyone wanting high-reliability or high-security has to work in a box. That's been rained on continuously for decades. ;)

Big Iron still has a place between commodity clusters and super computers. My dad used to work on them and he once referenced doing some operation on his local PC circa 2000 realized it would take several hours, so moved data to the TeraData machine where it took "Approximately how long it took my finger to lift off the enter key."

For some things having silly amounts of RAM and a few hundred disk drives and multi gigabit interconnects just works really well.

Not sure if Teradata will classify under big iron, though it does provide channel based connection to mainframe. IIRC Teradata nodes are UNIX based.

Not really my area of expertise.

IMO, it's less about OS than it is specialized hardware, you don't see multiple terabytes of RAM on normal motherboards. As such plenty of mainframes ran on a flavor of UNIX just like plenty of supercomputers used UNIX.

But, I can see people using other definitions.

Here's you a classic one I should've put in my other comment:

https://scs.senecac.on.ca/~ibc233/MS400.html

I still poke at them over this. Another was them running Hotmail on FreeBSD instead of Windows. Lots of problems when they switched. Least both experiences were good for debugging purposes. ;)

Note: The only thing better would be finding out Apple ran on a mainframe or AS/400 given Jobs' hatred of IBM. I doubt I'll get the satisfaction.

Let's just say it took me a while, and a lot of trial and error.

As someone who collects vintage computers my suggestion is to document the process. Having to re-discover an obscure command is just painful.

> Especially given that this thing can run Linux.

Interview with Linus:

What's the most amused you've ever been by the collaborative development process (flame war, silly code submission, amazing accomplishment)?

I think my favorite part is when somebody does something utterly crazy using Linux. Things that just make no sense at all, but are impressive from a technical angle (and even more impressive from a "they spent many months doing that?" angle).

Like when Alan Cox was working on porting Linux to the 8086. Or the guy who built his own computer using an 8-bit microcontroller that he wired up to some RAM and an SD card, then wrote an ARM emulator for it, and booted Linux (really really slowly) on his board.

https://www.linux.com/news/special-feature/linux-developers/...

I used to start the backup jobs on a AS/400 during a Summer job for my technical course.

The most interesting thing was while researching about them almost a decade later, I came to discover their programming model with a common runtime and a kernel level JIT for software.

.NET on Windows/WP, Android and iOS/bitcode might be the closest thing we have on current systems about that programming model.

The other interesting thing about them is single-level store. With a 64 (65-ish) bit address space, all your RAM and DASD gets mapped into it. So the objects in your program just have memory offsets, and the OS handles the underlying storage.

Their reputation for reliability is well deserved. The only time ours went down was for upgrades, and the few times we ran out of UPS power during storms.

> The only time ours went down was for upgrades, and the few times we ran out of UPS power during storms.

I'm surprised that you didn't have UPS for stopgap until the generators kick in. If you have a mainframe, it's probably for something mission critical to where a generator (or two or three for redundancy) is a good idea.

I'm curious what kind of business you're in where you can justify a mainframe and UPS but not generator, if you can talk about it.

This was many years ago - the firm wrote and sold accounting software for the AS/400, so while they were production machines, there wasn't really a 100% uptime requirement since there weren't end-users involved. The UPS was there to tide us over short power outages, and ensure a clean shutdown (IPLs after a hard shutdown took a very long time, as the OS would have to verify the whole filesystem).

Me and another guy were the only Windows programmers there. We put a friendly UI in front of the AS/400 via network calls (SNA APPC, later TCP/IP sockets) to an endpoint that the RPG guys wrote for us. Later, we wrote an Excel add-in to allow the users to access their financial data from the AS/400, and this became so successful that the entire company is now based around the same technology. Sadly, I don't get a percentage.

Thanks for sharing! That makes a lot more sense.

> Anyway, the instructor pointed me to a room with an AS/400, a huge stack of tapes (for the OS), a huge stack of manuals, and basically said "just do it."

"You're gonna learn to swim the Stennis way."

Me and a friend went to a programming class ages ago that was teaching AS/400 and programming in RPG/400 on them. That was a funny language. I was working at the state for a bit too, doing smaller programs for the database of inhabitants. Some of the bigger industries had a few AS/400 too but never got a job there programming.

Yeah, this same college started teaching RPG around the same time all this happened. I took two semesters of RPG programming, but I've never used it for anything in the real world.

RPG, at least back then, didn't suit me. It was very much column oriented, with this oddball tool (SEU - Source Entry Utility) that you had to program in. I understand the ILE version(s) of RPG have gone to more of a free-form format, but back then it was a royal pain.

RPG is "Repulsive Programming Garbage". It is the worst production programming language ever conceived. It was designed in the 60's based on the IBM 402 tabulator paradigm, to bridge programmers from plugboard wiring, to the 360 stored-program mode. It has long outlived its usefulness. Yet it lives on, entrenched in legions of schlubs who, like Bre'r Rabbit, have never known anything else.

No, wasn't my favourite programming language but at least it worked :-)

When was it? Must be at least 20 years ago judging by the Netware reference.

1996/1997 or thereabouts.

Did it at least support Ethernet by this point or did you get to learn all about Token Ring as well?

Did it at least support Ethernet by this point

Luckily, yes. It had an Ethernet port and TCP/IP, so once it was up and running, getting it on the 'net wasn't too bad. The biggest challenge was actually getting the IT dept. to assign us an IP address, etc. Luckily I knew the IT guy pretty well from doing work-study with him earlier, so it wasn't too bad.

On the other hand, while you could telnet to the thing, you couldn't really use plain old command line telnet, which usually assumes something like a VT100 or VT200 terminal. AS/400's usually want 5250 terminal emulation, not VT100/220. So I had to find a 5250 terminal emulator to use to connect to the system and actually work with it.

I would love to read a blog about this.

Perhaps a different person writing about a different system each month.

I'd write something about my experiences, but it was all so long ago now that I doubt I remember enough details to make it interesting. Still, something like this would be a fun project to do again in some ways. I've even toyed with the idea of doing something like the guy in this talk, but with an AS/400. The biggest reason I never did, other than the size/power/cooling issues, was the software licensing. I imagine an actual OS/400 license is crazy expensive, and if I just wanted a Linux server on vintage hardware, I would just fire up one of my extensive collection of old Sun SPARC boxes. :-)

Was it just the escape codes that weren't compatible, or was the as/400 trying to talk in EBCDIC?

A normal telnet connection will be assumed to be something VT100-ish, so it won't try to use EBCDIC. If you send one of a few specific values for the terminal type, though, the AS/400 will use block-oriented EBCDIC comms. This is even documented in RFCs 1205 and 4777.

A bigger issue can be with trying to send each of the 24 function keys when a VT102 didn't have any.

Wow, I dislike Token Ring. You just gave me flashbacks to my first network admin position way back in 1993.

Thanks. ;-)