Message groups are used in Robot/CONSOLE as a way to group messages into logical categories based on the source of the message. You can use message groups to separate certain messages from normal system messages. For example, you might create a message group to group messages by specific applications, by programming groups, or by company department.

By grouping messages, you easily can redirect a message based on where it came from without having to create a message set to process the message.

You determine the types of messages that should be separated into message groups and the grouping criteria to use. You then define each message group and its selection criteria.

When a message arrives on a message queue monitored by Robot/CONSOLE, the message groups are checked in the priority order specified. If a match to a message group’s selection criteria is found, the message group is assigned to the message. Note: Only one message group can be assigned to a message.

How to create and use a message group
In this example, all EDI message failures are captured and directed to the local expert, Jean, without creating or using a message set.

1. Before creating the EDI message group, you must create an EDI message center. From the Robot/CONSOLE Main Menu, select option 6, System Setup Menu. When the System Setup Menu displays, select option 1, Message Center Maintenance. When the Message Center Maintenance panel displays, press function key 6, Add Record, to create a new center.
   
2. When the Message Center Entry panel displays, create the new message center. In this example, Jean is the expert in the EDICENTER Message Center. When Robot/CONSOLE receives an EDI error, it displays a pop-up window to advise her of the problem that needs attention. If Jean does not respond to the pop-up window after one minute, the error is redirected to the broadcast list, DALELIST. DALELIST sends pager or e-mail messages to Jean and several of her co-workers (via Robot/ALERT) until the error is answered or the end of the list is reached.
3. Create the EDIGRP message group. Go to the Maintain Message Groups panel and press function key 6 to create a new group. Name the group EDIGRP and give it a message priority, such as 25. Add a description and redirect failure messages directly to the local Message Center, EDICENTER. Press Enter to create the new group.
   
4. When the Maintain Message Groups panel displays, enter option 2, Message Group Detail, next to the new EDIGRP message group.
   
5. When the Message Group Detail panel displays, add the Message File and Library information. This creates a filter so that the message group will pick up only EDI errors.
   
6. Activate the message group.

You have created a process that will capture EDI failure messages and direct them to the local EDI expert without needing a message set.

Message groups are a powerful feature of Robot/CONSOLE. If you haven’t tried them, we hope this article helps you think about ways you could start using them!

Contributed by Bill Broeckert, Technical Consultant

In 2008, U.S. Daylight Saving Time begins on March 9 and ends on November 2. Whether you change the time manually or have the system change the time automatically, the most important thing to keep in mind is that Robot/SCHEDULE must be inactive when the time change is made.

Two ways to set up the time change
Basically, there are two ways to accomplish the time change in Robot/SCHEDULE.

1. Create a CL program to end Robot/SCHEDULE, change the time, and restart Robot/SCHEDULE. (You can set up a Robot/SCHEDULE job to call this program.) This approach is explained in the Help/FACTS “Using Robot/SCHEDULE to automate Daylight Saving Time change.”

Note: You can modify the program to restart additional products so they pick up the time change. Products that benefit from this include: Robot/ALERT, Robot/AUTOTUNE, Robot/CLIENT, Robot/CONSOLE, Robot/MONITOR, Robot/NETWORK, and Robot/REPORTS.

2. Use the QTIMZON system value to make the change. With this approach, you need to create two Robot/SCHEDULE jobs to make Robot/SCHEDULE inactive during the time change. Download the Help/FACTS “Using Robot/SCHEDULE with the QTIMZON System Value” to get the details.

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

* i5/OS V5R4M0: PTFs SI26040 and SI25990

* i5/OS V5R3M0: PTFs SI26039 and SI25991

There are no changes for the QTIMZON system value in V6R1M0.

If your system uses a Hardware Management Console (HMC), you might need to apply additional fixes.

Unless specifically mentioned above, other Robot products are not affected by the time change. In addition, SEQUEL, ABSTRACT, ESEND, and EASY VIEW are not affected by the time change.

Contributed by Jeanne Thiesfeld, Technical Consultant

Send jobs Host-to-Host or Node-to-Node with Robot/NETWORK 10.0

If you haven’t discovered Robot/NETWORK packets, you are in for a treat. You can use Robot/NETWORK packets to centrally control and maintain:

* Robot/SCHEDULE job setups

* Robot/CONSOLE message sets, message tables, and message groups

* Robot/REPORTS report sets

Once you start using packets, you no longer have to sign on to multiple systems and create the same objects over and over. Not only do packets save you time, but they also reduce errors caused by repetition. You create an object once and use it many times.

Creating Robot/SCHEDULE packets
To access Robot/SCHEDULE packets, go into Robot/NETWORK 10.0 and click Product Master. Then, right-click Robot/SCHEDULE and select Explore. When the Robot/SCHEDULE 10.0 Explorer (graphical user interface) displays, you can create Robot/SCHEDULE jobs and other objects, such as date objects and OPAL objects, that you may need to complete your job setup. Use the same steps you would use if you were creating the job or object in a production Robot/SCHEDULE environment. Then you can send these jobs to remote Nodes. (Or, if you have a multi-Host environment, you can send these jobs to another Host’s Product Master.)

Note: Jobs or objects created in the Product Master library of Robot/SCHEDULE are not actually in production in the job setup of any system until you send them to a system.

Changing a packet that has been sent
If you send a job or object using packets and need to make changes to it, go into the Robot/SCHEDULE Product Master, make the changes, and send them. You can send the changes to all systems, or a selected group of systems. And, you can restrict the objects that will be sent with the job. For example, if you made changes to the environment only, you can avoid sending other objects that are attached to the job.

You can use the Product Master to remove or reverse changes you have made to jobs using a packet. If you move a change into production from the Product Master and it doesn’t work as expected, simply reverse that packet. Reversing a packet removes the changes made by that packet and returns the job to the way it was before the packet was applied. You even can delete a job created by a packet.

Sending an active job to the Product Master
Perhaps you have a production job set up on one system that you want to share with many systems. Use the command RBTNETNODE/RBNSNDRBT to send the job to the Robot/SCHEDULE Product Master. Once the job is in the Product Master, you can distribute it to as many systems as needed. In the future, you can make changes to it and distribute the changes to various sites.

Reviewing packet activity
When you send a packet from the Product Master, Robot/NETWORK keeps a record of the event. You can view this history online, or run the Packet History Report to see what objects have been sent from the Host to remote Nodes.

Sending jobs Node-to-Node
Using the Robot/SCHEDULE Explorer on the Robot/NETWORK Host, you also can send jobs Node-to-Node. When you right-click on a job on a Node system, a menu displays. When you select SEND, the job is sent directly to another Node system.

Note: When you send a job Node-to-Node, you bypass the Product Master and its benefits (such as the ability to share the job with other systems and the ability to maintain the job from a central site). Jobs sent Node-to-Node do not show up in the Packet History Report.

Working with green screen products
For green screen Robot products, such as Robot/REPORTS and Robot/CONSOLE, you create and send packets using the Robot/NETWORK 10 Product Master menu option on the Host system. From this option, you can create the Robot/CONSOLE and Robot/REPORTS objects you need to set up these products.

As with Robot/SCHEDULE, you create the object just as if you were in the actual product and distribute it to the remote Nodes from the Product Master. If your Report Set or Message Set contains OPAL, the remote system automatically compiles the code when the packet is applied.

Unlike working with Robot/SCHEDULE, you cannot send Robot/CONSOLE or Robot/REPORTS packets Host-to-Host or Node-to-Node. Distribution is limited to sending packets from the Robot/NETWORK Host to its attached Nodes.

You can send existing Message Sets and Report Sets from a remote system to the Product Master. For Robot/REPORTS, use the command RBTNETNODE/RBNSNDREP, and for Robot/CONSOLE use the command RBTNETNODE/RBNSNDRBC. These commands put the objects in the appropriate Product Master and let you change and distribute them to multiple systems.

Summary
Once you discover how easy it is to use packets, you’ll wonder why you haven’t been using them all along! Packets are a great way to maintain multiple products across multiple systems from a central site. And, with Robot/NETWORK’s security system, you can control access to the Product Master. You can limit access to a single user or a group of users who are allowed to create packets.

Contributed by Terri Preston, Technical Consultant

Robot/CONSOLE has important resource and log monitoring features

In addition to message management, Robot/CONSOLE has important resource and log monitoring features that let you monitor jobs, job queues, subsystems, FTP requests, QHST messages, security audit log changes, and more. Based on this monitoring, Robot/CONSOLE can notify you or generate reports. This article explains how to use these special monitoring features.

Resource Monitoring
Robot/CONSOLE can check the status of your critical resources regularly. The RBCRSCMON monitor job runs in the RBTSLEEPER subsystem and automatically checks the status of resources that you set up using the Resource Maintenance panel. When it finds a resource that is NOT in the expected status, it sends a message to a virtual message queue, RBCRSCQ. Using Robot/CONSOLE, you can monitor the following resources:

• Controllers

• Device Descriptions

• Domino Servers

• FTP Servers

• HTTP Servers

• Jobs

• Job Queues

• Line Descriptions

• TCP/IP Servers

• Network Servers

• Objects

• Output Queues

• TCP/IP Ports

• Subsystems

• Servers

• System CPU %

• Network Interfaces

You specify the expected status of the resource and how often Robot/CONSOLE should check. Figure 1 shows an example of how you might set up monitoring for a job queue depth over 10. If the resource monitor job (RBCRSCMON) checks the status and finds more than 10 jobs in the job queue, it sends a message (message ID JBQ0003) to the virtual message queue (RBCRSCQ). You also need a message set to handle the message. Your message set can send a pop-up message, page you using Robot/ALERT, or take some other action by using OPerator Assistance Language (OPAL) code.

Log Monitoring
Robot/CONSOLE provides three types of log monitors: FTP, QHST, and Security Audit Journal.

1. FTP requests. This monitor looks for FTP requests from other systems. A special monitor job (RBCLOGFTP) monitors these events and sends a message to the virtual message queue (RBCLOGFTP). Robot/CONSOLE records the request, who made the request, and when the request was made. Robot/CONSOLE monitors for the following FTP requests: delete file, send file, receive file, rename file, and execute command.

2. System history log (QHST). Turn this monitor on to monitor messages sent to the system history log (QHST). A monitor job (RBCLOGHST) logs QHST messages to a virtual message queue (RBCLOGHST). To avoid message overload, set up a message set and message table to unconditionally suppress frequently occurring informational messages. To determine which messages to include in the message table, run the “Summarize QHST Messages” report (Figure 2). You can run this report from a command line using the following command:

RBTCONLIB/RBCSUMQHST

3. The Security Audit Journal. To monitor security audit journal entries, turn on the Security Audit Log. A monitor job (RBCLOGAUD) converts System i security audit journal entries into message IDs and sends them to a virtual message queue (RBCLOGAUD). You can capture any or all of the following QAUDLVL security audit journal entries: *SECURITY (changes in system values or user profiles), *AUTFAIL (failed sign-on attempts or access to objects), *SERVICE (catches attempts to sidestep security using Service Tools or APIs), and *SYSMGT (changes to system reply list entries, operational assistant functions, and so forth).

You turn log monitors on using the Log Monitoring Setup panel (Figure 3).

Reporting
All log and resource monitoring messages are recorded so you can print history reports quickly for SOX auditors. For example, to print all messages relating to FTP requests, run the Message History List report from the History Reports menu and specify the “Originating Center” as RBCLOGFTP. You can do the same for resource monitor messages (RBCRSCQ), security audit log messages (RBCLOGAUD), and QHST messages (RBCLOGHST).

Contributed by Jenny Dischinger, Technical Consultant

Year in and year out, the Robot products earn their keep

Rugged climbs up soaring mountains. Peaceful hikes through quiet woods. Gliding gently over lakes and rivers. If your plans include the outdoors, REI has everything you’ll need to make your adventure a success. And, when REI wanted to make sure their computer operations could keep up with their business responsibilities, they turned to Help/Systems and the Robot products.

REI (Recreational Equipment Incorporated) was founded as a cooperative in 1938 to sell outdoor gear and clothing to members. Members pay $15.00 for a lifetime membership and receive a dividend each year on their purchases.

Today, REI operates more than 80 stores throughout the U.S., and has a thriving online and direct sales business. “We’ve been around a long time, and we have a lot of satisfied customers and members,” says Rod Williams, IS Manager for Service Assurance, at REI headquarters in Kent, Washington, a suburb of Seattle.

REI began using the IBM AS/400 as its business computer in the late 1980s, when it was first introduced. Since then, they’ve acquired several more iSeries and System i systems. Most are located at the Kent location.

One System i is located at REI’s distribution center, a few miles away in Sumner. The company first began using the Robot products when they purchased this system for the distribution center.

Automation journey began with a job scheduler
“We were opening the new distribution center in about 1990 and needed to purchase a scheduler to run a set of batch jobs. We looked at a couple of different products and chose the Help/Systems products,” says Rod. “Prior to that time, we were primarily a mainframe shop. This was our first foray into automation products for the System i.”

Today, the company uses Robot/CONSOLE for message management, Robot/SCHEDULE for job scheduling, and Robot/SAVE, for backup and recovery.

Says Rod, “We found these products very easy to install and set up. Especially in the case of the distribution center. We were able to do the things we wanted to straightforwardly and simply with the Robot/SCHEDULE package. Fifteen years later, the applications have changed, but we still have a lights-out data center and we rely on Help/Systems products to maintain that.

Another big payback came from Robot/CONSOLE
“The other big savings came when we put Robot/CONSOLE in our Kent data center, which is staffed 24 hours a day. We really didn’t have a message management system, so operators were constantly having to answer inquiry messages. Robot/CONSOLE allowed us to manage that. Our operators were doing things that the software does better and it frees them to do other things.”

REI automated their message processing by creating message sets. For example, they created device failure messages that break to the operator and let them know when there’s a problem. Says Rod, “We had a problem with a credit authorization that was going to another company. As part of troubleshooting that problem, we created some message sets to monitor for those messages, and now we’re alerted (to problems) much sooner.”

Other messages are suppressed so operators never have to see them. Adds Rod, “We’ve written some in-house programs for different applications so that they create a unique message and we monitor for that message ID. Then, we give the operator specific instructions on what to do, or just automate a recovery action.”

Flexible implementation for each system
REI runs the same message sets on different systems whenever it’s appropriate to do so. Other message sets are unique to each system based on the applications they run.

As Rod explains, “We have nine operators staffing the data center 24/7. Not all came to REI with extensive System i experience. But no matter their level of experience, they can monitor messages through Robot/CONSOLE. The night operators are monitoring the batch schedule, looking for errors, and watching the timeliness of the schedule to meet our service level agreements with REI customers.”

The future ties into enterprise monitoring
Currently, REI’s systems are independent of each other, but each system has Robot/CONSOLE installed. Adds Rod, “The next step in monitoring and message management is to integrate Robot/CONSOLE messages and automation into enterprise monitoring systems. Our aim is to monitor for the availability of business services, the way the customer sees them, not the way IT sees them.

“We haven’t had the resources to really fully explore these products. There’s a lot of other things we could be doing if we had more resources.”

Rod sums it up, “It’s never been a goal to eliminate staff through automation. Instead, it’s the challenge of absorbing the work and responsibility that results from business growth. It would just be a lot more difficult, and I probably wouldn’t sleep as well.

“These products have helped us achieve our business goals, beginning in 1991 with a new data center in a new REI distribution center. They continue to be an important part of our business strategy and achievement of goals.”

by Kiki Koras, Technical Writer

We are interested in backing up report set definitions. If our primary server fails, we can reinstall Robot/REPORTS and restore the files we need to get started. What files in what libraries should we back up to restore in case of a disaster?
For disaster recovery purposes, back up the RBTREPLIB library. This library holds all of the setup information for Robot/REPORTS. If you are using disk for short-term archiving, you also should back up the REPSHTRMLB library. This library contains the short-term data. In a disaster recovery situation, you want to have this library so you can restore the reports that had gone to the short-term archive.

I want to move Robot/ALERT from one System i to another. Is there a way to save/export the current Robot/ALERT configuration, pager information, broadcast lists, and so on to the new system?
Yes, this is easy to do. End Robot/ALERT on the old system and save the RBTALRLIB library. Then, restore RBTALRLIB to the new system. You must delete and re-create the communication jobs on the new system.

In Robot/CONSOLE, what is the difference between running the command RBCCLNUP and running the history-purge program RBC596?
The RBC596 program cleans up Robot/CONSOLE history based on the age of a message and its severity level. It removes messages from monitored message queues.

The RBCCLNUP command cleans up dangling data queues left by users who do not run the RBCENDQ command.

How can I make sure Robot/SAVE regularly releases tapes to my scratch pool?
To release tapes to the scratch pool regularly, schedule the following command in Robot/SCHEDULE:
RBSPGMLIB/RBSRLSEXTP

How can I check to see if one or all my clients are running and ready to receive tasks from the System i?
You can poll each registered client using the Robot/CLIENT RCLPOLL command. The command determines if the Robot/CLIENT task processor is running and if the client is ready to receive tasks. The RCLPOLL command allows you to check the status of all attached clients at once or to enter up to 50 names of individual clients.

You can view the operational status of the clients on the Client Control Center panel.

To use the command interactively, enter it on a command line and press function key 4 to display the command prompt panel.

You also can schedule the command in Robot/SCHEDULE to poll each client on a regular schedule (such as hourly) or you can embed the command in a program.

How do I purge completed tasks in Robot/CLIENT?
The RCLCLEANUP command deletes completed tasks. You must specify the number of days of completed tasks you want to keep. The best way to keep completed tasks cleaned up is to set up a Robot/SCHEDULE job to run the RCLCLEANUP command to purge completed tasks on a regular basis.

Teach Robot/CONSOLE and Robot/ALERT how to handle messages

If you are a new user of Robot/CONSOLE and Robot/ALERT, you may be wondering how to get started. After you’ve installed the products, what’s next?

Typically, new users want to start by creating a Robot/CONSOLE message center to monitor the QSYSOPR message queue. To do this, we recommend you use Robot/GUIDE, the automated setup option. (Refer to the Robot/CONSOLE Getting Started manual for complete information on using Robot/GUIDE.)

Robot/GUIDE creates two operator message centers for the QSYSOPR message queue, creates message sets for messages to be suppressed or messages that can be answered with the same reply every time, and allows you to set up log and resource monitoring. You can have Robot/CONSOLE handling your messages and monitoring your system logs and resources in minutes.

Note: If you didn’t run the RBCCRTMFD command during installation, you must run it before starting Robot/GUIDE. This command creates the message file definitions Robot/CONSOLE needs to create message sets. Robot/GUIDE requires the same security authorities as those used to install Robot/CONSOLE.

For Robot/ALERT, the first thing you must decide is how you will be sending notifications from the System i—by modem or by using TCP/IP. If you plan to use a modem, you need specific information about setting up the modem from your cell phone or pager service provider. If you plan to use TCP/IP, you need to know the domain name and IP address of the e-mail server you will use to send messages to the e-mail address associated with your pager or cell phone. (Refer to the Robot/ALERT 5.0 User Guide’s TCP/IP Paging Services questionnaire for more information.)

After you set up Robot/ALERT and send and receive a test message, go back to the QSYSOPR message center and tell Robot/CONSOLE to notify you of response-required messages. Robot/CONSOLE can notify you via a pop-up window on a System i session (if you are logged on). Or, you can associate a Robot/ALERT device (pager, cell phone, or other e-mail address) with your message center and receive unanswered messages via Robot/ALERT. You can specify how long Robot/CONSOLE should wait to notify you. This allows you to track QSYSOPR messages without being tied to a monitor.

If you are using Robot/ALERT, it is a good idea to have it page you for all response-required messages initially. This allows you to note the message IDs you want to handle differently. Then, create message sets for those message IDs. In addition, if an unexpected critical message comes through, you won’t miss it!

Using the Most Common Messages report
Robot/CONSOLE also provides another useful tool, The Most Common Messages Report. Use this report to identify which messages occur most frequently on any message queue that you monitor. To analyze the report:

• Look for messages that can be answered the same way each time and create a message set to accomplish this.
• Look for messages that don’t require immediate attention. Create a message set to redirect these messages to a message center that doesn’t notify you, or send messages using Robot/ALERT.
• Look for messages that require a response, but aren’t urgent. Create a message table for these. Then, create a new message center. You could set up this message center to use Robot/ALERT to send messages to an e-mail address that is monitored periodically. Finally, create a message set, selecting Message Table for the message set type. Press function key 10 until the OPerator Assistance Language panel displays. Specify the operation REDIRECT and enter the new message center in the Operation Values field to complete the setup.

Populating message tables automatically
Robot/CONSOLE can help you populate your message tables.

1. Display the Message Table Elements panel and press function key 6 (Add Query).
2. Enter a search term.
3. Robot/CONSOLE will populate the table with all the message IDs that contain your search term.

Review this list and add or delete message IDs to tailor it for your environment. For example, use this approach to create a table of all printer messages.

If you don’t want to see certain messages, use Robot/CONSOLE to suppress them. If you ran Robot/GUIDE, you already have a message set and message table called MSTSUPPRES. This table contains message IDs for informational messages that users typically do not need to see. Once you are satisfied that this table contains the message IDs you want to suppress, activate the MSTSUPPRES message set.

Setting up two-way messaging
If your want to answer messages from your pager, cell phone, PDA, or another e-mail address that can send a reply to the e-mail from Robot/ALERT, set up Robot/ALERT for two-way messaging. You need a POP3 mail account on your e-mail server (or on another e-mail server, such as one at your ISP). You also need to know the POP3 server’s domain name and IP address, and information about the POP3 account: login ID, password, and e-mail address.

Go to the Robot/ALERT Directory menu and select Option 1 (Vendor Maintenance Menu). On the Vendor Maintenance Menu, select Option 1. Create your vendor using Robot/GUIDE. On the Robot/GUIDE Automated Vendor Setup panels, make sure you:

1. Give your vendor a unique name. (Don’t delete existing vendors or your devices will be deleted.)
2. Select TCP/IP (1) for Connection Type.
3. Select two-way (2) for Service Type.
4. Select SMTPPOP3.
5. Enter the information for the outbound e-mail server
6. Enter the information for the inbound server.
7. After the vendor is created, enter a 1 to create a device.

Verify that you can send a message and receive a response. Then, you can begin using this new device on your Robot/CONSOLE message centers. When you respond to a message, Robot/ALERT recognizes the reply in the POP3 account and gives it to Robot/CONSOLE. You’ve answered the message without having to dial in!

Contributed by Theresa Aleckson, Technical Consultant

Although SEQUEL executive dashboards are most commonly used to track business indicators, they also can display operations data to help you streamline and improve your System i operations. In fact, a SEQUEL executive dashboard could be a crucial tool if you must comply with Service Level Agreements (SLAs). This article describes how key performance indicators stored in the database files the Robot products maintain can be incorporated into SEQUEL executive dashboards.

Manage job schedules and batch jobs
The sample Robot/SCHEDULE dashboard (below) displays metrics to help you evaluate job scheduling and batch management. It can help you answer many interesting operations questions.

* How automated are the batch jobs on my system? The pie chart (1) and a corresponding list (2) show how many batch jobs are submitted by users compared to how many batch jobs are submitted by Robot/SCHEDULE. You can use this information to judge your progress on automating batch job management. You can drill-down from either of these objects to see which users are submitting their own jobs.

* Are my Robot/SCHEDULE jobs completing successfully? Table 3 and pie chart 4 give you information about the completion status of Robot/SCHEDULE jobs, including normal completion (Complete), abnormal end (Terminated), setup errors (Error Setup), warnings (Warning), and jobs that were skipped because of OPAL programs attached to the job (Skip OPAL).

* What’s happening with my long-running jobs? Jobs with an average run duration of more than 30 minutes are summarized in table 5. This table averages job runs over the past 30 days.

* Have there been any warning events in the last week? Table 6 summarizes warning events over the last seven days, with information on job name, number of events, and message text. A date object or a calendar that is expiring would display.

* How are my jobs set up? Table 7 and graph 8 break out jobs by types including jobs that are on hold, group jobs, reactive jobs, and other (primarily jobs scheduled by date and time). This information gives you an idea of the overall makeup of your schedule. In general, a schedule with a higher percentage of group and reactive jobs is more automated.

Track important message statistics
The Robot/CONSOLE dashboard (below) summarizes a variety of message statistics.

* What volume of messages does the QSYSOPR message queue handle? Table 1 and graph 2 show the number of messages QSYSOPR receives each day.

* How many messages do other monitored queues receive? Table 3 displays a count of messages for each monitored queue. If a queue has an extremely high number of messages, it may indicate a problem. You can drill down into the data to determine the root of the problem.

* What is the message count by message severity? Graph 4 displays summary totals for each message severity level on the QSYSOPR message queue.

* What are the most common message IDs on my system? Are these automated? The Message ID Count summary table (5) shows how many times each message ID was received, along with message text. Messages with a blank message set field indicate common message IDs that have not been set up in Robot/CONSOLE and present automation opportunities.

* How quickly are messages being answered? The Average Response Time summary (6) shows the average response time for the first shift. If it is above the acceptable limit, you should take corrective action.

Design your own Robot dashboards
These are just a few examples of how you can use SEQUEL to create operations dashboards. There are many other possibilities. For example, you could create a different Robot/CONSOLE operations dashboard to identify security errors and resource issues. Or, you might create a Robot/SAVE dashboard to monitor your backup operations.

Dashboards can include almost any imaginable statistic and formatting. They’re easy to customize according to your needs. If you have

SEQUEL and at least one Robot product, you can start tracking your operations metrics right away. Contact SEQUEL Technical Support at 952-933-0609 to request a save file that contains the SEQUEL objects shown in this article.

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