IBM i Chief Architect Will Gives N2i Some Platform Pointers
January 10, 2024 Alex Woodie
It’s hard to find someone more knowledgeable about the ins and outs of the IBM i platform than Steve Will, who holds CTO and chief architect titles at IBM. So when Will accepted an invitation from COMMON’s N2i (New to IBM i) group to speak to IBM i newcomers this week, it was a good chance to pick up something new.
One of the first things that IBM i newcomers will notice about the IBM i is that it’s an unusual platform, in several regards. For starters, it’s older than many platforms, being able to trace its lineage back to the 1980s. It’s also built differently than many other platforms, and those differences are part of what give it value.
During his presentation this week for the N2i group, Will, who leads development of the IBM i at the IBM Lab in Rochester, Minnesota, discussed the IBM i’s composition in relation to traditional kernel-based operating systems, such as Unix, Linux, or Windows.
“IBM i, one of its defining features, is that it’s a layered architecture that is future proof,” Will said. “If you have a piece of code that you compiled on IBM i or one of its predecessors and you haven’t changed one bit of its of its compiled code for 10 years, 15 years, 20 years, 30 years, you’ll be able to continue to run it on Power Systems that have IBM i today.”
The reason for that is because IBM i employs a machine interface (MI) that sits between the code developed by the user and the code that gets run on the hardware. Instead of writing code to run directly on the hardware, Will explained, IBM i users write code that runs on the MI, and IBM takes care of everything else. That protects the user from having to worry about changes to the hardware, he said.
“So if you’re writing application programs that get compiled directly to that [hardware], and now somebody changes how memory is managed, what the different CPU instruction sets are, whatever – you’re going to have to rewrite your program, or at the very least you’re going to have to recompile it to get it down to an operating system set of instructions that run on top of that stuff,” Will said. “We have an operating system architecture [in IBM i] that prevents people from inserting themselves into that operating system, thus being able to completely protect the powerful kernel of IBM i.”
This prevents third-parties from being able to develop things such as a driver for a new storage device, for example. Instead, IBM must develop the driver. That makes the IBM i operating system both more expensive to develop and more complex, Will concedes.
“If you’re new to i, this is not a basic kernel operating system,” Will said. “You can’t mess with it, but the people who use it gain tremendous benefit from that.”
Another unique aspect of IBM i’s architecture that has paid big dividends over the decades is single-level storage.
Every piece of data in IBM i is treated as if it’s residing in main memory on the Power System box, even if it’s stored on a disk or a tape drive. It’s given an address in memory, and IBM provides pointers to get to that data, Will said.
“It has served us really, really well in terms of being able to add things, like the various kinds of storage that we have these days, as well as being able to optimize how we use the data on our platform,” Will told the N2i attendees. “Db2, the integrated embedded relational database that’s in IBM i, works together with the storage management in our platform, so that you don’t have to manage your storage. You don’t have to manage your database to the level that you do on other platforms. And that level of simplicity, because you don’t have to manage those things, means complexity within the operating system, but it also gives us the advantage, for example, to adapt our performance.”
The longer one runs a workload that stores data on Db2 for i and uses the database’s query engine, the more the system “learns” about how one is using that data, Will said. “And we move data around within your storage and memory and so on, so that it will get faster and faster and faster over time,” he said. “This is not something you can do without storage management tools and performance management tools on other operating systems. So it is a uniqueness to IBM i.”
Having built-in automation like that is another important aspect of the IBM i architecture, Will said. Many other platforms require a small army of operators, system administrators, and storage and database experts to run, maintain, and optimize. But since IBM i does many of those operations on its own, IBM i shops can often avoid hiring those people or consultants.
Another aspect of IBM i that’s unique is that it was designed from the beginning to be object-oriented, in that it maintains strict controls over what is a piece of data and what is an executable object. As Will explained, this provides a level of security for IBM i that is absent on many other platforms.
“[T]he architecture protects the platform and all of the things that run on the platform from things like viruses and Trojan horses, which are essentially impossible to write on IBM i,” Will said. “Generally speaking – generally speaking – a virus is a piece of code that inserts itself into the kernel of the operating system and does something that you would think only the kernel should be allowed to do. There is no way for you to write a user program that inserts itself into the IBM i kernel. It’s not that it’s hard to do. It cannot be done.”
If someone managed to get into the IBM i operating system and change some of the bits around, other parts of the operating system would automatically detect it, Will said. “It would discover that things were wrong and there’s no way to do that from the outside world,” he said. “So a virus typically thought of as coming from the outside world cannot get into IBM i.”
Will also popped a couple of myths and misconceptions that people often have around the IBM i, such as that it’s so old that it doesn’t have a relational database. While it’s true that today’s IBM i can store data in the non-relational formats used by its S/34 and System/36 predecessors, the truth is that the vast majority of workloads on IBM i are utilizing the integrated Db2 relational database, Will said.
“Those things can still be done on IBM i because we tend not to stop you from doing old outdated things,” Will said. “If your business still depends on a S/36 program that had its data in a non-relational form, we don’t force you to make it relational
Another myth is that the IBM i can’t run open source software. In reality, the IBM i has its own AIX runtime that allows it to run just about anything that can run on Unix, Will points out. And while some people may denigrate the IBM i for ugly greenscreen interfaces, users can also develop fancy new Web or mobile screens if they like.
“We rarely remove older technology because there are customers whose businesses depend on it and there’s no specific reason for us to remove it, in most cases,” Will explained. “But for that investment protection, we sometimes tend to be looked at a platform that does things in an old way. We could do it in a new way, and probably many of you are involved in making new ways happen wherever you’re working these days.”
While IBM’s IBM i business is not as big as it was in the AS/400’s heyday, it is still quite profitable. According to Will, the IBM i is the top revenue earner in the Power family, and has been experiencing solid growth in recent quarters, sometimes approaching 10 percent per quarter. The reason that IBM i continues to be such a profitable business for IBM, Will said, is the value that the platform returns to its customers.
“More than 95 percent of our customers say that the return they get on the investment that they make in IBM i is the best of all the technologies that their organizations use,” he said. “[M]ost of our clients tend to think about IBM i as being their mainframe, they’re much-less expensive, but just as reliable mainframe. They may have Windows in their business, they may have Linux in their business, but the core workloads that run their businesses run on IBM i.”
IBM executives today recognize the value that IBM i brings, which has not always been the case, Will said. But because of the continued profitability and high customer satisfaction rate of IBM i customers, IBM today is happy to invest in the platform, he said. That in turn will help to keep this platform going strong, he said.
“I guess if you wanted to be cynical, you could say it’s like a cult,” Will said. “You’re getting value from IBM i that you don’t get from those other kernel-based operating systems, and people who have grown to depend on that really value that.”
Alex – excellent job as usual.
He does always do a good job, doesn’t he? Thanks from me, too, Alex.
Very good read Alex, Congrats! And even good to remind all this to current users and naysayers – your business is on the “best, futureproof business platform”.
A small typo – System 38 already had the relational database, maybe you wanted to write S/34 and S/36.
“Object oriented”? If that’s Steve’s verbatim I’ll take it but I believe “object based” is the better term.
Back to they System 38. Code compiled after CPF 2.0 will run on a AS/400, oops, iSeries eServer 400 (that’s what my most recent t-shirt says). Don’t believe me? Type ‘CALL QCL’.
“denigrate the IBM i for ugly greenscreen interfaces, users can also develop fancy new Web or mobile screens if they like”
The platform is perceived also through UI lenses, how can management miss that.
I always will be convinced that not having invested in a pure graphic and improved remote display protocol is an error. With standard GUI components focused to ERP style dev.
5250 and DDS is standard, ready on the system, and every person working on IBMi can bring such knowledge elsewhere lowering costs immensely without fragmenting and retraining. Web wasn’t born for ERPs, session based style, and there are just too many ways to do things and fantasies and a framework a day.
If we can reduce the essence of IBMi is not to push complexity to its users in virtue of a beautiful architecture.
I have a PGM, I can move it seamlessly to a new machine. I’ve stock job queues for coordination. Database… print a barcode with stock software? done…. stock Apache that I can use… etc…
Now I’ve fired up a fat RDi 9.8 on my windows client and I cannot debug a machine installed one year ago or so because lacks some PTFs.
I’ve a new consultant in for a quick work… well he can touch “the web display” part in reasonable time due to javascript hell dependency just to render a table to video. Ah, he needed an hour and more to download the new RDi to open a back end RPG-free because SEU (the stock editor of the machine) cannot properly syntax check the language (!).
This I call pushing complexity to its users. An IBMi anti-pattern.
Of course many things would have been solved by an improved incremental thin terminal graphic protocol with over it basic components to build ERPs, with an improved SEU using such facilities and DDS or alternative declarative descriptions, laying an healthy foundation.
IBMi would have been basically unbeatable as a core ERP business machine, to run and to dev upon.