What if you want to get the 7th line of a text file. For example, you could get the 7th line of the /etc/hosts file, by using the head and tail commands, like this:

# head -7 /etc/hosts | tail -1
# Licensed Materials - Property of IBM

An even easier way to do it, is:

# sed -n 7p /etc/hosts
# Licensed Materials - Property of IBM

Once you've successfully set up live partition mobility on a couple of servers, you may want to script the live partition mobility migrations, and at that time, you'll need the commands to perform this task on the HMC.

In the example below, we're assuming you have multiple managed systems, managed through one HMC. Without, it would be difficult to move an LPAR from one managed system to another.

First of all, to see the actual state of the LPAR that is to be migrated, you may want to start the nworms program, which is a small program that displays wriggling worms along with the serial number on your display. This allows you to see the serial number of the managed system that the LPAR is running on. Also, the worms will change color, as soon as the LPM migration has been completed.

For example, to start nworms with 5 worms and an acceptable speed on a Power7 system, run:

# ./nworms 5 50000

Next, log on through ssh to your HMC, and see what managed systems are out there:

> lssyscfg -r sys -F name
Server1-8233-E8B-SN066001R
Server2-8233-E8B-SN066002R
Server3-8233-E8B-SN066003R

It seems there are 3 managed systems in the example above.

Now list the status of the LPARs on the source system, assuming you want to migrate from Server1-8233-E8B-SN066001R, moving an LPAR to Server2-8233-E8B-SN066002R:

> lslparmigr -r lpar -m Server1-8233-E8B-SN066001R
name=vios1,lpar_id=3,migration_state=Not Migrating
name=vios2,lpar_id=2,migration_state=Not Migrating
name=lpar1,lpar_id=1,migration_state=Not Migrating

The example above shows there are 2 VIO servers and 1 LPAR on server Server1-8233-E8B-SN066001R.

Validate if it is possible to move lpar1 to Server2-82330E8B-SN066002R:

> migrlpar -o v -t Server2-8233-E8B-SN066002R -m 
Server1-8233-E8B-SN066001R --id 1
> echo $?
0

The example above shows a validation (-o v) to the target server (-t) from the source server (-m) for the LPAR with ID 1, which we know from the lslparmigr command is our LPAR lpar1. If the command returns a zero, the validation has completed successfully.

Now perform the actual migration:

> migrlpar -o m -t Server2-8233-E8B-SN066002R 
-m Server1-8233-E8B-SN066001R -p lpar1 &

This will take a couple a minutes, and the migration is likely to take longer, depending on the size of memory of the LPAR.

To check the state:

> lssyscfg -r lpar -m Server1-8233-E8B-SN066001R -F name,state

Or to see the number of bytes transmitted and remaining to be transmitted, run:

> lslparmigr -r lpar -m Server1-8233-E8B-SN066001R -F name,migration_state,bytes_transmitted,bytes_remaining

Or to see the reference codes (which you can also see on the HMC gui):

> lsrefcode -r lpar -m Server2-8233-E8B-SN066002R
lpar_name=lpar1,lpar_id=1,time_stamp=06/26/2012 15:21:24,
   refcode=C20025FF,word2=00000000
lpar_name=vios1,lpar_id=2,time_stamp=06/26/2012 15:21:47,
   refcode=,word2=03400000,fru_call_out_loc_codes=
lpar_name=vios2,lpar_id=3,time_stamp=06/26/2012 15:21:33,
   refcode=,word2=03D00000,fru_call_out_loc_codes=

After a few minutes the lslparmigr command will indicate that the migration has been completed. And now that you know the commands, it's fairly easy to script the migration of multiple LPARs.

The default value of hcheck_interval for VSCSI hdisks is set to 0, meaning that health checking is disabled. The hcheck_interval attribute of an hdisk can only be changed online if the volume group to which the hdisk belongs, is not active. If the volume group is active, the ODM value of the hcheck_interval can be altered in the CuAt class, as shown in the following example for hdisk0:

# chdev -l hdisk0 -a hcheck_interval=60 -P

The change will then be applied once the system is rebooted. However, it is possible to change the default value of the hcheck_interval attribute in the PdAt ODM class. As a result, you won't have to worry about its value anymore and newly discovered hdisks will automatically get the new default value, as illustrated in the example below:

# odmget -q 'attribute = hcheck_interval AND uniquetype = \
PCM/friend/vscsi' PdAt | sed 's/deflt = \"0\"/deflt = \"60\"/' \
| odmchange -o PdAt -q 'attribute = hcheck_interval AND \
uniquetype = PCM/friend/vscsi'

If your system hangs with LED code 555, it will most likely mean that one of your rootvg file systems is corrupt. The following link will provide information on how to resolve it:

http://www-304.ibm.com/support/docview.wss?uid=isg3T1000217

After completing the procedure, the system may still hang with LED code 555. If that happens, boot the system from media and enter service mode again, and access the volume group. Then check what the boot disk is according to:

# lslv -m hd5

Then also check your bootlist:

# bootlist -m normal -o

If these 2 don't match, set the boot list to the correct disk, as indicated by the lslv command above. For example, to set it to hdisk1, run:

# bootlist -m normal hdisk1

And then, make sure you can run the bosboot commands:

# bosboot -ad /dev/hdisk1
# bosboot -ad /dev/ipldevice

Note: exchange hdisk1 in the example above with the disk that was indicated by the lslv command.

If the bosboot on the ipldevice fails, you have 2 options: Recover the system from a mksysb image, or recreate hd5. First, create a copy of your ODM:

# mount /dev/hd4 /mnt
# mount /dev/hd2 /mnt/usr
# mkdir /mnt/etc/objrepos/bak
# cp /mnt/etc/objrepos/Cu* /mnt/etc/objrepos/bak
# cp /etc/objrepos/Cu* /mnt/etc/objrepos
# umount /dev/hd2
# umount /dev/hd4
# exit

Then, recreate hd5, for example, for hdisk1:

# rmlv hd5
# cd /dev
# rm ipldevice
# rm ipl_blv 
# mklv -y hd5 -t boot -ae rootvg 1 hdisk1
# ln /dev/rhd5 /dev/ipl_blv
# ln /dev/rhdisk1 /dev/ipldevice
# bosboot -ad /dev/hdisk1

If things still won't boot at this time, the only option you have left is to recover the system from a mksysb image.

To familiarize yourself with using USB drives on AIX, take a look at the following article at IBM developerWorks:

http://www.ibm.com/developerworks/aix/library/au-flashdrive/

Before you start using it, make sure you DLPAR the USB controller to your LPAR, if not done so already. You should see the USB devices on your system:

# lsconf | grep usb
+ usbhc0 U78C0.001.DBJX589-P2          USB Host Controller
+ usbhc1 U78C0.001.DBJX589-P2          USB Host Controller
+ usbhc2 U78C0.001.DBJX589-P2          USB Enhanced Host Controller
+ usbms0 U78C0.001.DBJX589-P2-C8-T5-L1 USB Mass Storage

After you plug in the USB drive, run cfgmgr to discover the drive, or if you don't want the run the whole cfgmgr, run:

# /etc/methods/cfgusb -l usb0

Some devices may not be recognized by AIX, and may require you to run the lquerypv command:

# lquerypv -h /dev/usbms0

To create a 2 TB file system on the drive, run:

# mkfs -olog=INLINE,ea=v2 -s2000G -Vjfs2 /dev/usbms0

To mount the file system, run:

# mount -o log=INLINE /dev/usbms0 /usbmnt

Then enjoy using a 2 TB file system:

# df -g /usbmnt
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/usbms0     2000.00   1986.27    1%     3182     1% /usbmnt

It's very easy to determine the parent process ID, without looking it up in the process list. For example for the current korn shell process, you can determine the parent process of the korn shell process, by looking at the process list:

 # ps -ef | grep ksh | grep -v grep
    root  8061040 17891578   0 22:28:32  pts/0  0:00 -ksh

In the example above you can see that the parent process of the korn shell process with PID 8061040 is 17891578. The same answer can be retrieved by simply looking at the PPID variable:

# echo $PPID
17891578

It's quite easy to generate a PDF file from a text file on AIX. What you need to do that, are both Enscript and Ghostscript installed. Both of them are RPMs that can be found in the AIX Toolbox for Linux Applications. Download the enscript and ghostscript RPMs, along with the RPMs ghostscript-fonts, libpng and urw-fonts, which are required by Ghostscript to run. Put the 5 RPMs in a single folder on your AIX system and run the following command to install all five:

# rpm -ihv *rpm

Now that it is installed, you can easily generate a PDF file. For example, if you wish to generate a PDF file from /etc/motd, run the following command:

# /opt/freeware/bin/enscript -B -p - /etc/motd \
| /usr/bin/gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \
-sOutputFile=/tmp/motd.pdf -f -

The PDF file is written to /tmp/motd.pdf, and can be viewed with any PDF viewer.

To create a printer queue that dumps its contents to /dev/null, simply run the following command:

# /usr/lib/lpd/pio/etc/piomkpq -A file -p generic -d null -D asc -q lpnull

This will create a printer queue called lpnull and it will write any print jobs to /dev/null.

At some times it may be necessary to create a dummy disk device, for example when you need a disk to be discovered while running cfgmgr with a certain name on multiple hosts.

For example, if you need the disk to be called hdisk2, and only hdisk0 exists on the system, then running cfgmgr will discover the disk as hdisk1, not as hdisk2. In order to make sure cfgmgr indeed discovers the new disk as hdisk2, you can fool the system by temporarily creating a dummy disk device.

Here are the steps involved:

First: remove the newly discovered disk (in the example below known as hdisk1 - we will configure this disk as hdisk2):

# rmdev -dl hdisk1

Next, we create a dummy disk device with the name hdisk1:

# mkdev -l hdisk1 -p dummy -c disk -t hdisk -w 0000

Note that running the command above may result in an error. However, if you run the following command afterwards, you will notice that the dummy disk device indeed has been created:

# lsdev -Cc disk | grep hdisk1
hdisk1 Defined    SSA Logical Disk Drive

Also note that the dummy disk device will not show up if you run the lspv command. That is no concern.

Now run the cfgmgr command to discover the new disk. You'll notice that the new disk will now be discovered as hdisk2, because hdisk0 and hdisk1 are already in use.

# cfgmgr
# lsdev -Cc disk | grep hdisk2

Finally, remove the dummy disk device:

# rmdev -dl hdisk1

During a system decommission process, it is advisable to format or at least erase all drives. There are 2 ways of accomplishing that:

If you have time:

AIX allows disks to be erased via the Format media service aid in the AIX diagnostic package. To erase a hard disk, run the following command:

# diag -T format

This will start the Format media service aid in a menu driven interface. If prompted, choose your terminal. You will then be presented with a resource selection list. Choose the hdisk devices you want to erase from this list and commit your changes according to the instructions on the screen.

Once you have committed your selection, choose Erase Disk from the menu. You will then be asked to confirm your selection. Choose Yes. You will be asked if you want to Read data from drive or Write patterns to drive. Choose Write patterns to drive. You will then have the opportunity to modify the disk erasure options. After you specify the options you prefer, choose Commit Your Changes. The disk is now erased. Please note, that it can take a long time for this process to complete.

If you want to do it quick-and-dirty:

For each disk, use the dd command to overwrite the data on the disk. For example:

for disk in $(lspv | awk '{print $1}') ; do
   dd if=/dev/zero of=/dev/r${disk} bs=1024 count=10
   echo $disk wiped
done

This does the trick, as it reads zeroes from /dev/zero and outputs 10 times 1024 zeroes to each disk. That overwrites anything on the start of the disk, rendering the disk useless.