This chapter discusses the following two aspects of the AIX V3.2 operating system:
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.
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:
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.
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.
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.
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.
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.
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.
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:
The locations for saved files for AIX V3.2 installation are:
The location for saved files for AIX V3.2 update is:
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.
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:
See Software States and Events in installp Summary for more details on the installp summary and lslpp command software states.
This section introduces the terminology which is used by IBM in describing the AIX update and installation processes.
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.
The term OPP sometimes refers to the installable options of an LPP.
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.
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.
This contains all the fixes since AIX V3.2.0.
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.
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.
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.
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.
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.
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.
Two new flags have been added to the lslpp command to help determine the level of the software on a system.
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.
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.
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.logNote: 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:
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:
The following screen will be displayed, if there are any problems.
Following is a summary of the procedure to be followed for installing the
complete maintenance level using the command update_all:
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.
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.
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.
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.
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. 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.
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 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
# 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
The update of your system will require about 8000 blocks of
If the above step fails, the following message will be displayed.
space in /tmp. This program will free this space for you by removing
all files in /tmp. Subdirectories in /tmp will not be removed.
If there is still not enough space and /tmp is only 8192KB then an
attempt will be made to extend the /tmp file system by 1 partition
(4096KB).
Type [ENTER] to have this program remove all files in /tmp, or
Type [Q] to quit this program, and selectively free the
necessary space yourself.
This program was unable to free the necessary space in /tmp.
Either the /tmp file system is too small, or you have a
significant amount of space in subdirectories in /tmp.
Please free the necessary space in /tmp and run this program again.
SUCCESS:
Your machine has been successfully updated. The details of the
install can be found in the file /tmp/install.log. A summary can be
found in the file /tmp/install.summary. You may remove these files
whenever you have finished them, they are for your information only.
This update requires that you reboot your machine in order for the
fixes to the kernel, device drivers, and some daemons to take effect.
Type [Q] when you are finished viewing this message.
PROBLEM FOUND:
A problem was encountered installing your machine. There
are a number of status files which are useful for determining
the cause of this failure.
If the file /tmp/install.summary does not exist, then
installp failed during requisite or space checking. That is,
before attempting to install any PTF packages. The most likely
cause of this failure is lack of disk space.
If the file /tmp/install.summary does exist, then the processing of
PTF packages had begun and failed for some reason. Search this file
for the string "FAILED" to determine which PTF packages could not
be installed.
The file /tmp/install.log file contains the complete output of the
installp program. You can search for the PTF package IDs which you
located in the install summary to find any error messages printed
the failing PTF packages.
Please call your IBM Service Representative if you need more
information regarding the diagnosis and correction of this problem.
# update_all -d<device>
where <device> is the device containing the
maintenance level image, in this example rmt0.1.
Utility ptfdir_clean
Automatic Apply/Commit of Maintenance Levels
Changes in bosboot Processing
Command ifreqs
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.
Changes in Command installp
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.
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.
The installp command produces a summary report at the end. Following is an example of such a summary:
Installp SummaryThe following table lists the possible installation events, event results and software states for that 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 results of the installp summary are described below:
The software states in installp are described below:
You can now choose to apply updates and enhancements using one of the five following options:
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.
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
...
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
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:
# installp -acqNX -d<device> all