Many companies run their critical applications on an IBM i framework, all or some of which is still being hosted in their own data centers. When an update is released, or when a cloud migration is being planned, the question naturally arises: “What IBM i OS version are we running now?” This happens especially when the system is set up by one person or team, but another team “inherits” it.
Indeed, some businesses are cautious about upgrades, especially if their systems run smoothly. But even if things are running smoothly, there are good reasons to ensure that your IBM i OS is the latest version. You can keep track of the latest available version (and past versions) through IBM’s own wiki page on technology updates.
Checking your current version is the first step in any update or upgrade. But, as such updates and roll-outs get more and more complicated with every iteration of an operating system, there is a more clear-cut case for hiring a third party to manage them.
Why Keep Your OS Version Up-to-Date?
Most experts agree that keeping software up-to-date is crucial and that updating an OS is most crucial. Why? In a nutshell, the longer an OS has been around, the more its flaws become obvious. Updates fix these holes.
For example, updates commonly aim to:
- Repair security holes. The longer an OS has been around, the more opportunity there has been for hackers to figure out security holes. Operating system updates plug these holes.
- Address-known performance issues. Bugs are inevitable in any piece of software. And though manufacturers attempt to remove all bugs before the production release, users commonly find them, once deployed in a real-world environment. Updates commonly address those flaws.
- Add new features. On the flip side, an operating system might ship with a minimal number of features needed to be productive and stable. Other features get added in with later versions, once they have been proven to be stable, too.
- Hardware compatibility. Newer devices are always hitting the market, but older operating systems might not be designed to handle them. Again, updates can help ensure compatibility.
IBM i OS Version and PTFs
For IBM i, many updates come in packages known as PTFs, short for “Program Temporary Fix.” A PTF is a software patch for the operating system. This patch is called “temporary” because it is seen as a short-term “fix” for an IBM i operating system until the release of the next version. (Though note that many fixes are distributed as part of the core code in the subsequent version.)
IBM began to slow the pace of full OS upgrades (new releases) some years ago, and so many of the fixes and updates to systems running IBM i are now done via PTFs. That said, it is still vitally important to upgrade to the newest OS version when it becomes available.
How to Check Your IBM i OS Version
Which version of IBM i that a system is running can be checked through the IBM i Command Line.
GO LICPGM – One straightforward way to check the IBM i version is to use the GO LICPGM command. Choose option 10, and then press F11. This will display all installed licensed programs, including IBM i.
DSPSFWRSC – Some admins have reported that using GO LICPGM misreports licenses on some programs. Thus, many authors have advised using DSPSFWRSC instead. DSPSFWRSC displays all software resources installed, along with its software version. Simply type the command and then press F11. Nick Litten also has a nice script that uses the IBM API to return the IBM i version on a Power Series machine.
Upgrading IBM i
If you insist on doing an IBM i upgrade yourself (and your organization owns the hardware), there are some standard steps to take:
- Run a full back-up of your system/environment. This should include full images with data and architecture.
- Set up an image catalog. It will save time doing this instead of using a stack of DVDs (for instance).
- Verify the license keys. Make sure these are stored in an accessible place, just in case.
- Add any relevant PTFs. See above; some PTFs might need to be added before proceeding with an upgrade or migration.
- Upgrade the HMC (machine code) first, then upgrade the FSP firmware and the IBM i software itself and microcode.
- Verify the install. Be sure to use QSYSOPR for important messages.
- Run some keys programs to ensure their stability.
It is recommended that upgrades be rolled out in a staggered fashion; for example, start with one or two pilot machines, upgrade, and test. Work out any issues before rolling out to other machines.
The Hassle of Upgrading Systems Yourself
The steps in the last section can be a lot more involved than that simple list would intimate. If you have a dedicated IT team to carry out the upgrade, they should have the experience to do all of this seamlessly.
But teams do change, and oftentimes IT departments choose to commit fewer and fewer resources to more routine tasks (like upgrades). Add in the possibility of error and the shrinking talent pool when it comes to IBM i expertise, and it’s a recipe for delays, mistakes, and downtime.
We’ve often had clients approach our company with just these worries, asking things like:
- We think something went wrong with our most recent IBM i upgrade, can you help us roll it back?
- My admin’s about to retire and I’ll be short-staffed, can you help?
- We’re due for a hardware refresh, but our budget is limited, can our applications be migrated to the cloud?
If you are considering an upgrade (or migration), this is the ideal time to bring on a third party to manage the change. More often than not, you’ll save internal team resources while minimizing downtime and disruption.
Remote IBM i and AIX Administration and Monitoring
And while you’re at it, you might also consider fully remote IBM i administration and monitoring. With remote administration, a third party takes on full administration responsibility for your environment, including OS management, upgrades, and backup and restore processes. The result is better reliability, longer uptime, and better disaster recovery (DR).
Remote monitoring goes hand-in-hand with remote administration. With remote monitoring, key IBM i systems can stay on-premise while a third-party provider monitors the infrastructure, always on the alert for potential problems. This can be done securely, without sacrificing compliance or performance.
