[an error occurred while processing this directive]

AIX fix strategy From: leedp@austin.ibm.com (Dennis Lee, PMP Release Manager)

First, a little history...

The maintenance strategy for AIX 3.1 was cumulative updates. Every few
months, we'd put all available fixes in one large package and ship it.
There was no real strategy for providing a single fix. Although we'd
occasionally produce an emergency patch, there was no method for
tracking them; if you got a second one, it might overwrite the first.
So, after a few of these patches, it's hard to track.

In AIX 3.2 we introduced a "selective fix" strategy to support
individual fixes. The package contained information about other fixes
that were required for that fix to work correctly. For example, a Korn
shell fix might require a change in libc.a, which might in turn require
a fix in the kernel. This strategy allowed us to keep track of which
fixes were installed to make sure we didn't overwrite one with another,
and make sure they all worked together. But the initial selective fix
design still had a few problems.

o None of the fixes were cumulative. If you got a fix for Korn shell,
you may not receive all of the fixes for Korn shell. This left the
possibility of rediscovering other problems that were already fixed.

o Since we chose to fix everything possible that was reported as a
problem, instead of deferring them to the next release, the number
of available fixes became quite large.

o The number of additional fixes required by any given fix could also
be quite large. Since the installation program ran once for each
fix, the size and complexity of the fix packages grew, and
installation time lengthens greatly.

While developing the AIX 3.2.4 upgrade, we undertook a large effort to
resolve the selective fix concerns, and dramatically increase the
quality of AIX 3.2. The base operating system and most of the optional
program products were split into subsystems. A subsystem is a group of
logically related files. The division was made such that changes to a
given subsystem were less likely to affect other subsystems. In total
there are approximately 500 subsystems, but in practice, files have been
modified in only about half of them. The advantages of the new
packaging strategy are:

o Each subsystem package is cumulative, containing all of the fixes
and enhancements to date for that subsystem.

o The cumulative subsystem package is tested as an entity.

o The number of fix packages is greatly reduced because the number of
subsystems is far fewer than the number of fixes and enhancements.

o The number of other fixes required by any given fix is also greatly
reduced because a subsystem package has requisites only on other
subsystem packages.

o The reduced number of fix packages greatly reduced installation time.

Some customers also told us that they liked the maintenance level
strategy that we used in AIX 3.1. They liked being able to install all
of the known fixes, and they liked knowing what "level" of AIX they had.
To meet these requirements, we produced a Preventive Maintenance Package
(PMP). The PMP is simply a collection of the latest cumulative
subsystem packages tied together in such a way that it can be installed
by selecting a single fix. We also added flags to the lslpp command and
added a new command, oslevel, to show which PMP is installed. Now we
had both! The good attributes of selective fix along with the good
attributes of maintenance levels.

A few Q&As:

Q. Why is the fix I just received 130 megabytes!@#? I already have the
AIX 3.2.4 update installed!
A. Your fix may be part of the AIX 3.2.5 update. AIX 3.2.5 is another
PMP that contains all of the fixes to date, as well as enhancements
to support the PowerPC model 250, and the new high-end RS/2 models
590 and 990, as well as support for new disk and tape drives, graphics
adapters and more.

Q. Why can't you just build my fix on 3.2.4?
A. There really isn't such a thing as 3.2.1 or 3.2.2 or even 3.2.4.
They're just collections of fixes and enhancements built on a 3.2 base.
If the fix for your problem was built prior to 3.2.5, you can get the
older version. But if your fix was built for the first time in a 3.2.5
subsystem, that's the only version of the fix that exists.

See also 6.02.

[an error occurred while processing this directive]