Change in U.S. law requires updates

Due to a change in the law (The Energy Policy Act of 2005), Daylight Saving Time (DST) in the United States has been extended by four additional weeks. Starting in 2007, Daylight Saving Time begins on the second Sunday in March (March 11, 2007) and ends on the first Sunday in November (November 4, 2007).

If you use the QTIMZON system value, IBM has issued the following Program Temporary Fixes (PTFs) that add time zone descriptions to comply with the new rules for 2007 and beyond. After you apply the appropriate PTFs for your OS level, you can change the QTIMZON system value to the new value for your region. Note: Continue to check with IBM in the event that future PTFs become available.

• V5R4M0 PTFs SI26040 and SI25990
• V5R3M0 PTFs SI26039 and SI25991

Note: If your system uses a Hardware Management Console (HMC), you might need to apply additional fixes. If the HMC code is at version 6.1 or version 5.2.1, no additional fixes are required. Previous releases of the HMC code require additional fixes to support the changes in DST. Check with IBM for a list of PTFs that might apply to your HMC.

Download Help/FACTS with more information.

When you need to expand your sphere of resource monitoring, consider Robot/TRAPPER

Robot/TRAPPER adds another facet to the many ways the Robot products allow you to monitor resources. Robot/TRAPPER allows you to use the reliability of the System i to monitor any device with an IP address. This can include such varied equipment as automated teller machines (ATMs), Windows servers, hubs, environmental monitors, and more!

Check resources at predefined intervals
Robot/TRAPPER allows you to proactively ping (check the status of) any device that has an IP address at predefined intervals to ensure availability. It keeps track of the pulse of your network.

The Maintain Devices panel displays a device’s description, IP address, ping priority, and status. You can search the list of devices by device description or IP address.

You can use this panel to add, delete, and modify device records. When you select a device on the Maintain Devices panel, you can modify its description, message queue, library, or ping interval. You also can use the Maintain Devices panel to check the status of devices, place devices on hold so they are not pinged, and ping devices on demand.

If the device doesn’t respond to a ping, Robot/TRAPPER uses Robot/CONSOLE to notify you. You should assign your critical resources the highest ping priority so they are pinged more frequently than less important resources. When a critical device becomes unavailable, you have the full power of Robot/CONSOLE at your disposal to respond to the problem. Your Robot/CONSOLE message set might:

* Run OPAL code to attempt a recovery when a ping fails.

* Notify you immediately so that you can begin to monitor the situation and take corrective action. (If you want to notified by pager or e-mail message, you need Robot/ALERT.)

* Use the interface to Robot/ALERT to escalate the problem through a chain of people, or notify a whole group at the same time.

Listen for messages
Robot/TRAPPER also has the ability to receive SNMP traps (event notifications) from these devices. Devices can be added manually or Robot/TRAPPER can add them dynamically as traps are received.

Robot/TRAPPER running on the System i works with Robot/CONSOLE to let you know when your network devices have security breaches, completion messages, or application errors. This is accomplished by using a Management Information Base (MIB). The MIB tells Robot/CONSOLE what a message from a specific device means.

If you’ve defined a message set for that message, Robot/CONSOLE takes the action you have specified. Robot/TRAPPER ships with a number of common MIB source files that can be compiled to translate events from network devices. If the MIB you need is not supplied, you can usually download it from the equipment vendor’s Web site and compile it.

If you are doing (or would like to do) System i-based enterprise management, you should consider Robot/TRAPPER.

Interface to enterprise monitors
If you are not doing System i-based enterprise management, Robot/TRAPPER also acts as an interface for Robot/NETWORK and Robot/CONSOLE that allows two-way communications with an enterprise monitor such as Netcool or Remedy. Help/Systems supplies MIBs that you can compile on the enterprise monitor to enable it to translate the SNMP trap events sent by the System i.

When an SNMP trap (message) is sent to the enterprise monitor by a Robot product, the operations staff at the enterprise monitor console can review the event and reply to it directly. Robot/TRAPPER picks up the reply and directs it to its source, so the reply is applied to the correct System i message.

Every day, your network of devices grows bigger and becomes more complex. The job of network monitoring has also grown considerably—whether your monitoring efforts center on the System i or on a large enterprise. In fact, your network may have grown so complex that it’s scary. Robot/TRAPPER can help take the fear and confusion out of the equation. But, you’ll only know if you give it a try. Help/Systems invites you try it for 30 days for free!

Contributed by Terri Preston, Technical Consultant

By evaluating your goals, the choice may become clearer

If you have both Robot/SCHEDULE and Robot/CONSOLE, you have two Help/Systems products that can help you with resource monitoring. Robot/SCHEDULE checks local resources and their current status by using OPAL. Robot/CONSOLE lets you set up an automated process to monitor resources such as lines, subsystems, controllers, and more without writing OPAL. When you use Robot/CONSOLE resource monitoring, it notifies you whenever resources are not available (not in the expected state) and when their status changes again. It also provides a detailed history of all the status checks.

As you implement resource monitoring, you will find that some resources can be monitored by either Robot/SCHEDULE or Robot/CONSOLE. If you have both, how do you decide which is the better candidate to monitor what?

How does Robot/SCHEDULE excel?
Robot/SCHEDULE was the first of the Robot products to offer resource monitoring. The primary purpose of Robot/SCHEDULE’s resource monitoring is to check that resources are available when a job needs them to run successfully. Robot/SCHEDULE resource monitoring lets you:

* Create a job and use OPAL to check on the resource status.

* Schedule the job to run every so often (an EVERY type job that also can use time ranges).

* Schedule the job only when you need to check the status of the resource.

* Run the job on demand via the DO or DS override options.

* Put the job on hold easily.

* Send a pager, e-mail, or text message (via Robot/ALERT) each time the resource is still in the unexpected state when checked.

* Run a job based on resource status.

What does Robot/CONSOLE do differently?
Resource monitoring was so popular in Robot/SCHEDULE that when Robot/CONSOLE 4.0 was designed, Help/Systems decided to provide an even more robust systems management capability. Robot/CONSOLE lets you:

* Check a resource at intervals (ranging from 5 to 180 minutes) without scheduling a job.

* Set up resource checking easily; OPAL is not required.

* Check a resource more than once before reporting an unavailable status (check from one to 999 times).

* Track resource status history. This can help you identify “problem” resources.

* Include a summary of availability in the Robot/CONSOLE Good Morning Report.

* Schedule the RBCCHKRSC command as a Robot/SCHEDULE job and run it at a pre-determined time (on a schedule).

* Stop monitoring by changing the monitoring priority to zero.

* Reduce message overload. Robot/CONSOLE generates one message after the specified number of checks show the resource is not in its expected status. No further messages are sent until the resource’s status changes.

* Customize message text sent to a pager, by e-mail, or other notify options within a message set. (Note: Pager or e-mail notification requires Robot/ALERT.)

* Schedule the RBCCHKRSC command as a Robot/SCHEDULE job with the Force Message parameter set to *YES. Each time the job runs and the resource is not in the expected status a message, Robot/CONSOLE sends a message. For example:

RBCCHKRSC RESOURCE(QBATCH) TYPE(SBS) LIBRARY(QGPL) FRCMSG(*YES)

* Monitor a larger selection of resources.

Making the call
Both Robot/SCHEDULE and Robot/CONSOLE offer significant resource monitoring capabilities. When you are trying to decide which one to use, think about these points:

* If you are monitoring a resource primarily to make sure a job runs correctly and it can be monitored by Robot/SCHEDULE, it’s best to use Robot/SCHEDULE. Keeping all the information in Robot/SCHEDULE makes it easier to see job dependencies.

* If you need to monitor a resource that can’t be monitored by Robot/SCHEDULE, you must use Robot/CONSOLE.

* If you need to monitor a resource most of the time (not relative to any particular job) and it’s a resource that can be monitored by either product, use the product with which you are more familiar.

Setting up resource monitoring in Robot/CONSOLE
Setting up resource monitoring in Robot/CONSOLE involves two parts. First, you tell Robot/CONSOLE the resource to monitor. Then, you set up a message set to handle the message. The sample panels shown check the QBATCH subsystem every five minutes to make sure it is active.

Setting up resource monitoring in Robot/SCHEDULE
Robot/SCHEDULE can do the same thing. To set up monitoring in Robot/SCHEDULE, you would create two jobs—an EVERY-type job that runs every five minutes to check the subsystem and a reactive job with OPAL that reacts to the EVERY job. You need two jobs because OPAL can’t be attached to an EVERY-type job.

Conclusion
The Robot products are designed to be flexible and let you solve problems more than one way. If you have both Robot/SCHEDULE and Robot/CONSOLE, you have several ways to monitor resources to make sure jobs run smoothly and to improve data center management.

If you need to monitor resources beyond those that can be monitored by Robot/SCHEDULE or Robot/CONSOLE, take a look at Robot/TRAPPER.

Contributed by Heath Kath, Technical Training Consultant

Pinpoint key locations with interactive map plotting

Imagine being able to generate an interactive Google map that shows locations for your branch offices, customers, product installations, or even vehicles with real-time GPS tracking coordinates. The map would allow you to click on a marked location to display information from your System i database within a pop-up balloon. Within the balloon, you could even click on a hyperlink to display a related Web page or run an interactive SEQUEL business intelligence request to retrieve relevant information for the selected site.

All these capabilities are available to you right now. SEQUEL has been integrated with the Google maps function to support interactive map plotting based on address, zip code, or latitude/longitude coordinates stored in System i database files. You can even map locations from data stored in ORACLE, SQL Server, and other databases with the assistance of SEQUEL’s multiplatform database support.

Real-time vehicle tracking
A number of SEQUEL users in the transport industry already use this function to pinpoint the location of trucks equipped with GPS tracking systems. Depending on the available database information, SEQUEL could show a dispatcher the type of cargo the truck carries, whether it has available space, or the overall status of the shipment. In addition, they could run a SEQUEL request to drill-down into detailed database information, such as a bill of lading.

Other industries
The possibilities with the SEQUEL mapping capabilities are endless. Companies in other industries could use this function to quickly identify product or equipment installations within a region or across the country.

Working example
To illustrate how the mapping function works, we’ve created an example using a public-domain database from the U.S. Geological Survey (USGS) that shows locations of stream flow monitoring stations across the nation. Among other information, the USGS database contains latitude and longitude coordinates for each station. This database was downloaded from a USGS Web site and saved as a physical file on the System i.

You can initiate run-time prompts within SEQUEL ViewPoint, a SEQUEL executive dashboard, or from a Web browser using the SEQUEL Web Interface. SEQUEL lets you define as many prompts as you need to filter the data according to your own unique requirements. Therefore, you can select data for different product lines, vehicle types, or any other category or segment.

After you click the OK button to submit the request, SEQUEL converts the zip code or city name location into latitude and longitude coordinates to define the centering location. Then, using this location, SEQUEL performs a distance calculation to identify all the stations within the specified range.

For each selected station, SEQUEL reformats the System i database information into an XML output file according to the requirements of the Google maps API. This XML file is served along with a predefined HTML page and the results display in a browser window.

When you click on a location, a pop-up balloon displays detailed information extracted from the System i database.

You can also define hyperlinks to run SEQUEL Web Interface requests or to direct you to documents on a local server.

If you’re already a SEQUEL customer and would like to implement a mapping solution, download the Help/FACTS with a technical how-to approach.