AS/400 i Mystery Solved–Again?

April 4, 2011 Pat Botz

I read with much interest the January 31 article, AS400 i Mystery Solved written by ITJ editor-in-chief Tim Prickett Morgan in response to a question posed by a reader of The Four Hundred. Reader Dan had a very good point and may well be partially right. However, after working with numerous i shops in the last 15 years or so, I have come to a somewhat different conclusion. I believe the biggest problem with the declining use of the AS/400 has been the fact that it was too far ahead of its time! Let me explain.

About 10 years ago, while I was still working for IBM, I spoke to a user group in Los Angeles on the topic of single sign-on. I had been describing the technologies, already available to our customers for free, that could be used to create a single sign-on environment between a Windows domain and the iSeries (or AS/400e or whatever it was called at the time, I’ll refer to it as the AS/400 in this article). I was well into the presentation when I sensed and saw a look of “deer in the headlights” from the audience. Finally an audience member blurted out: “This stuff is, I’m sure, really interesting to you, but just tell us the *@#$!^% command to run and get on with it!”

Aside from the fact that this was at least partly due to my presentation abilities, I believe there was something even more telling in that statement.

In order to integrate the AS/400 into a Windows domain authentication environment, it must be done at the technology level. It can’t be hidden behind a single command or set of commands that the AS/400 administrator runs and then it just works. Both the AS/400 environment and the Windows environment have to be configured. And you certainly must understand the underlying technology to troubleshoot problems that may occur on the other end, on your end, or somewhere in the middle. When integrating disparate environments and where different people administer those environments, you have to work and communicate at the technology level. There’s no way around it except for the competing platforms to make accommodations for the other.

But the audience was unable to get their heads around the technology involved in single sign-on. It seemed to me at the time, that they just didn’t want to be bothered with the mundane, boring, and foreign technology. “Just give me a command,” they cried.

I spent a lot of time mulling this experience over and talking about it with different people. At first I thought, “What a bunch of babies!” In a distributed, heterogeneous, computing environment, you have to deal with the non-AS/400 systems and you can’t expect the AS/400 to always be able to hide the complexities of the other platforms.

About this same time I began to notice another unexpected (to me at least) statement coming from AS/400 administrators. “You can’t do that on the AS/400.” It was usually aimed at their Windows administrator counterparts. The first time I consciously registered this statement was when a customer wanted to secure dataflow between their AS/400 and their Windows environment. The Windows administrator said “Let’s just use IPSec.” When asked why the seasoned AS/400 administrator thought this couldn’t be done on the AS/400, he said, “There’s no IPSec commands.” I knew full well the AS/400 supported IPSec. But the AS/400 administrator was also right. There was no IPSec command. You needed to go through the VPN support in iSeries Navigator, and you had to understand a fair amount about what IPSec was and how it worked.

I noticed another curious state of affairs as I worked with shops to implement single sign-on. I would explain how it worked to both the Windows and AS/400 administrators. Almost invariably, the Windows administrators would grasp the concept long before the AS/400 administrator did. They often became the champions of the project. In fact, I believe many AS/400 administrators supporting single sign-on still don’t really understand how it works.

Putting these experiences together resulted in an epiphany, of sorts, for me. Remember the marketing mantra: Manage your business, not your computer? The beloved AS/400 systems actually came pretty close to this ideal. AS/400 administrators, in general, had never needed to understand the gorpy underlying technology details of their systems. Why should they? The system did a better job of hiding technology than any other system available–and it still does!

So why does the AS/400 have a reputation as being old technology? Maybe it is because the people who managed and programmed them understood their business processes and needs better than they understood computer technology. They could afford to focus on the business because the AS/400 allowed them to focus on business requirements rather than the technology requirements of their computers. By contrast, the folks managing all of those PCs in the local area network, by necessity, and then their successors managing racks and racks of servers, had to understand how much of the underlying technology worked just to keep those systems and the LAN up and running.

And why, pray tell, was this a problem? It wasn’t. At least not until the AS/400 (and the applications that run on them) had to be integrated into local area networks with other non-AS/400 systems. This integration was, more often than not, driven from the PC side of the IT shop. They came asking things like, “Does your system support NetBIOS or SMTP?” AS/400 administrators had rarely, if ever, had to deal with their systems at this level. They just configured the mail server and were done with it. They didn’t need to know about SMTP or POP or any of that other gorp. So, often times, the answer to the PC folks was, “You can’t do that on the AS/400.”

Ironically, the AS/400 was able to support most of these requests. But it wasn’t immediately obvious to most AS/400 administrators. Some of the confusion was just miscommunication due to differences in terminology. Many of the requests could have been supported by writing utility programs that used system APIs; i.e., by using the technology directly rather than system commands. But AS/400 administrators were, by and large, not aware of this. And rightly so, they didn’t need have to know the technology involved when it was just the AS/400 or AS/400-to-AS/400 networking. In those cases, they focused on what they were trying to accomplish (i.e., send mail) rather than the technology needed to actually send mail (gorpy software). The AS/400 may have even used the same technology under the covers, but AS/400 administrators were able to be blissfully unaware of it!

So, why is the AS/400 market declining and perceived as old technology? I believe, literally, that because it was so far ahead of its time that many of the shops using it were unable to understand how to integrate the system with the changing environment around it. This led to the misconception of old technology and the need to move on to “newer” more “flexible” systems.

Brilliant, Pat. Just freaking brilliant.

Thanks. I think.

–TPM

Patrick Botz is the principal consultant and founder of Botz & Associates Inc. He is also president of Valid Technologies, LLC, a biometric middleware ISV. Pat spent nearly 20 years working at IBM in various security roles including lead IBM i security architect, IBM eServer security team, and the head of IBM Lab Services Security Consulting practice. Check out his Website at www.botzandassociates.com. Send your questions or comments for Patrick to Tim Prickett Morgan via the IT Jungle Contact page.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search