Comment by whartung
7 hours ago
I'm curious how much of the AS/400 architecture leaks out to the application developers. In the end, the vast majority of the work done on these machines was done in RPG and COBOL.
Curious if most of the architecture was visible to the actual operators, but the developers themselves were, perhaps, a bit isolated from it all.
Because, I don't think HN is a site for "Unix/NT" enthusiasts, but more so high level "computerists" in general. And I don't think that AS/400 application developers would be any less interested in computing than other developers.
Yet, anecdotally, over the years, as much as I've heard bits and pieces about how interesting the AS/400 system is, I've heard anyone talking it up. How they're able to do Cool Computing Thing because of the OS or architecture that can't readily be done on other systems at the time. How the unique features of the AS/400 solved their application and systems problems.
At my office, long ago, we were looking to replace our entire system, and we actually went to an AS/400 demo. But it was very expensive, and whatever they were selling wasn't really resonating with me as a developer, or my boss as a manager. Always wondered "what if" had we got such a system and had to use it in anger what it would have been like.
Anyone have any war stories to share?
I worked on as400's for about 15 years so I can give you some thoughts:
1-Stability: The as400 is the most robust/stable environment I've ever worked on for business applications. Many of our customers had no IT staff, just the accounting staff that would put in backup tapes, and the machines would run unattended for years until an OS version upgrade.
You're right that the underlying stuff that made it robust was not really visible or accessible to the developer, but it was the foundation that created a solid environment.
2-OS foundational capabilities: The integrated database, job scheduler, message queues, 5250 terminals with some nice capabilities (e.g. "subfiles" that are basically data tables), control language, etc. all combined to make a nice foundation for creating ERP style business apps.
3-RPG: I worked in RPG after coming from assembly language (video games) and my observation to the guys at the company was "hey, it's just like assembly, an opcode and a couple operands". It was a primitive language but because of the foundational items in #2, it only needed to move data, validate data and sometimes complex calcs, so productivity was good.
4-Non-ERP/CRUD backoffice apps: When the internet arrived and our customers wanted to sell online it became clear that the as400 was a square peg and the internet was a round hole. The foundational elements were designed for a different style of workload and interaction.
5-Openness (lack of): There were definitely times when the limits of the language and workload assumptions were different from the problem at hand (beyond just the internet/ecom stuff). There were times when we really felt like our hands were tied and couldn't just do what was needed for problem X, either using different languages or utilities.
One example was a pro basketball team ticketing/seat reservation system. Game packages could be different number of games (e.g. 10, 20, entire season) and number of seats in group could vary, and various other variables created a challenging search problem. We succeeded by getting creative with the DB and indexing and our code, but we felt boxed in while doing it.