I’ve written a bit about the Administration Runtime Expert (which you will often see referenced as ARE) previously.
As part of the Administration Runtime Expert support, IBM has shipped a few basic ARE templates that can be used without requiring you to have the Administration Runtime Expert product (5733ARE) installed on your system. A template defines the environmental information – such as configuration setting or attributes – that are expected. There are currently have four templates available as part of the operating system. All of these can be run on an IBM i partition from Qshell.
One specific utility (template) that I want to tell you about is the network health checker. This network configuration plug-in for ARE verifies a variety of TCP/IP configuration settings and network characteristics. It checks for common configuration issues, much like reviewing the information available via the CFGTCP command. This template also performs basic network operations, such as looking up localhost and checking if all configured DNS servers can be reached. You can run this template to verify that the system’s network configuration is working in a fast, reliable, and repeatable manner.
Here’s a practical example ….
I use Navigator for i quite a bit – in particular, the performance tasks, but for other things as well. I was trying to use Navigator on an IBM i partition that I’d never worked with before and it was SSSSLLLOOOOWWW! Of course, the first thing one tends to look at is the CPU and memory configuration for the partition – but these were fine – uncapped to 2 cores with 10GB of memory – plenty to run Navigator. So the next step was to see if I had any networking issues.
I decided to give the ARE network health checker a try.
You need to use QShell to run these templates. There are various ways you can do this, but perhaps the simplest is to simply start the QShell environment with STRQSH and work from there.
To run the network health checker, you use the following incantation:
/QIBM/ProdData/OS/OSGi/templates/bin/areVerify.sh –network
The network health checker immediately identified the problem – retrieving the local host name took a long time – 28 seconds! The text below was the information returned from the network health checker that clearly identified the problem (I have highlighted the problem in red).
Running plugin Network Verifier
Retrieving local host name
Start time is Tue Aug 27 16:39:06 CDT 2013
Local host name is etcsdi1s.rchland.ibm.com
End time is Tue Aug 27 16:39:34 CDT 2013
Warning: Retrieving local host name took longer than 10 seconds. Elapsed time was 28 seconds
Details: Taking this long to resolve localhost can lead to slow network performance.
The rest of the output from the network health checker gave me information about the network configuration – so it was very easy to compare the output from the system with very poor performance to that of a system that was working well. Sure enough – the DNS server settings were incorrect for the partition with the performance issue. I corrected the DNS server configuration and my problem was resolved.
Note that the Network Health Checker is also available via the ARE graphical user interface; however, as I’ve just written, you do not need the ARE product to use this feature.
There are a few other health checkers available with the areVerify.sh script. Invoking this script without any parameters will return the following:
/QIBM/ProdData/OS/OSGi/templates/bin/areVerify.sh
Usage: areVerify.sh
Valid parameter:
-network : Verify network configuration and status
-iasserver server_name : Verify the 'server_name' IAS server
-precheck : Verify software products that are necessary to use the IBM Application Runtime Expert for i
-hostservers : Verify the host servers are active
Finally, here are a couple useful websites with additional information on the Administration Runtime Expert:
Revolutionize your application and product support
The original name of ARE was Application Runtime Expert. IBM renamed ARE to Administration Runtime Expert in 2017.
This blog post was edited to fix broken links on March 29, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.