The IBM AIX timeline. Below this timeline I am posting a slightly dated article because it is very well written and was a discussion point with one my customers recently.
Migration or Update?
The oslevel command helps plan updates
Once you know what AIX version you’re starting from, you can determine how to move to a new version.
Migration:
Moving to a new base level of AIX is always a migration. So, if you’re going from AIX 6.1 to AIX 7.1 or even from AIX 5.3 to AIX 7.1 (no need to do it in two stages), you’re migrating to a new release.
Update:
On the other hand, if you’re moving to a version within the same release, referred to as “patching,” it’s an update. That means it can be done using “smitty update_all,” even if it does require a reboot at the end of the update.
You may be updating to a later TL, or just to another Service Pack within the same TL. Installing a new TL is an “all or nothing” operation. If you’re downloading the updates yourself from the IBM Support Portal, you’ll need to know whether you’re going to a new TL or just updating to a later Service Pack on the same TL. The TL is a separate download and significantly larger than the SP.
Apply or Commit?
When you install updates, you commit them or simply apply them. When fileset updates are committed, the older versions are removed. When fileset updates are only applied, the previous version is saved. Applying them rather than committing them has this advantage: In the unlikely event that you want to roll back those new updates, you can reject them later without having to restore your OS from a backup. Once you’re sure you’re not going to back out the new filesets, you can commit them, which will save you some disk space.
TL updates can’t be rejected in the way Service Packs can so the recommendation is to commit them, rather than apply them.
Figure below shows some examples of the different upgrade paths, depending on the version of AIX you’re starting from.
If you find that “oslevel -s” reports that you’re on an older TL than you were before, it’s probably because new software has been installed at a lower level than the TL. If you encounter this oslevel regression, you need to determine which filesets are the culprits and install their updates as well. You can identify them by running “oslevel -s -l Level”. The level you enter has to be known to the OS, even if its updates haven’t been installed. Run “oslevel -qs” to see the known versions.
After installing a SP, the Reliable Scalable Cluster Technology (RSCT) filesets typically drag your oslevel backwards in this way. The teams that look after RSCT and CSM filesets match the AIX TL schedules, but not the SPs, so you’ll have to download the RSCT updates yourself.
It’s worthwhile getting familiar with the oslevel command syntax (see links). Understanding your AIX levels will help you stay up-to-date with important new features, which in turn will protect your systems by including fixes for critical problems
The original article is available here . Has been posted here through WordPress share.
You might want to read more about our CEO Sheshagiri Anegondi (Sheshu). He is amongst the foremost Oracle License Experts globally.