You and i

« Strategy Updates in IBM i Development | Main | IBM i Information Strategy »



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 (

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


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.


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.

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:

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.


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

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.

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.

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.


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.



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.

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?


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.


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.

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.


The comments to this entry are closed.