The IBM i OS Base Is Older Than We Think, But Moving Ahead

March 6, 2023

Timothy Prickett Morgan

Hardware upgrades are costly in terms of money and while it is always exiting to get a new system with that “new computer smell” – and you know what we are talking about – at least IBM i operating system and systems software upgrades don’t carry such a high price – provided you are on Software Maintenance and you do proper testing on your software before you make a jump to a new release.

The other great thing about IBM i systems software is that any given release not only runs on the current new Power Systems hardware at the time, but also on several prior generations of hardware, and older releases are updated to cover new hardware as it rolls out, too. Add in the Technology Refresh updates for the past several IBM i generations and it is considerably easier to stay current on IBM i software than it is on Power Systems hardware – and much less expensive, too.

The question is, how current are companies when it comes to their IBM i stack. We get some sense of that each January when the IBM i Marketplace Survey report comes out, which details the results of the survey that happened during the fall of the prior year. The survey, which is done by Fortra (formerly known as HelpSystems), has been in the field for nine years now and gives us a rich set of data from which to try to understand the IBM i base.

As we pointed out last week when we analyzed the Power Systems installed base among the IBM i faithful, we think that the data gathered by the survey reflects the state of the active part of the IBM i base, which we reckon is about 30,000 unique customers and does not indicate the vintage of hardware and systems software at the remaining 90,000 customers worldwide, what we call the laggards.

This active-laggard split is admittedly a hunch that we have, but it is that is informed by anecdotal evidence from customers and business partners who tell us far more vintage System/38, System/36, AS/400, iSeries, and System i iron has stayed in the field longer than any survey data ever shows. We think these laggard customers are stuck on vintage and unsupported software from third party vendors who may not even exist anymore or who charge too much money to upgrade applications to current releases. We think that active customers are the ones who tend to read publications like The Four Hundred, to go to COMMON and other user group meetings, and to take the time to do surveys. And we think that the Fortra survey, to be specific, is absolutely representative of what active customers are doing in terms of Power Systems and IBM i release levels.

We know that the laggards are quite a bit further back, although by how much is not clear. We reckon it is about four years or so behind the active part of the base, but following a similar path. Last week, we took the dataset of Power Systems distribution by Power CPU family from the nine Fortra reports and did a little witchcraft on it to figure out what the machine base at the remaining 90,000 sites might look like. This week, we are looking at the primary IBM i releases installed at sites.

The IBM i Marketplace Survey allows respondents to report on all Power Systems machines they have in their company, not just the primary machine’s type. But when it comes to the operating system, it asks for the primary one. This stands to reason, since if you have two machines (or three) in a high availability or disaster recovery configuration, you will probably be at the same hardware and software release. But some companies have separate machines for test and development and other uses, perhaps out in the field, and these can be at different hardware and software releases.

Here is what the raw data for primary IBM i operating system installed for the past five years:

In this raw data, we see that IBM i 7.5, which came out in May 2022, was cited by 2 percent of respondents, and we can see the rise of IBM i 7.4, which was cited by nearly half of respondents in the survey that ran last October. You will also note the decline of IBM i 7.3 after a pretty long run, and the decline of earlier releases as well.

We like to get an even longer view, and in more distinct colors and patterns that are easier to see, and so we put together this chart with all nine years of data:

We have estimated the distribution of earlier OS/400, i5/OS, and IBM i releases based on past data, when these were all called out separately. We think this is pretty representative of the OS distribution over time among the 30,000 active customers. As you can see, IBM i 7.5 is just starting out its climb.

But we do not think for a second that it is representative of what is going on at the laggards, and therefore for three-quarters of the installed base. We do not for one second believe that IBM i 7.4 is nearly half of the installed base and that IBM i 7.3 is nearly 40 percent of the base. No server operating system has 90 percent of its customers on the two current releases. Not Windows Server, not Linux. Not the IBM System z mainframe and its z/OS platform.

We created a model last year that showed that more than half of the base was actually on IBM i 7.1, which is consistent with the anecdotal evidence we get from customers and partners by time shifting those laggards to the distribution of operating systems that we saw on the IBM i Marketplace Survey four years ago. If you do that, you get a distribution of primary operating systems – including both actives and laggards added together – that looks like this:

Just for fun, we are going to let you see the model data that we generated for the 2022 and 2023 installed bases:

Here is what is interesting. The IBM i 7.4 base is growing very fast, and we think that this is customers moving up from IBM i 7.2 and in some cases IBM i 7.3. But funnily enough, the base of IBM i 7.2 is growing as customers upgrade from IBM i 6.1 and to a certain extent IBM i 7.1, and even though the IBM i 6.1 base is down, it is being propped up by those moving from i5/OS 5.4 and in some cases OS/400 V5R3. And IBM i 7.1, in our analysis, represents half of the IBM i base, not IBM i 7.4, and this has some important implications.

You can’t fault IBM for this, either. The company has done wonders with the Technology Refresh method of updating software functionality across three concurrently supported releases, and one of the side effects is that people are taking advantage of the seven years of support and can do so without sacrificing major functionality. That generosity is extending the effective life of IBM i releases. But the IBM i 7.1 base grew in the past 12 months – not by much, but by a few thousand customers. And if we are right, that is a big problem in the long run.

Last week, when talking about hardware, and in a bit of a haze because I was writing late at night, I said that IBM should worry less about what IBM i versions and releases it can support on PowerVM logical partitions on a particular Power10, Power9, and Power8 system and more about how it can use the Technology Independent Machine Interface, or TIMI, to make a Power10 processor look like a Power9, Power8, Power7+, or Power7 processor, and maybe older CPUs and their systems. Rather than trying to update everyone to more modern hardware and operating systems, why not convince older releases of OS/400, i5/OS, and IBM i that they are actually running on whatever hardware they expect? This would mostly mean hiding more modern features, not taking away old stuff.

So we ask again: Why can’t TIMI and microcode make any new Power processor look like any older Power processor? With such an approach, you could in fact move everyone to Power10 and just leave their software – operating system, database, systems stack, and applications – as they are. Why not?

RELATED STORIES

The Power Systems Base Is A Little Less Rusty (2023 Survey)

The IBM i Power10 Upgrade Cycle Forecast Looks Favorable (2023 Survey)

RPG Use “Skyrocketed” Says IBM i Marketplace Report (2023 Survey)

Cutting IT Costs Is Not A Priority, And That’s Good News (2023 Survey)

How Do You Stay In Touch With The IBM i Community? (2023 Survey)

Security Still Top Concern, IBM i Marketplace Study Says (2023 Survey)

The State Of The IBM Base 2022, Part Three: The Rusting Iron

The State Of The IBM i Base 2022, Part One: The Operating System

The State Of The IBM i Base 2022, Part Two: Upgrade Plans

The Real IBM i Legacy Is The People

IBM i Salaries: Underpaid, Yet Highly Valued And Hard To Replace

Marketplace Study Shows How IBM i Language Use Evolves

Security Again Top Concern in HelpSystems Marketplace Study

The Distinguished Professionals Of IBM i

Are You Experienced? IBM i Users Weigh In

Settling In With IBM i For The Long Haul

IBM i Has Been Getting With The Program For Years

The IBM i Base Did Indeed Move On Up

The IBM i Base Is Ready To Move On Up

Investment And Integration Indicators For IBM i

Security Still Dominates IBM i Discussion, HelpSystems’ 2018 Survey Reveals

The IBM i Base Not As Jumpy As It Has Been

The Feeds And Speeds Of The IBM i Base

IBM i Priorities For 2017: Pivot To Defense

IBM i Trends, Concerns, And Observations

IBM i Survey Gets Better As Numbers Grow

Where Do Those IBM i Machines Work?

If you’re on the very latest TR of #IBMi you can now use the IBM-supplied BINDING_DIRECTORY_INFO Table Function to get the same information as you can from the DSPBNDDIR CL command.

In my #SQLTools, I’ve had the BNDDIR_ENTRIES Table function that produces the identical information for several years. There is no API to access Binding Directory objects so my version uses the DSPBNDDIR OUTFILE support to accomplish this task.

As mentioned, the IBM-supplied BINDING_DIRECTORY_INFO is available on the latest TR of the operating system. If you are on V7R3 or later, see if you have it. If so, you don’t really need to continue reading this article, but feel free to continue.

BNDDIR_ENTRIES for #IBMi V7R2 and Later

In SQL Tools we ship the SQL User-Defined Table Function (UDTF) named BNDDIR_ENTRIES which was written to be compatible with IBMi V7R2 and later, with the exception of one line of code, which I’ll cover later in this article.

The syntax for this function follows:

SELECT * FROM TABLE( BNDDIR_ENTRIES( ‘QSYS2’, ‘QUSAPIBD’));

If you run this statement using IBM ACS or our SQL iQuery product, you will see the results for the QUSAPIBD. This binding directory is automatically included by RPG IV and C compilers. Years ago, working with IBM Rochester, we got all the entries from QC2LE included in QUSAPIBD which is why BNDDIR(‘QC2LE’) became unnecessary in RPG IV starting with IBM i V6R1.

The output from the above statement would look similar to the following.

If you’re an IBM i shop that takes advantage of Binding Directories, you probably need to know which binding directories contain certain Service Programs or Modules. the BNDDIR_ENTRIES Table Function will help with that.

Suppose you wanted to know which *SRVPGM and *MODULE objects are in the QC2LE as well as QUSAPIBD binding directores? A simple JOIN statement can be used to create this dataset:

SELECT c2.
  FROM TABLE (
         sqltools.BNDDIR_ENTRIES(‘QSYS’, ‘QC2LE’)
       ) C2
       INNER JOIN (
           SELECT *
             FROM TABLE (
                 sqltools.BNDDIR_ENTRIES(‘QSYS’, ‘QUSAPIBD’)
               ) API
         ) API
         ON (C2.OBJNAME, C2.OBJLIB) = (API.OBJNAME, API.OBJLIB)

The results from this SQL statement look like this:

Now you know which entries appear in both Binding Directories.

Binding Directories do not have an API themselves. So the only exposed way to get to those entries is via the DSPBNDDIR CL command. The BNDDIR object is a SPACE object, similar to a User Space object. Space objects are used for a variety of IBM i objects, such as *CMD, *USRSPC, and several others. For *BNDDIR objects the data is stored as fixed length segments within the space and repeats for each entry. In the old days, I would’ve written an MI program, but today I would choose the C language to get to the *BNDDIR Entries. However, today objects are locked down with System Domain and System State flags, so user code, even written in C, cannot resolve a pointer to those objects associated space. You would actually have to do a DMPSYSOBJ to a SPOOLED file, read that SPOOLED file data and extract the Entries.

The source code for the BNDDIR_ENTRIES Table function is shipped with our SQL Tools product. We include a source file named QUSRSRC (User Source) that contains functions that we deem less compelling and thus ship the source code for them.

Optional Statement

In order to perform the JOIN operation I illustrated, the BNDDIR_ENTRIES table function needs to connect one set of data with another. However, the DSPBNDDIR CL command output to a named output file. That OUTFILE can be a different name every time the command is run. Coming up with unique names can be challenging. To solve that problem SQL Tools ships with the TEMPNAME Function. This function returns a system-wide unique name. That name can be the name of a file in QTEMP or an IFS file name. To have it generate a name in QTEMP, pass in the name QTEMP as the first parameter, as follows:

DECLARE OUTFILE_NAME VARCHAR(21) NOT NULL DEFAULT ‘QTEMP/Z_BNDDIRE’;
set OUTFILE_NAME = sqlTools.tempname(‘QTEMP’);

Calling TEMPNAME() generates a name in QTEMP that is unique. This allows you to use this function in a JOIN operation as illustrate above. If you do NOT have SQL Tools, then this function does not exist on your system. If you want to use BNDDIR_ENTRIES anyway, simply comment out that one line of code that sets the OUTFILE_NAME variable. Also avoid using it in a JOIN operation with another BNDDIR_ENTRIES table function.

To learn more about any of our SQL Tools functions or obtain the source code for BNDDIR_ENTIES visit our website, download the latest SQL Tools V2R3 (announced 3 March 2023), and install them onto your IBM i system. You’ll receive a 2-month no-charge trial license automatically upon installation.

Visit: http://www.SQLiQuery.com/SQLTools for more details.

That’s all there is to it.