What is This “.1” Anyway?
By Steve Will
Greetings, IBM i fans. I know this blog post is a little later than you might have been expecting. In my defense, I’ve just returned from Japan and China, talking to customers and the iManifest group, and I’m only now recovering from the jet lag.
For today’s topic, I’ve selected a question I hear frequently, in one form or another. And, after the recent announcement of IBM i 6.1.1, it’s particularly appropriate. I’ll set it up with the question, excerpted and altered, I received via e-mail:
Steve,
We are currently testing our core applications on 6.1. There is a good chance we'll need to look at POWER7 and thus need 6.1.1 in the near future.
We already have many hours of QA time allocated for
testing of 6.1 and I would hate to do this again in a few months. I'm wondering
if we should consider just putting on 6.1.1. I need to be able to specify
exactly what is different in 6.1 and 6.1.1, so I know whether repeating tests
will be necessary.
Can you please explain to me?
If you haven’t read my “Layers of i” blog entry, I suggest you look at it, because explaining the difference between 6.1 and 6.1.1 is more easily understood with that information in your head.
The "point” releases, such as 6.1.1 and 5.4.5 before that, were created to give customers a way to avoid exactly the sort of duplicate QA recertification the e-mailer described. Let me explain things a couple of different ways.
First, these point releases only contain changes below the Technology Independent Machine Interface, not in the part of IBM i that contains the APIs used by customer applications. This means no application changes are even possible for the point release because none of the APIs or the code that implement them will change. If you think about it in layers: Your applications sit on a layer of APIs. That API layer is being left exactly as it is. With the point release, we’re rolling in a new layer below that API layer -- the Licensed Internal Code.
So why do we need the new layer, and why should you be able to test on 6.1 and be confident the testing is valid for 6.1.1? This leads to the second way of describing point releases.
A point release is intended to allow customer access to new hardware and virtualization capabilities, without changing the interfaces the customer uses for existing function. In the point release, we enable new storage devices, for example. We also get our microcode ready for new processors, so that the transition from one generation to the next is seamless. Finally, we’re providing new PowerVM virtualization functions, and our microcode must be aware of them to take advantage of them -- the October release of PowerVM supports redundant Virtual IOS partitions for example, and our microcode needs to be able to use that capability.
None of these new hardware, processor or virtualization capabilities cause changes to an application, and certainly none of them change any of the database functions. Similarly, they don't change the implementation of other IBM i functions such as data queues, security functions, the IFS and so on. Any changes to those functions come through PTFs, and these PTFs are not associated with 6.1.1 in particular -- they apply to both 6.1 and 6.1.1 equally since the code base they’re fixing is exactly the same.
Over the years, we’ve had many, many customers who wanted to be able to adopt new hardware -- for the processing capacity for instance -- but they don’t want to have to recertify their applications at the same time. This actually benefits IBM as well, because we typically get customers onto our newer hardware sooner because they don't have to coordinate hardware and software updates concurrently.
If your business is prepared to do your 6.1 testing now, there’s no reason to delay it for fear of changes associated with 6.1.1. It’s another way we use the power of the IBM i architecture to protect your investment in software, while delivering new valuable capabilities in non-disruptive ways.
By Craig Johnson
Recent Comments