“Why IBM i?” Architectural Foundations

I have recently had several opportunities to give a brief explanation of the architecture of IBM i -- to explain the key foundational elements and explain why these make IBM i significantly different from other operating systems. Today, I will share with you the notes I wrote for one of these sessions. When I present the “Why IBM i? A System Designed for Business” presentation, I often say I could talk for 30 minutes or more on one single chart -- the chart that lists these elements. I never get a chance to talk for that long, but here is the shorter version. I hope it helps you.

IBM i is very different from the other operating systems in the industry, and the differences are related to its unique architecture. From the birth of the AS/400, the goal of the operating system was to create a platform that would allow a business to be insulated from the complexity of IT technology. Our customers want to "run the business, not the computer." The five architectural elements below are not just marketing words -- they are built into millions of lines of operating system code -- and their purpose is to make IBM i stable, simple, secure and scalable.

DB2 for i & Single Level Store: We build intelligence and expertise into our handling of customer data. DB2 on IBM i is a part of the operating system, and it automates many functions that require human analysis and management on other operating systems. Single Level Store is a way of treating all storage attached to IBM i as if it is one huge set of memory. Working with DB2, our storage management spreads data across a customer's DASD in order to optimize data access. For these two reasons, customers rarely have to hire storage administrators or database administrators for their IBM i environments, and those professionals who are hired spend more time on analysis than on day-to-day management.

Object-Based Architecture: AS/400 was built understanding that security would be a key requirement of all businesses. Each object on IBM i has a set of well-defined functions, and it is architecturally impossible to treat an object in a way that violates its intended use. For example, two common methods of spreading viruses or “Trojan Horses” in other operating systems are to modify code in a compiled executable, or to rename an object so that a program looks like something that is not dangerous -- sending a program in an e-mail but making it appear to be a photo, for example. Neither of these two attacks can be done to software compiled as IBM i programs, because those operations are simply not allowed by the architecture.

Integration: We believe that the only software a typical customer really wants to deal with is the software that runs its business directly -- the applications that are developed by the customer or that they buy from our ISVs. For that reason, our operating system comes integrated with all of the necessary "middleware" a business application might need: Not only DB2, which I mentioned before, but also web servers, security services, user identity management and so on. These pieces of middleware must be added on top of other operating systems. We incorporate them into IBM i, and we ensure they fit into the architecture of the system, including the object-based architecture I mentioned, as well as the virtualization and TIMI I will describe next.

Work Management: The AS/400 was built assuming that a business would rather have one physical system that is capable of running all of the workloads it needs, rather than buying a new system for each workload. To support that idea, IBM i has a "subsystem" concept that allows an ERP application to sit next to a CRM application, which sits next to a web server and so on -- all of them sharing resources such as the database, but not colliding with one another. This is very different from typical competing operating systems, where it is architecturally difficult to run multiple workloads safely on one machine -- or one virtual machine -- and so the industry has had tremendous "sprawl" as customers of other platforms have had to buy a new system for each application or workload. Yes, today these other operating systems “solve” the problem their architectures created with virtualization. Subsystems are a virtualization technology that existed since the beginning of the operating system, and they allow an IBM i client to spend less on managing multiple environments.

Technology Independent Machine Interface: IBM i is split into two pieces, and the TIMI separates them. The TIMI also provides a layer of abstraction that does two important things. First, it allows programs that were compiled on older releases to run unchanged -- without even recompiling -- as IBM i changes technology beneath those applications. The operating system moved from a 48-bit CISC hardware architecture to today's Power architecture without the need for customers to recompile code. Second, the TIMI works together with some of the IBM i-specific capabilities built into POWER processors to keep system memory separate from user memory, protecting the operating system from intentional or unintentional interference. An interesting point though, is that all of the IBM i "device drivers" for I/O are beneath this TIMI. To protect the integrity of the operating system, and by extension the customer’s data, IBM i cannot have a "device driver" authored by another provider.

For those of you who made it to the end of this, thanks for reading. I suspect all of you now feel like you could develop the next extension to this extremely integrated operating system. No? Well, then perhaps you at least could explain some of its value to the next person who needs to hear it.

 

 

 

Twitter: #ibmi, @Steve_Will_IBMi

 

Comments

[Alan Seiden]

Steve, thank you--this came at the right time. Your concise summary of IBM i architecture will help me as I present a new talk next week in Cambridge, Mass., explaining IBM i to PHP developers (http://www.northeastphp.org/talks/view/77/IBM-i-fertile-ground-for-PHP-developers).

Those of us who are familiar with IBM i sometimes need to take a step back to appreciate it.

[Nathan Andelin]

Steve,

I'd like to highlight your paragraph about workload management.

Dan Burger, Executive Managing Editor of ITJUNGLE recently contacted me about one of my comments posted on Linkedin in which I indicated that we are in process of migrating two new customers from Windows based systems to an IBM i based cloud service, using a Web portal.

Dan asked if we were planning on hosting customers in separate partitions. I responded, no. We set up separate HTTP server instances, listening on separate ports. We run each customer's workloads in separate subsystems. We separate their data into separate libraries, and run their jobs under separate library lists.

Dan asked why we might do it that way, instead of using partitions. I shared an opinion that IBM i workload management had a few advantages over partitions in that IBM i could make resource allocation decisions based on things like job priorities and time slices, while a hypervisor wouldn't have that degree of control.

Dan suggested that a lot of people would not agree with my assessment. As I thought more about it, I don't remember the topic ever being discussed in public. But at least you point out a few similarities between IBM i workload management and partitions.

-Nathan

[Jean Mikhaleff]

Steve,
As you say, the IBM i is fully integrated for business applications.
However, I have read recently an article “Getting Started with EGL” From Dan Darnell who says “Lose the green screen –and the notion that RPG needs to drive the user interface-, and you still have a great server platform to use for the underpinnings of your applications.”
The problem is clear: for EGL people, the persistence is due to Green Screen applications. For the IBM i developers, the persistence is due to the nature of business applications. We have an ideological problem there.
Fortunately, we have a real example on hand of Back Office Business application. ATMs are part of back office business application automated, done in the past by bank clerk.
With that kind of back office application, the user has to follow step by step the transaction. You may have widgets and a lot of buttons around, the problem is not there: the user has to follow strictly the instructions written on the screen or quit. I think that 80% of business applications are natively persistent like ATMs. The programs must drive the transaction because the transaction is natively persistent and not because of green screen technology.
If ATMs were event driven, the users might lead the transactions. So, with that kind of event driven ATMs, the users might have cash without inserting any credit card.
For me it is obvious that for 80% of Back Office business applications, which are natively persistent, we need an integrated system. IBM i automatically manages multi-users, sharing programs and database dynamically which is a big hurdle when the developer has to manage this system part by himself.
Of course it is possible for a developer to manage multi-users and persistence using “some mechanism” but this is quite risky. To take a similar example, a scuba diver can swim like a fish, but to live all the time underwater it is better to be able to breathe water directly. This is the reason why we don’t have a lot of houses underwater.
As I know, the IBM i platform is the only one in the world natively thin client, able to manage natively multi-users, persistence, sharing programs with an integrated database.
That’s why I think that IBM should be the first company of the world because IBM has the right solution for 80% of business applications.
I think that the IBM i platform just needs native Web interfaces and a designer for both HTML5 but also graphical PDF reports.
However 20% of Front Office web applications must be event driven, which means driven by the users. For those applications we already have a lot of platforms and solutions, CGIDEV2 included. IBM i is unique. I quite agree with that.

[Nathan Andelin]

This comment is in response to Jean's. And more particularly to his statement "I think that the IBM i platform just needs native Web interfaces and a designer for both HTML5 but also graphical PDF reports."

One of my friends, David Shoaf, at Alpine School District (Utah) just gave a presentation at our monthly user group meeting in July that is recorded at the following link:

http://bit.ly/Otnfhc

He begins by declaring "I am an RPG programmer", then goes on to reminisce about his career, beginning in the 1970's, then moves on to express his travails with Web interfaces over a 12-13 year period. Finally, he shares his experience with the "Presto" product from BCD.

This is not meant to be a product endorsement. But it appears that Jean and my friend David Shoaf may share similar views and may even have a number of common (perhaps stereotypical) personality traits.

With respect to HTML, JavaScript, and the majority of Web interfaces, David states "a lot of that is beyond an RPG programmer".

I should warn in advance that the video presentation is 50 minutes long, and it may not apply to most audiences, but it appears that people like Jean may identify with David and take heart in his message.

Perhaps ironically, I just received a call a few minutes ago from a representative of the Asna Wings product, which is similar to BCD Presto. I can think of about 10 other vendors who offer similar web facing products, all targeted at the people who declare "I am an RPG programmer"; who may be equally reluctant to learn and use low-level web interfaces.

-Nathan

[Steve Will]

Alan - I'm glad I could help. Good luck on your session. Spread the good word!

[Steve Will]

Nathan - There is no single technology which satisfies all requirements for every situation. Partitioning does have its place -- certainly when multiple operating systems are involved.

Having said that, the virtualization provided by subsystems, together with the policy & controls we've created in our work management can be amazingly powerful when software and administrators use the security features of IBM i. Many solutions -- from the days of the AS/400 to today -- take full advantage of the ability to share the resources of the system WITHOUT partitioning. In fact, I have been thinking about writing a blog about how the IBM Lotus products are so competitive on IBM i for that very reason.

[Steve Will]

Jean, thanks for the comments. Lots of good things to think about. I like the analogy of scuba vs. being able to breathe water. Nice.

[Jean Mikhaleff]

Nathan,
For the presentation layer we have a DSPF and PRTF with column numbers and line numbers. It is obvious that we need instead a markup language to insert pictures in cells and have a proportional font for UI and .pdf reports.
I don’t agree with you when you say “a lot of that is beyond an RPG programmer”. For example my aunt is 65 years old, she knows nothing about HTML or JavaScript, but she is able to publish photos and videos only with the help of a web designer. Google says that there are two millions pages created or updated every day in the world by amateurs. The Web was successful because everyone is able to make HTML pages with designers, video included. I think that the graphical part for business application is much easier than my aunt, which is a real amateur, is able to do.
My aunt knows nothing about JavaScript and HTML and many RPG programmers know very few about DSPF syntax because both have a proper designer for the presentation layer.
I just say 80% of Back Office business applications like ATMs are persistent and must be program driven. 20% Front Office applications must be event driven.
The question is, for persistent applications, are “some mechanisms” better than:
-) DB2 for i &Single Level Store + Object-Based Architecture + Integration + Work Management + Technology Independent Machine Interface + RPG ?
If the answer is yes, EGL , which is multi-platform language, will replace soon RPG+IBM i with “some mechanisms” to manage persistence and multi-users. If the answer is no, IBM needs to improve the life cycle of IBM i to please its loyal customers. This is just one opinion among many others.

[Nathan Andelin]

Jean,

It was my friend David Shoaf who expressed the opinion that learning low-level web interfaces such as HTML and JavaScript was "beyond an RPG programmer". I was quoting him from the video.

For my part, I did learn HTML and JavaScript, in addition to RPG. I don't fit the mold.

However, I am confused now. One one hand you say that you disagree that learning HTML and JavaScript is beyond an RPG programmer. On the other hand, you suggest having a GUI designer to shield them from it.

I'm also perplexed about you continually raising concerns about GUI designers and "persistent" interfaces, when it appears that several reputable tools and frameworks already offer that.

I can think of a dozen vendors that offer tooling for RPG programmers that appear to address your concerns, including IBM. But you still keep raising them.

-Nathan

[Jean Mikhaleff]

Nathan,

I just read the new iProDeveloper August 2012 On Page 2 “From the Editor” Rita-Lyn Sanders begins her article with those words “I’m not a programmer; however, I have developed two static websites using HTML and SCC and written a statistical program in SAS to analyze data...” According to Google, there are two millions pages created or updated every day by people who are not developer.
Like Rita Lyn Sanders about her static websites, I want to make RPG business applications to be proud of, using directly an integrated web designer for the presentation layer.
IBM stands for International Business Machine and my own opinion is that IBM should focus on its core business.

[Greg Helton]

I think most people quickly lose interest in how the Technology Independent Machine Interface means code doesn't have to be recompiled when they find out that the code could only be RPG or COBOL. It is, as you say, a significant difference but it really isn't an advantage is it?

[David Andruchuk]

Steve,

Thanks for putting in print what most of us lifer IBM i community evangelists know but at times discount.

I have copied your blog link to share w/others I am currently architecting a project with to help them understand our platform and what it means to our businesses and how our visions of what we wish it to become has value beyond just lipstick on an old plow horse.

David

[Greg Helton]

The CLR is essentially the means with which .Net programs are provided the same hardware independence that the IBM i's Technology Independent Machine Interface provides COBOL and RPG programs. But the CLR provides an extra benefit. The C# and VB.NET compilers have migrated from C++ to managed code. The CLR runtime can utilize hardware dependent optimizations available on the different platforms it runs on and, in the future, when new chips provide new optimizations, the runtime will provide those to the program, again, without recompiling. Additionally, the CLR supports the Compiler as Service paradigm.

If I were trying to sell people on the IBM i, I'd tell them of the similarities between the IBM machine and its newer competition, for instance that Service Programs provide the same functionality as .Net assemblies.

[Steve Will]

Greg, thanks for your comments.

First -- the specific attribute I discussed of avoiding recompiling only affects code which has been compiled to create the intermediate code which IBM i can translate again -- and while there are compiled languages on IBM i in addition to RPG and COBOL, I do understand the point. Some languages are interpreted, so no "MI code" exists which is bound to programs written in those languages.

Second, I like your observation about CLR and the similarities between service programs and .Net. This brings up two interesting points.

1)The "Why IBM i?" presentation is generally created with a particular audience in mind, and I typically don't assume that audience has deep technical skills in .Net (or any specific architecture/language, in fact.) An altered version of the presentation could be created which specifically compares/contrasts. It might be worth investing some time in creating this. Hmmmm.

2) There are other very powerful attributes of the TIMI (or, the MI, if you prefer). I tend to talk first and most about the ability to carry forward code without change or recompiling, because that has been a key difference in the past AND has saved clients a great deal of time & money. However, I could certainly create some charts about other key values of the TIMI. Again, I'll have to consider when those might be most useful.

Thanks.