There are quite many nifty little tricks, which can make life easier for the AIX administrator carrying out typical tasks in his job. I'll start the collection, suggestions will be highly welcome and added here when they are messaged to me. No, i don't claim to have found out myself what stands here.
Please do not hesitate to share your knowledge.
bakunin
==================================================
- Restore single file from a mksysb tape:
put tape into tape drive rmtX and save original file first, it will be overwritten
# tctl -f /dev/rmtX rewind
# tctl -f /dev/rmtX.1 fsf3 ; tar -xvf /dev/rmtX.1 /path/to/file
- Reset the time counter of the SSA-RAID-Adapters cache battery (i.e. after a battery change):
# ssa_format -b -l <device>
- Access the hidden (IBM only) SBB panels on a POWER3 machine (6H1, H80, etc.):
In the main menu enter "14900"
- See all OS maintenance levels the machine is aware of:
# instfix -i | grep AIX_ML
- See all packages which are downlevel for a certain maintenance level:
At least the machine has to be aware of the maintenance level in question. List all the maintenance levels the machine is aware of (see there). Use the displayed keyword as argument for instfix and grep for ":-:' to get all packages downlevel for this ML.
# instfix -i | grep AIX_ML
# instfix -ick <ML_Keyword> | grep ':-:'
Example: Find all filesets downlevel relative to ML03
# instfix -i | grep AIX_ML
All filesets for 5.1.0.0_AIX_ML were found.
All filesets for 5100-01_AIX_ML were found.
All filesets for 5100-02_AIX_ML were found.
Not all filesets for 5100-03_AIX_ML were found.
Not all filesets for 5100-04_AIX_ML were found.
Not all filesets for 5100-05_AIX_ML were found.
Not all filesets for 5100-06_AIX_ML were found.
# instfix -ick 5100-03_AIX_ML | grep ':-:'
5100-03_AIX_ML:IMNSearch.rte.httpdlite:2.0.0.15:2.0.0.15:-:AIX 5100-03 Update
5100-03_AIX_ML:X11.adt.imake:5.1.0.15:5.1.0.15:-:AIX 5100-03 Update
5100-03_AIX_ML:X11.apps.xdm:5.1.0.25:5.1.0.25:-:AIX 5100-03 Update
Update IMNSearch.rte.httpdlite, X11.adt.imake and X11.apps.xdm to get to ML03.
- Shorten the /var/adm/wtmp file
This file can grow quite big and possibly exhaust disk space in /var. It is essential, though, to preserve the files inode therefore simply deleting it and then "touch /var/adm/wtmp" is a dangerous method. Use the following command instead (as root):
# cat /dev/null > /var/adm/wtmp
You might copy the file before for archival purposes:
# cp /var/adm/wtmp /path/to/wtmp.archive ; cat /dev/null > /var/adm/wtmp
- Prevent screen redraw with "more" ("man", ...)
Set the following variable (see this thread):
# MORE="-W notite" ; export MORE
- Find out the connection status to the HMC
To find out the connection status of the LPAR to the HMC issue
hscroot@hmc # lspartition -dlpar
but you can also get that information from the LPAR directly:
# /usr/sbin/rsct/bin/rmcdomainstatus -s ctrmc
Management Domain Status: Management Control Points
I A 0x9d8fee8dea7422d6 0001 10.130.113.79
I A 0x26fe4069162a4c12 0002 10.130.13.79
This means that both HMCs have correct RMC-connections. A counter example would be this, where the second HMC has no working connection:
# /usr/sbin/rsct/bin/rmcdomainstatus -s ctrmc
Management Domain Status: Management Control Points
I A 0x5d070d1bc6c9d0c0 0001 10.10.111.101
O A 0xcac7e15c5df1adfc 0002 10.10.111.102
- Find out the Volume Group type
You an get the information about a VG being a "classic", "big" or "scalable" VG also from other observations (i.e. observing the max. number of PPs in the VG, etc.), but the most foolproof way is to read the VGDA. The following example is a "classic" VG:# readvgda <PV-of-the-VG> | head -7
.....
..... Tue Jun 7 17:36:49 CEST:201
..... readvgda hdisk4
..... readvgda_file: /dev/rhdisk4
..... readvgda_type: smallvg
..... readvgda_ver: 3
.....
