GG24-4161-00 International Technical Support Organization
Austin Center

AIX V3.2 Product Packaging and Selective Fix Enhancements

This chapter discusses the following two aspects of the AIX V3.2 operating system:

Historical Perspective of AIX V3 Packaging

&aix31
The AIX V3.1 Base Operating System (bos) was getting updated approximately once every two months. The bos update levels were identified as 3003, 3005, 2008, 2010 and so on. These updates contained every fix available for the release, intermingled with product enhancements. When the updates were applied, all of the fixes or enhancements for a software product were applied at the same time. The user was unable to select only the fixes for a particular problem.

For a particular problem, sometimes the customer will apply an emergency fix. It was not possible in AIX V3.1 to keep track of such emergency fixes.

The size of AIX V3.1 updates became very large, taking about 30 to 40MB of disk space. This update process was costing the customers considerable time and disk space.

AIX V3.2
In AIX V3.2, the method of packaging and distributing updates was significantly changed. The packaging strategy supplied a fix for one customer reported problem in one update package. Occasionally an update package fixed more than one problem when the problems or fixes were closely related. 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 to keep track of which fixes were installed to make sure the system didn't overwrite one with another, and make sure they all worked together. This packaging scheme resulted in the following advantages to the customer:
Need for AIX V3.2.4 or Greater

The packaging scheme introduced in AIX V3.2 had the following disadvantages:

AIX V3.2.4 addresses all these problems and provides a suitable solution to circumvent all of them. AIX 3.2.5 maintenance level is the latest level at this moment, and it addresses all the above problems also.

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 practise, files have been modified in only about half of them. The advantages of the new packaging strategy are:

Maintenance Level

Beginning in the second quarter of 1993, a maintenance level is being provided for each LPP, including the base operating system (bos). If the LPP has a data portion, there is a separate maintenance level for it. See the AIX Installation Guide for a listing of LPPs, options and subsystems.

A maintenance level is a cumulative update package. Each installable product option has its own maintenance level. The base operating system (bos) has a separate maintenance level. Every other product has its own maintenance level. For example, bosnet has a maintenance level for each of its installable options: ncs, nfs, snmpd and tcpip. If we install bosnet without ncs, we will only get maintenance levels for the other options.

A maintenance level is a collection of all updates for a licensed program product (LPP) since the last version. For AIX 3.2.5, each maintenance level will contain all of the updates (both fixes and enhancements) since AIX V3.2 was released.

Maintenance levels can be applied to only one LPP or to all LPPs, depending on the customer's needs. The LPPs can be individually selected from the menus.

Preventive Maintenance Package (PMP)

A Preventive Maintenance Package (PMP) is a cumulative update package. It contains all selective fixes and their prerequisites for a set of software products.

The update package will contain all known updates (both fixes and enhancements) available for each subsystem at the time it is built.

The difference between the AIX V3.2.4 update package or the AIX 3.2.5 update package and the previous AIX V3.2 update packages is that there are no prerequisites for individual fixes. Each update package contains code to fix all the known problems and add all the known enhancements. Each update package will supersede any earlier update packages. A file will be replaced once, instead of many times.

For example, suppose after the AIX 3.2.5 maintenance level for the logical volume manager (LVM) subsystem is released, the mklv command is found to have an error. A selective fix is issued which includes a corrected copy of the mklv command. This fix will have the AIX 3.2.5 maintenance level of the LVM subsystem as a prerequisite.

Now suppose the mkvg command is found to be in error. A new selective fix is created which supersedes the previous one. This new selective fix will contain both the mklv and mkvg files, and will fix all the problems corrected since the AIX 3.2.5 maintenance level of LVM subsystem. The prerequisite is AIX 3.2.5 maintenance level of LVM subsystem. The earlier selective fixes for correcting the previous problems on the command mklv will not be a prerequisite. All changes to a subsystem are cumulative after the AIX 3.2.5 maintenance level.

This means that the AIX V3.2.4 or AIX 3.2.5 updates can be applied in much less time than it took for earlier releases of AIX V3.2. Additionally, applying the entire AIX 3.2.5 preventive maintenance package (PMP) to a system will bring the system up to the AIX 3.2.5 level. This makes it easier for a customer to identify the level of their system.

In the future, updates will still be available to customers as soon as they are identified and corrected. However, when an update is sent out for a particular subsystem, it will also contain all previous corrections. It will no longer be possible for a customer to apply only the incremental code associated with a particular problem.

The highlights of AIX PMPs which are also called AIX PMP 3240 and 3250 are as follows:

Let's try a reality check. Here are a few examples.

Prior to the subsystem packaging changes in AIX 3.2.4, it wasn't altogether uncommon for a selective fix (with its requisite fixes) to be 100MB and more of individual packages. Installation times vary for many reasons, but it was also not uncommon to experience installation times of 16 hours. This was due in part to the number of fixes, but also due to inefficiencies in the installation process. The same files might be included in several fix packages, therefore replaced several times, and the boot image might be rebuilt multiple times.

The same fix, after the subsystem packaging changes in AIX 3.2.4, wouldn't necessarily be a great deal smaller, since it would have the same requisites, but would likely install in nearly 1/4 of the time. The reason is simple. If you take 2000 changes and package them into 2000 packages, each of which is separately installed, it takes a great deal longer than if you take the same 2000 changes and package them into 250 packages. And, if you then make a few changes to optimize the installation process like making sure that the boot image is rebuilt only once, the installation pain is greatly reduced.

Now let's assume that you've already installed the latest PMP, and you need another fix. That fix is still likely to have requisites on other fixes, but you have a large portion of them already installed. First, the requisites that are already installed don't have to be included on your installation tape. Since reading tape takes time, the less tape you have to read the better. Also, there are quite likely entire subsystems that are either not touched by your fix, or have not changed since the PMP, so the number of fix packages will be fewer. The result is that fixes between PMPs are likely to be much smaller.

This sounds great, but why is the fix you've just received 130MB? You already have the AIX 3.2.4 update installed! You thought it was going to be all better now? The answer is likely to be that your fix was 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 AIX to support the PowerPC model 250, and the new high-end PS/2 models 590 and 990, as well as support for new disk and tape drives, graphics adapters and more neat stuff. Why can't we just build your fix on 3.2.4? The answer is that there really isn't such a thing as 3.2.1 or 3.2.2 or even 3.2.4. They're all nothing more than collections of fixes and enhancements built on an AIX 3.2 base. If the fix for your problem was built prior to the AIX 3.2.5 subsystems, 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.

AIX 3.2.5 Packaging Information

There are different ways a customer may receive service update packages:
Preventive Maintenance Package 3250 (PMP)

This contains the AIX 3.2.5 maintenance level update for your system. It may also be called a put tape, PMP 3250, or a cumulative update tape. This tape is non-bootable.

This includes all available subsystem selective fixes. It is composed of real PTFs, enhancement packaging PTFs and maintenance level packaging PTFs. This media can only be used to apply fixes to systems at AIX V3.2 or higher. This package also includes the third SNA refresh PTF as well as the latest PTFs for XLC, XLF, C++**, CICS* and ESCON*. This PMP will not contain installation images. It is expressly intended to be used to cumulatively update a system. It is not usable to move from one version of an LPP to a higher version. It contains only update images (PTFs). If a customer wants to move from AIXwindows 1.2 to AIXwindows 1.2.3, this package will not do it for him. Customer will need to use an installation or MES tape. It does not contain newly revised InfoExplorer database files. These files are provided as installation images only. Customer will need to use an installation or MES tape.

This package is not automatically shipped to customers. Customers will need to contact their defect Support Center to order this package.

MES Package or AIX 3.2.5 Release Update Tape Package

The Miscellaneous Equipment Specification (MES) package contains the PMP 3250 plus entitled software product installation images ordered by the customer. This tape is non-bootable. The updates and new installation images (software products) will be shipped on the same installation media. This MES tape will contain everything on the PMP plus all the installation images that are not a part of AIX V3.2 GOLD (for example X11R5**). This media is expressly intended to be used to move from one version of an LPP to a higher version. If a customer wants to move from AIXwindows 1.2 to AIXwindows 1.2.3, this package will do it for him. It can be used to cumulatively update a system to PMP 3250.

This is a product package, not a service package. The IBM Support Center cannot order this package for the customer.

AIX 3.2.5 Installation Tape

The installation tape can be ordered using procedures similar to the MES tape. This media contains everything that a MES tape contains plus all the AIX V3.2 GOLD images. This tape is bootable. This media can be used to install AIX onto new systems. It is composed of entitled (paid for) software product installation images and the PMP 3250 package. It is used to install a new system or to upgrade from AIX V3.1 or AIX V3.2 to AIX 3.2.5. Customers should order this tape instead of the MES tape, if migrating from AIX V3.1 to AIX 3.2.5. It is expressely intended to be used to move from one version of an LPP to a higher version. If a customer wants to move from AIXwindows 1.2 to AIXwindows 1.2.3, this package will do it for him. It can be used to cumulatively update a system to PMP 3250.

This is a product package, not a service package. The Support Center cannot order this package for the customer.

Subsystem Package or Selective Fix Package

This contains one or more subsystem selective fixes. This tape is non-bootable. A subsystem (selective fix) package is shipped to the customers who report specific problems to IBM Support Centers. These problems are corrected by the fixes which are packaged in the subsystem (selective fix) package. A subsystem package will replace only the files which have changed since AIX V3.2.0. These tapes are normally made out and sent by IBM Support Centers handling the customer's problems. There are two ways of delivering these packages: a package that will install onto any AIX V3.2 system, or a package that will install only on AIX 3.2.5 systems. In this case, the Support Center will need to specify in the order that the PMP 3250 package is already installed.

installp Overview, Terminology and Background

The command installp installs available software products from the media. The same command is also used to apply, commit or reject fixes from the media.

The installation/update process performs four major actions upon program products. They are:

Apply
When a given version of a product is applied, it is installed and the previously active version of the product is saved in a special save directory. The user may later choose to go back to that earlier version of the software. Once a version has been applied, it becomes the currently active version of the software.

The locations for saved files for AIX V3.2 installation are:

The location for saved files for AIX V3.2 update is:

where <ptf_no> is the fix ID (PTF number).
Commit
When a given version of a product is committed, the files of the previously active versions of the product (that were saved during the apply) are deleted. After the commit, it is impossible to return to a previous version without reinstalling the product. A user may commit any previous version of the product that has been applied but not committed. It is not necessary to commit the currently active version, for proper working of that fix.
Reject
When a user rejects a certain version of a software product or an update, the files of the previously active version of the product (that were saved during the apply) are copied back to the system and become the currently active version. Files saved when the rejected version was first applied, and any versions of the product applied after it, are deleted. After the reject, it is impossible to return to the rejected version without reinstalling that version of the product again.
Cleanup
If a previously failed installation or update leaves any software in a state of either applying or committing, it is necessary to perform cleanup (the command installp -C) before any further installations will be allowed. An attempt is made to clean up any incomplete installations by removing those parts that were previously completed. An attempt is also made to return to the previous version of the software product, if one exists, as the currently active version. If this cannot be done, the software product is marked as broken, and unpredictable results can occur if the user attempts to use it. Therefore, it is advisable for the user to reinstall any broken software products or apply/commit any broken updates.

Note that the apply and reject actions can change the version of the product that is currently active. The commit action does not change the currently active version of the product.

Example of Commit and Reject of Updates

To understand the effect of the commit and reject operations let us assume that a product has the following state, as shown below: Updates State update 5 applied update 4 applied update 3 applied update 2 applied update 1 applied new install applied




In this example update 5 is the currently running version of the software. If the user commits update 2, the code saved to allow the user to reject update 1 or update 2 will be removed. Update 3 and above will continue to be in applied state and may be rejected at a later time.

The state now looks like: Updates State update 5 applied update 4 applied update 3 applied update 2 committed update 1 committed new install committed




If the user now rejects update 4, update 5 will also be rejected if:

Files saved for the rejected update and any updates that were applied after it are removed from the system. The state now looks like: Updates State update 3 applied update 2 committed update 1 committed new install committed


Update 3 is now the running version of the code.

See Software States and Events in installp Summary for more details on the installp summary and lslpp command software states.

Terminology Used in AIX V3.2 Installation Process

This section introduces the terminology which is used by IBM in describing the AIX update and installation processes.

LPP - Licensed Program Product

An LPP may also be called an Optional Program Product (OPP), a software package or a software product. An LPP is a purchasable product (like bos, X11, sna, hcon, and others). An LPP can either be a collection of options or a single option.

OPP - Optional Program Product

The term OPP sometimes refers to the installable options of an LPP.

Install image

This is new code for either a new LPP or a new version of an existing LPP. It is placed on a machine for the first time using the installation process.

Option
An option is a collection of subsystems that are built together to form one installable image. Examples of options are bosext1.mh, bosnet.ncs, bosext2.acct, hcon, and others. Note that an option can be only one subsystem or multiple subsystems combined together.
Subsystem
A subsystem is a functionally related group of software components that are part of the same optional software product. Examples of subsystems are LVM, Kernel, TTY, Printer, or HFT Configuration Utilities.

Basically, every file in AIX and its LPPs belongs to one and only one subsystem. For instance, the commands mklv and mkvg belong to the LVM subsystem.

Cumulative Subsystem

This contains all the fixes since AIX V3.2.0.

APAR - Authorized Program Analysis Report

An APAR is opened when a reported customer problem is found to be a defect with the IBM software. An APAR contains information about the problem description, brief customer details, and the status of the APAR. When a solution is made available, the PTF number is recorded in the APAR.

Requisites
A requisite can have one of the following relationships to a specific update or installation image:
Update
An update may also be called a program temporary fix (PTF) or a program update. The number assigned to the update is called the PTF number or the fix ID. An update either corrects a defect in, or adds an enhancement to the Base Operating System (bos) or an optional software product. It is temporary in the sense that when the next release is issued, this correction will be contained in it and it will no longer be necessary to apply the correction.

PTF numbers beginning with U49 are AIX maintenance level PTFs. The remaining 4 numbers in U493240 (3240) implies the AIX 3.2.4 maintenance level PTF. The remaining 4 numbers in U493250 (3250) implies the AIX 3.2.5 maintenance level PTF.

Supersede
The update 2 is said to supersede update 1 if it contains all the corrections that were contained in update 1.

After installing AIX 3.2.5 on the system, the customer will receive subsystem fixes for problems they have. These subsystem fixes will not be cumulative fixes. They will have the cumulative subsystems from the maintenance level as their prerequisites. This allows for smaller fixes to be sent, and decreases installation time. Each subsystem that is fixed will supersede its previous subsystem, so you will always get the latest fixes for that subsystem.

Selective Enhancement

An enhancement can be a new module or an update to an existing module. It provides new function for an existing product, or new function to support a new device or a new application. It is a change required to make a new device or a new function work. An enhancement might have a fix as a prerequisite. For example, many hardware releases require changes to the operating system or may need new device drivers, configuration methods, or predefined attributes. It may be necessary to apply these changes before the new functions are added.

A selective enhancement is most often a packaging update, since it combines enhancements to several subsystems (see packaging below) into one update.

Selective Fix

A selective fix may also be called a PTF or a subsystem fix. A fix is an update to a module that is a part of a previously released product. This update corrects a problem with the module. It updates some number of files which are members of a subsystem.

Packaging
A packaging update is used to group a related set of updates together to ensure correct installation. This update will contain no code; it will only contain prerequisite information. This is a way to group updates together so they can be installed by selecting just one item from the menu.

New Enhancements Since AIX V3.2.4

This section describes some of the new commands and enhancements to the existing commands since AIX V3.2.4 maintenance level. These commands are also part of the AIX 3.2.5 maintenance level.

Changes in the Command lslpp

Two new flags have been added to the lslpp command to help determine the level of the software on a system.

  1. # lslpp -L This command will display the maintenance level of the products plus any updates applied since the maintenance level was applied. For example use the command, lslpp -L bos.obj for the operating system.
  2. # lslpp -La This command generates output which includes all PTFs that have been superseded.
  3. # lslpp -m This command lists the latest maintenance level of products. To list the latest level of the operating system, use the command lslpp -m bos.obj. This command may take up to 30 seconds to complete.
The lslpp command cannot be used to identify the following:

Use the command lslpp -al to display the full name, state and description of all the software products. The command lslpp -h displays the installation and update history information for all the software products.

Command oslevel

Because only some products have maintenance levels, there was a need for a single word command that will display the system level. The command oslevel is a korn shell script in the file /usr/bin/oslevel. It parses the output of lslpp -L. Then it compares the maintenance levels of the products that are applied on the system to a list of all products that can have maintenance levels. It determines if you have all the maintenance levels you need and if you are really at AIX 3.2.4 or AIX 3.2.5. The command syntax and the available flags are given in the following diagram:


# oslevel [ -l | -g [-s] | -e ] [-i]

The description of the flags are:
-l List products at levels earlier than maintenance level
-g List products at levels later than maintenance level
-e List products at current maintenance level
-s List subsystem level information - valid with -g
-i Include products only updated by installation images

Running the command oslevel without any flag, should display that the system software is at levels equal to, below, above, or at mixed levels relative to the current maintenance level. Corresponding output for those cases would be =3250, <3250, >3250, or <>3250 for the 3250 maintenance level. The additional options may be specified to determine which products and subsystems differ from the maintenance level.

Use of the -i (installation images) option lists only products that do not have a maintenance level, but are updated by a new installation images. Corresponding output for those cases would be =3.2.5, <3.2.5, >3.2.5 or <>3.2.5 for the 3.2.5 product level.

The need for a separate oslevel command is as follows. Let us assume that your system had U493250 applied. Then you applied products that have different maintenance levels, so your system is not really at AIX 3.2.5. However, lslpp -m would still indicate that the system is at the 3250 AIX maintenance level. This is a problem with installp that is being worked on, when this document was being prepared.

To explain further, let us assume that you had three products installed on the system, and each of these products had a maintenance level. You install U493250, which has the ifrequisites on each of these three products. It installs the maintenance level for each one, all its requisites are met, and it says it is applied. Later, you install product A, but do not install its maintenance level. The command smit install_latest will install the product and all the latest fixes, which is the best menu for installing new products. Now, the system is really not at the AIX 3.2.5 maintenance level anymore, but lspp -m will still say that U493250 is applied. The command oslevel will know that the system has this new product and it has a maintenance level that is not applied. So it will report <>3250 because you have some products at their maintenance levels and some that are not.

Utility update_all

There are many things to be considered while updating to AIX 3.2.5. For example, /tmp file system should have 8MB of free space or the command bosboot verify will fail. A script was written to help the customers to update the system to AIX 3.2.4 or AIX 3.2.5.

This utility is part of the U422463 PTF. To install update_all program, use the command:

# installp -acXBNg -d /dev/rmt0.1 bos.obj 3.2.0.0.U422463 2>&1 | \
tee /tmp/update_all.log
Note: In the above command rmt0 is the tape drive with the installation media. Use the appropriate device name as per your configuration. In the above command | is the pipe and \ is the backslash characters. The log file /tmp/update_all.log may be examined for the successful installation of this PTF. Once installed update_all should be called without options. However, there are some options provided for special needs such as diskless server or file systems server. If you plan to use the system as a diskless server or /usr server in the future, run update_all -s thus the files which are necessary to support this will not be deleted. If your system is already a diskless or /usr server, these files will be retained automatically.

The following screen contains the command used to display all the flag options and their usage:


# update_all -?
usage: update_all [-iqbsz] [-d device]
-i Don't install new Maintenance Level Update Utilities.
-q Quiet mode (don't ask any questions).
-b Don't display the welcome banner.
-s This machine may be used as a diskless or remote /usr server.
-z Don't do any cleanup (increase MAX LPs,
rm files in /tmp, etc...)

Figure: Flags for the Command update_all

To use this command, run update_all -d /dev/rmt0.1. If you run the command update_all it will do the following tasks:

The command then procedes with the following activities:

The command ensures that there is enough working space as follows:

Following is a summary of the procedure to be followed for installing the complete maintenance level using the command update_all:

  1. Login as root user.
  2. Have all the other users log off. The command will check to ensure that only the root user is logged on the system.
  3. Stop all your applications and database engines, if any.
  4. Make sure there is 44MB of space in /usr or available partitions to be extended. Also check /var space and paging space, and run chlv -x 512 hd2 command.
  5. Load the tape containing the maintenance level into the tape drive.
  6. Enter the following command:
    # update_all -d<device>
    
    where <device> is the device containing the maintenance level image, in this example rmt0.1.

    Note: If this machine may be used as a diskless or remote /usr/server, use the -s option.

After you answer the prompts, this procedure will automatically update your system to the latest maintenance level and reboot the system. If the system is used as a diskless or /usr server, it will not be rebooted automatically.

This command cannot be used to upgrade a machine from AIX V3.1.

Utility ptfdir_clean

The ptfdir_clean script was written to clean up scripts, files and directories that are left on a machine for diskless clients and remote /usr clients. If the machine is not and will never be a diskless client or remote /usr server, this script should be run before and after installing any PTFs (especially AIX 3.2.5 or AIX V3.2.4).

The utility ptfdir_clean -y will first confirm that the machine is not a server, then it will search for all the committed PTFs on the system and remove the associated /usr/lpp/*/inst_<ptf_no> directories and files. It will also remove inst_root directories and files.

It will report the amount of file system space recovered, and the amount that could be recovered if all PTFs and products were committed on the system. This script is especially useful for customers with limited disk space (for example systems with 400MB drives).

This script will be shipped with the installation subsystem.

Automatic Apply/Commit of Maintenance Levels

When all of an LPP's maintenance level prerequisites are met (all the subsystem maintenance levels are installed), then the LPP maintenance level will be applied. Similarly for commit, when all the LPP prereqs are committed, then the LPP maintenance level will be committed.

When an applied LPP maintenance level is rejected, the subsystem maintenance levels will remain applied. If you want to reject an entire maintenance level, you will need to reject each subsystem, one by one.

Changes in bosboot Processing

In AIX V3.2, during PTF installations, the command bosboot was run many times. This took time and was prone to failure. Since AIX V3.2.4, individual calls to bosboot from each PTF was taken out. There is only one bosboot at the end.

installp looks at what it will install and if any of the PTFs require a bosboot, it sets a flag. Before it installs any PTFs, it runs the command bosboot -v which checks to see if you have enough space in /tmp, /var, and others to make a boot image. If any error is returned, the installation is cancelled so that the user can cleanup /tmp or fix whatever problem has occurred.

The file system /tmp will not be expanded, even if you give the -X flag which says to automatically expand file systems, since /tmp is a temporary file system, installp should not expand it. It should allow the user to either cleanup files there, or extend it themselves.

If the bosboot verify is successful, the PTFs will be installed. Then a bosboot will take place at the end. If this bosboot is unsuccessful for any reason, a flag will be set to indicate that a bosboot is pending in installp. No PTFs will be marked as broken because everything installed OK, but the bosboot failed. The user should correct whatever the problem is with bosboot and then run installp -C, which will see that the bosboot is pending and run bosboot to rebuild the boot image, and clear the bit. No installs will be allowed until installp can run a successful bosboot.

Command ifreqs

To specify that the fix in one product needs another fix in another product, ifreqs is used. If you are installing the bos.obj fix <ptf_no_a> and you have bosnet.tcpip installed, you should also install fix <ptf_no_x>. The expression below states that the PTF <ptf_no_a> in bos.obj has an ifreq on <ptf_no_x> in bosnet.tcpip product.
bos.obj 3.2.0.0.<ptf_no_a>-- ifreqs -- bosnet.tcpip.obj 3.2.0.0.<ptf_no_x>
The PTF <ptf_no_x> will not be applied, if the system does not have bosnet installed. Then later, you decide to install the bosnet.tcpip.obj product, it will be missing an ifreq.

The need for the utility ifreqs is illustrated below. Let us assume that a fix for product A changes the behavior of a subroutine in product B, which is an ifreq. When that fix was applied product B was not there, so the ifreq fix for product B did not go on. Now, when the product B is put later on it is using an older code without the fix, which could cause problems.

When you have installed AIX 3.2.4 or AIX 3.2.5, there should not be any outstanding ifreqs. If you install any products after you have installed the AIX maintenance level, it is a good idea to run ifreqs after the installation.

The utility ifreqs is a korn shell script in the file /usr/sbin/ifreqs.

Changes in Command installp

A new flag has been added to the installp command to permit files to be saved in a different location than the default directory. Previously, when PTFs were installed the replaced files were always saved in a directory under /usr. When the PTFs are committed, these saved files are deleted and free space is available in /usr file system. This free space cannot be used by the user, since /usr is a special directory containing products. Also it is not possible to reduce the file system /usr, without reinstalling the system.

The -t flag specifies an alternative location for a save directory that holds files being replaced by an update. This option is primarily useful in the following two circumstances:

The advantage of saving the files is that if there is any problem with any PTF, it can be rejected later. Otherwise the PTF will be marked as broken.

The installp -l command lists all the software products and updates on the specified installation media. Three new types (R, E and C) have been added to the report. Type indicates the type of update packaging. An update may belong to an installation package or to one of the following types of update packages as per the following table: Type Description S Single update G Single update that is highly recommended R Required update, goes on automatically M Maintenance package I Installation package E Enhancement package C Cumulative update package F First (installp fix), goes on automatically




If a user issues installp with both the -B (only select update packages) flag and the -g (automatically install any software products or updates that are requisites of the specified software product) flag, the -B flag will take precedence and only updates for products on the system will be applied.

Software States and Events in installp Summary

The installp command produces a summary report at the end. Following is an example of such a summary:


Installp Summary
----------------
Name Fix Id Part Event Result State
-------------------------------------------------------------------------------
bos.obj U491150 USR APPLY SUCCESS APPLIED
bos.obj U493250 USR APPLY SUCCESS APPLIED
bsmEn_US.msg USR COMMIT SUCCESS COMMITTED
bsl.en_US.aix.loc USR COMMIT SUCCESS COMMITTED
bsl.en_US.pc.loc USR COMMIT SUCCESS COMMITTED
bsl.en_US.pc.loc U418397 USR COMMIT SUCCESS COMMITTED
bsl.en_US.aix.loc U418396 USR COMMIT SUCCESS COMMITTED
bsmEn_US.msg U422576 USR COMMIT SUCCESS COMMITTED
bsmEn_US.msg U422577 USR COMMIT SUCCESS COMMITTED
bsl.en_US.aix.loc U491131 USR COMMIT SUCCESS COMMITTED
bsl.en_US.pc.loc U491131 USR COMMIT SUCCESS COMMITTED
bsmEn_US.msg U491133 USR COMMIT SUCCESS COMMITTED
bos.obj U491150 USR COMMIT SUCCESS COMMITTED
bos.obj U493250 USR COMMIT SUCCESS COMMITTED

---- end ----

The following table lists the possible installation events, event results and software states for that summary:
Table: installp Summary Installation Events, Results and States

The results of the installp summary are described below:

Success
The specified action succeeded.
Failed
The specified action failed.
Cancelled
Passed preinstallation checking, but was cancelled by the user (usually with a Ctrl-c) or the system (usually because an installp fix was applied).

The software states in installp are described below:

Applied
The specified option is applied.
Committed
The specified option is committed.
Available
The specified option does not exist on the system, but is known to be available on some media.
Broken
The specified option is broken and should be reinstalled before being used.
Applying
An attempt was made to apply the specified option, but it did not complete successfully, and cleanup was not completed.
Committing
An attempt was made to commit the specified option, but it did not complete successfully, and cleanup was not completed.
Rejecting
An attempt was made to reject the specified option, but it did not complete successfully, and cleanup was not completed.

New SMIT Installation Menus

The SMIT installation and update menus are now rearranged in a more logical order and are revised to reflect the new packaging. See Figure - Old Installation Menu Tree until AIX 3.2.3 and Figure - New Installation Menu Tree since AIX 3.2.4 for a comparison of the menu restructuring.

You can now choose to apply updates and enhancements using one of the five following options:

  1. Install Software at Latest Available Level: This option installs everything dealing with the selected software. To get into this option directly use the fastpath command smit install_latest. This option applies all updates, enhancements and new software products (if the customer has ordered it and it is on the installation media). Selections can be made at the LPP or option level, and all product code and updates will automatically be applied for each selection.

    Selection of an LPP or option from the software listing installs all software on the media for that LPP or option, including installation images, maintenance levels, enhancements and subsystems (selective fixes). It will update the LPP or option to the very latest level.

  2. Install Maintenance Levels: This option installs fixes and enhancements. To get into this option directly use the fastpath command
    smit install_maintenance. This SMIT menu panel lists only the special maintenance level PTFs on the installation media. The user can choose to have updates and enhancements applied. Selections can be made at the option level. New software products (installation images) are not installed through this menu (use the install menu and select the new version of the LPPs you wish to install, such as Motif 1.2, X11.5 or AIC 1.2).
  3. Install Enhancements: This menu option installs individual enhancements. To get into this option directly use the fastpath command smit install_enhancements. This SMIT panel lists only the special enhancement PTFs on the installation media. The user can choose to have only enhancements applied. Selections can be made at the LPP or by individual enhancement. Any updates which are required for the enhancement will also be automatically applied. New software products are not installed through this menu..
  4. Install Subsystems (Selective Fixes): This option installs fixes for each subsystem. To get into this menu option directly, use the fastpath command smit install_subsystems. This panel lists all subsystem PTFs on the installation media. The user can select individual subsystems and have the updates applied to these subsystems only. Selections can be made at the LPP, option or subsystem level. New software products are not installed through this menu.
  5. Install From All Software on Installation Media: This option installs every kind of product or update from the media. To get into this option directly, use the fastpath command smit install_selectable_all. The user can select from anything on the media, including installation images, maintenance levels, enhancements and fixes. Selections can be made at the LPP, option, subsystem or fix/enhancement level, depending on whether they are selecting a software package, maintenance level, enhancement or subsystem. This is the only menu that lists every installation image and PTF on the installation media.

Old Menu Tree

Here is the old menu tree SMIT was displaying, before applying PTF U418283 (this one made SMIT changes):


System Management
Installation and Maintenance
Standard Installation & Maintenance
Software Installation & Maintenance
Install / Update Software
Install Software With Updates
Install Software Without Updates
Install Updates Only
List All Software on Installation Media
List All Problems Fixed by Software on Installation Media
List All Applied but Not Committed Software
Commit Applied Software (Remove Previous Version)
Reject Applied Updates (Use Previous Version)
Remove Applied Software Products
Copy Software to Hard Disk for Future Installation
Clean Up After a Failed Installation
Software Inventory
List All Installed Software
List All Updates to a Software Product
Show History of a Software Product
List Prerequisites of a Software Product
List Dependents of a Software Product
Show ID of a Software Product
List Files Included in a Software Product
Verify a Software Product
System Maintenance
...
Diskless Workstation Management
...
Remote /usr Client Management
...

Figure: Old Installation Menu Tree until AIX 3.2.3

New Menu Tree

Here is the new menu tree SMIT displays, once PTF U418283 is applied:


System Management
Software Installation and Maintenance
Install / Update Software
Install / Update Selectable Software (Custom Install)
Install Software at Latest Available Level
Install Maintenance Levels
Install Enhancements
Install Subsystems (Selective Fixes)
Install From All Available Software Packages
Install ALL Software on Installation Media
Copy Software to Hard Disk for Future Installation
Clean Up After a Failed Installation
List All Software on Installation Media
List All Problems Fixed by Software on Install Media
List Installed Software
List the Installed Software
List Maintenance Level of a Software Product
Show History of a Software Product
List Prerequisites of a Software Product
List Dependents of a Software Product
Show ID of a Software Product
List Files Included in a Software Product
Manage Applied Software (List, Commit, Reject, Remove)
List All Applied but Not Committed Software
Commit Applied Software (Remove Previous Version)
Reject Applied Software Updates (Use Previous Version)
Remove Applied Software Products
Verify Correct Software Installation
Remote / usr Client Management & Installation
Install / Update This Client From Remote /usr
List Installed Software
List the Installed Software
List Maintenance Level of a Software Product
Show History of a Software Product
List Prerequisites of a Software Product
List Dependents of a Software Product
Show ID of a Software Product
List Files Included in a Software Product
Verify Correct Software Installation
Verify Consistent Installation Level

Figure: New Installation Menu Tree since AIX 3.2.4

SMIT Menu Changes

The SMIT menus have been changed to reflect the new PTF types (maintenance levels, enhancements, subsystem fixes) and to increase usability of software listing by using English-like descriptions, such as: