Let's say you have a helpdesk, where they must be able to run a script under user-id root to check or monitor a system:

First, create a script, you wish your helpdesk to run.

Modify your /etc/inetd.conf file and add:

check stream tcp wait root /usr/local/bin/script.sh

check 4321/tcp

# telnet [system] 4321

The uname -Ls command will show you the partition number and the partition (lpar) name. When setting the resource allocation for a partition profile, set the minimum to the absolute bare minimum, and set the maximum as high as possible.

For memory there are special considerations:

• If you set the maximum too low and you wish to exceed above the maximum amount of memory defined in the active profile, you can't simply adjust the profile and put extra memory in via DLPAR, because the LPAR has been initialized with a certain page table size, based on the maximum amount of memory setting. Therefore, a reboot will be required when you wish to use more memory than defined in the active profile. If you do try it however, you'll receive the following error:

  HMCERRV3DLPAR018: There is no memory available for dynamic logical partioning on this partition.

• If you set the maximum too high, the partition will be initialize with a large page table size, which uses too much memory for overhead, which you might never use.

Use the following command to find any files that no longer have a valid user and/or group, which may happen when a group or user is deleted from a system:

# find / -fstype jfs \( -nouser -o -nogroup \) -ls

It sometimes occurs that a file system runs full, while a process is active, e.g. when a process logs its output to a file. If you delete the log file of a process when it is still active, the file will be gone, but the disk space will usually not be freed. This is because the process keeps the inode of the file open as long as the process is active and still writes to the inode. After deleting the file, it's not available as file anymore, so you can't view the log file of the process anymore. The disk space will ONLY be freed once the process actually ends.

To overcome it, don't delete the log file, but copy /dev/null to it:

# cp /dev/null [logfile]

In general IBM recommends that JFS log devices be set to 2MB for every 1GB of data to be protected. The default jfslog for rootvg is /dev/hd8 and is by default 1 PP large. In some cases, file system activity is too heavy or too frequent for the log device. When this occurs, the system will log errors like JFS_LOG_WAIT or JFS_LOG_WRAP.

First try to reduce the filesystem activity. If that's not possible, this is the way to extend the JFS log:

• Determine which log device to increase. This can be determined by its Device Major/Minor Number in the error log:

  # errpt -a

  An example output follows:

  Device Major/Minor Number
  000A   0003
  

  The preceding numbers are hexadecimal numbers and must be converted to decimal values. In this exmpale, hexadecial 000A 0003 equals to decimal numbers 10 and 3.
• Determine which device corresponds with these Device Major/Minor Numbers:

  # ls -al /dev | grep "10, 3"

  If the output from the preceding command reveals that the log device the needs to be enlarged is /dev/hd8 (the default JFS log device for rootvg), then special actions are needed. See further on.
• Increase the size of /dev/hd8:

  extendlv hd8 1

• If the jfslog device is /dev/hd8, then boot the machine into Service Mode and access the root volume group and start a shell. If the jfslog is a user created jfslog, then unmount all filesystems that use the jfslog in question (use mount to show the jfslog used for each filesystem).
• Format the jfslog:

  # logform [jsflog device]

  For example:

  logform /dev/hd8

• If the jfslog device is /dev/hd8, then reboot the system:

  # sync; sync; sync; reboot

  If the jfslog is a user created jfslog, then mount all filesystems again after the logform completed.

To find out if your machine has a 64 or 32 bit architecture:

# bootinfo -y

# bootinfo -K

# ls -ald /unix

# bootinfo -b

# bootinfo -r

# bootinfo -T

If you have a PMR open with IBM and you need to upload logs/snap/dump etcetera to IBM: You can use the below web interface to upload files. All you need is your PMR number, type (mostly AIX), and your email address. Once the files are uploaded, you get an email confirmation. You can still use the traditional ftp to testcase, should you prefer.

http://www.ecurep.ibm.com/app/upload

Getting yesterdays date on AIX can be a litte tricky. One way of doing this, is by using gnu-date:

# date --date=yesterday +%m%d%y

# perl -MPOSIX -le 'print strftime "%m%d%y",localtime(time-(60*60*24))'

The standard tool for cluster monitoring is clstat, which comes along with PowerHA SystemMirror/HACMP. Clstat is rather slow with its updates, and sometimes the required clinfo deamon needs restarting in order to get it operational, so this is, well, not perfect. There's a script which is also easy to use. It is written by PowerHA/HACMP guru Alex Abderrazag. This script shows you the correct PowerHA/HACMP status, along with adapter and volume group information. It works fine on HACMP 5.2 through 7.2. You can download it here: qha. This is version 9.06. For the latest version, check www.lpar.co.uk.

This tiny but effective tool accepts the following flags:

•   -n (show network interface info)
•   -N (show interface info and active HBOD)
•   -v (show shared online volume group info)
•   -l (log to /tmp/qha.out)
•   -e (show running events if cluster is unstable)
•   -m (show status of monitor app servers if present)
•   -1 (exit after first iteration)
•   -c (CAA SAN / Disk Comms)

# qha -nev

• ST_INIT: cluster configured and down
• ST_JOINING: node joining the cluster
• ST_VOTING: Inter-node decision state for an event
• ST_RP_RUNNING: cluster running recovery program
• ST_BARRIER: clstrmgr waiting at the barrier statement
• ST_CBARRIER: clstrmgr is exiting recovery program
• ST_UNSTABLE: cluster unstable
• NOT_CONFIGURED: HA installed but not configured
• RP_FAILED: event script failed
• ST_STABLE: cluster services are running with managed resources (stable cluster) or cluster services have been "forced" down with resource groups potentially in the UNMANAGED state (HACMP 5.4 only)