Problems may be encountered with printers connected via Axis Boxes to the network, producing errors with some of the prints, usually larger prints. The printer prints a page with the following text: "ERROR: timeout, OFFENDING COMMAND: timeout, STACK:".

The solution is quite easy. The port speed of the LPT port used on the Axis Box is probably set to "Standard". Set it to "High Speed" and timeouts don't occur anymore.

How do you create an external destination in HP Output Server? I wanted to deliver a print to a destination, that executes an external command on the job. Here's the configuration that works:

I named by logical destination external, which points to queue qexternal and the physical destination is called pdexternal.

The logical destination:

-template-version              : $Date: 2002/03/01 02:35:32 $
-template-component            : false
-managing-server               : jqm_06
-disabled                      : false
-form-feed-default             : false
-maximum-tries-default         : 30000
-printer-name                  : external
-destination-type              : file
-queue-supported               : qexternal
-template-type                 : standard-template
-retention-period-default      : 0
-descriptor                    : test external delivery pathway
-input-document-formats-supported: literal,
                                 ps,
                                 pdf,
                                 text,
                                 frame,
                                 hp-pcl,
                                 afp
-template                      : false
-template-classification       : static-template
-printer-realization           : 0

-template-version              : $Date: 2002/01/04 17:24:14 $
-queue-name                    : qexternal
-managing-server               : jqm_06
-disabled                      : false
-template-type                 : standard-template
-descriptor                    : test external delivery pathway
-queue-warning-threshold       : 50
-scheduler-assigned            : Pd-FIFO
-template                      : false
-template-classification       : static-template
-logical-printers-assigned     : {external, 'available'}
-message                       : Enabled
-physical-printers-registered  : pdexternal
-job-order                     : 

-template-version              : $Date: 2002/03/12 19:59:09 $
-template-component            : false
-managing-server               : dsm_06a
-ghostscript-program           : !{dazel-install-directory}!/bin/gs
-disabled                      : false
-form-feed-default             : false
-deliver-program               : /appl/hpos/external.sh
-printer-name                  : pdexternal
-queue-supported               : qexternal
-template-device-name          : generic
-file-overwrite-default        : true
-template-type                 : standard-template
-character-set-default         : iso-latin-1
-physical-device-type          : external
-descriptor                    : test external delivery pathway
-medium-default                : iso-a4-white
-font-directories              : !{dazel-install-directory}!/lib/
                                 FONTS/Soft_Horizons
-template                      : false
-character-sets-supported      : iso-latin-1,
                                 ascii
-template-classification       : static-template
-file-base-directory           : /tmp
-printer-realization           : 1
-printer-connection-mode       : external
-ps-init-directories           : !{dazel-install-directory}!/lib/PS
-fifo-directory                : /appl/hpos/fifo
-write-only-device             : true
-deliver-arguments             : !{fifo-directory}!/!{job-identifier}!

#!/bin/ksh

{
echo
echo "Process:"
echo $$
echo "Parameters:"
echo $0 $*
echo "Who am I?"
whoami
} >> /appl/hpos/external.out

file=$2
base=`basename $file`
cp $file /appl/hpos/fifo/$base.$$
mail user@domain.com < $file
fifo=$1
echo "-job-state-on-printer completed" > $1
exit 0

# pdpr -dexternal /etc/motd

As HP Output Server doesn't support hot backups, It is recommended to do monthly maintenance, in order to create a backup and keep things healthy. Assuming HPOS is installed in /appl/hpos and its data is stored in /data/hpos:

• Notify your users of the downtime.
• Stop any applications that use HPOS.
• Clear out any "hanging" jobs.
• Clear out the /data/hpos/var/tmp directory.
• For every log file in /data/hpos/var/log, issue:

  # cp /dev/null > $logfile

• Delete and recreate the JQMs:

  # config_server -d $jqm
  # config_server -t JQM $jqm

  JQM job databases tend to grow over time. By re-creating them, you can save lots on disk usage and I/O performance. You can do this step safely, as all information is stored in the CM. If you use a server-startup-order, you should also update this again after you've recreated the JQM:

  # config_server -u -x"-server-start-order xxx" $jqm

• Delete and recreate the DLMs:

  # config_server -d $dlm
  # nfig_server -t DLM $dlm

  This step may be required because sometimes a DLM produces errors, which you might see in JobTracker. These errors are solved by recreating the DLMs. Again, remember to set your server-startup-order, if you use it.
• Stop all HPOS daemons:

  # stop_server -t all

• Create a backup of the system.
• If available, download any service packs and install them now:

  # . /appl/hpos/etc/setup_env.sh
  # perl /appl/hpos/etc/patch.pl

  If this fails, just try it again, or you can restore your backup.
• Also upgrade any client systems to the same service pack. If necessary, also check the Windows client versions required.
• Start all daemons again:

  # start_server -t all

• Test if everything is working.
• Reboot your server to free up memory.
• Again, test if everything is working.
• Startup all applications again, that use HPOS.
• Notify your users that the system is available.
• Document any changes (e.g. Service Packs) and problems encountered.
• Store the software you've used somewhere safe.

#!/bin/ksh
# Save HPOS config config
. /appl/dazel/etc/setup_env.sh
rm -f /appl/hpos/dump-file
pdconfig -d -c /appl/hpos/dump-file

If a device like a printer box, jet-direct card or a Xerox Document Centre does not ping anymore from the HPOS server, it will result in connection timed out errors within HPOS. If this device however does ping from another location within your netwerk, you have a network issue, and its very likely that your network switch simply needs to learn the IP address and/or MAC address of the device. You can do this by sending a packet from the device to the HPOS server. But how do you get this device to send a packet itself, because a ping is not available?

For an Axis Box, go to the Network Settings (which is available from the Admin window). Now fill in the IP address of your HPOS server as the Primary DNS server and click on Ok. Ofcourse DNS resolving will fail (if your HPOS server isn't a DNS server), but quite immediately after clicking Ok, you will notice that the Axis Box will ping again from the HPOS server. If it pings again, change the primary DNS server in your Axis Box back to its original value.

The same can be done with other devices, like the Xerox Document Centre. Go to the TCP/IP properties (usually under Properties -> Connectivity -> Protocols). Set the IP Address Resolution to STATIC (if you're using DHCP) and update the primary DNS server to the IP address of the HPOS server. Then click on Reboot on the Status window, and you'll notice that it will ping again to the HPOS server. Again, change everything back to their original values, if the Document Centre pings.

HACMP provides events, which can be used to most accurately monitor the cluster status, for example via the Tivoli Enterprise Console. Each change in the cluster status is the result of an HACMP event. Each HACMP event has an accompanying notify method that can be used to handle the kind of notification we want.

Interesting Cluster Events to monitor are:

• node_up
• node_down
• network_up
• network_down
• join_standby
• fail_standby
• swap_adapter
• config_too_long
• event_error

# smitty hacmp
Cluster Configuration
Cluster Resources
Cluster Events
Change/Show Cluster Events

# odmget HACMPevent

If you wish to enable MAC Address take-over on an HACMP cluster, you need a virtual MAC address. You can do a couple of things to make sure you have a unique MAC Address on your network:

• Use the MAC address of an old system, that you know has been destroyed.
• Buy a new network card, use the MAC address, then destroy this card.
• Use a DEADBEEF address: (0xdeadbeef1234). This is a non-existent hardware vendor. You might run into problems with someone else making up a deadbeef address, so use this option with caution.

• clstat - show cluster state and substate; needs clinfo.
• cldump - SNMP-based tool to show cluster state.
• cldisp - similar to cldump, perl script to show cluster state.
• cltopinfo - list the local view of the cluster topology.
• clshowsrv -a - list the local view of the cluster subsystems.
• clfindres (-s) - locate the resource groups and display status.
• clRGinfo -v - locate the resource groups and display status.
• clcycle - rotate some of the log files.
• cl_ping - a cluster ping program with more arguments.
• clrsh - cluster rsh program that take cluster node names as argument.
• clgetactivenodes - which nodes are active?
• get_local_nodename - what is the name of the local node?
• clconfig - check the HACMP ODM.
• clRGmove - online/offline or move resource groups.
• cldare - sync/fix the cluster.
• cllsgrp - list the resource groups.
• clsnapshotinfo - create a large snapshot of the HACMP configuration.
• cllscf - list the network configuration of an HACMP cluster.
• clshowres - show the resource group configuration.
• cllsif - show network interface information.
• cllsres - show short resource group information.
• lssrc -ls clstrmgrES - list the cluster manager state.
• lssrc -ls topsvcs - show heartbeat information.
• cllsnode - list a node centric overview of the hacmp configuration.

When you're using HACMP, you usually have multiple network adapters installed and thus multiple network interface to handle with. If AIX configured the default gateway on a wrong interface (like on your management interface instead of the boot interface), you might want to change this, so network traffic isn't sent over the management interface. Here's how you can do this:

First, stop HACMP or do a take-over of the resource groups to another node; this will avoid any problems with applications when you start fiddling with the network configuration.

Then open up a virtual terminal window to the host on your HMC. Otherwise you would loose the connection, as soon as you drop the current default gateway.

Now you need to determine where your current default gateway is configured. You can do this by typing:

# lsattr -El inet0
# netstat -nr

# odmget -q"attribute=route" CuAt

# lsattr -El inet0 | awk '$2 ~ /hopcount/ { print $2 }' | read GW
# chdev -l inet0 -a delroute=${GW}

# route add 0 [ip address of default gateway: xxx.xxx.xxx.254] -if enX

# chdev -l inet0 -a addroute=net,-hopcount,0,,0,[ip address of default gateway]

# chdev -l inet0 -a addroute=net,-hopcount,0,if,enX,,0,[ip address of default gateway]

# lsattr -El inet0
# odmget -q"attribute=route" CuAt

With HACMP, you can run into the following error during a verification/synchronization:

WARNING: The LVM time stamp for shared volume group: testvg is inconsistent with the time stamp in the VGDA for the following nodes: host01

To correct the above condition, run verification & synchronization with "Automatically correct errors found during verification?" set to either 'Yes' or 'Interactive'. The cluster must be down for the corrective action to run.

This can happen when you've added additional space to a logical volume/file system from the command line instead of using the smitty hacmp menu. But you certainly don't want to take down the entire HACMP cluster to solve this message.

First of all, you don't. The cluster will fail-over nicely anyway, without these VGDA's being in sync. But, still, it is an annoying warning, that you would like to get rid off.

Have a look at your shared logical volumes. By using the lsattr command, you can see if they are actually in sync or not:

host01 # lsattr -Z: -l testlv -a label -a copies -a size -a type -a strictness -Fvalue
/test:1:809:jfs2:y:

host02 # lsattr -Z: -l testlv -a label -a copies -a size -a type -a strictness -Fvalue
/test:1:806:jfs2:y:

HACMP automatically runs a verification every night, usually around mid-night. With a very simple command you can check the status of this verification run:

# tail -10 /var/hacmp/log/clutils.log 2>/dev/null|grep detected|tail -1

# smitty clautover.dialog

# odmget HACMPcluster
# odmget HACMPtimersvc