Help/Systems - System I Automated Operation & Business IntelligenceRobots
Google Search

Help/Systems www

Archive for August, 2007

Beyond message queue monitoring

Wednesday, August 22nd, 2007

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.

Figure 1

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

Figure 2

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).

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

Use ABSTRACT to build a cross-reference table

Wednesday, August 22nd, 2007

Have you ever wondered how program changes will impact your application or your job schedule? Are you involved in maintaining your batch environment? Does your job schedule documentation need an overhaul? If you answered “yes” to any of these questions, perhaps it’s time for you to take a look at ABSTRACT, Help/Systems’ programming and analysis tool set for the System i.

What is ABSTRACT?
ABSTRACT is a tool set that allows you to build a “where-used” database that tracks object relationships and other valuable information regarding files, fields, and how they are updated. If you write “home-grown” applications or are responsible for maintaining other people’s code, you can use ABSTRACT to create the documentation you need to manage your environment as efficiently as possible.

Once you have installed ABSTRACT on the System i, select an interface to use. You can install the iSeries Navigator plug-in, the WDSc plug-in, or work directly from a 5250 command line. Next, select the library (or libraries) you want to load into the ABSTRACT cross-reference repository. Once this information is loaded, you can view where-used and used-by relationships.

An example of a “where used” cross-reference

The object reference options give you a top-down view of your application. The where-used options display your fields or objects from a bottom-up perspective. The LOADXREF command captures information about your application’s programs, files, and other types of objects, such as menus, SEQUEL views, queries, or job schedule entries.

Simplify your development tasks
Once you build your cross-reference, you can use this information to pinpoint how critical changes will affect your application, determine where changes need to be made, automatically re-create all objects affected by physical file record layout changes, or generate a graphical flowchart for documentation purposes.

ABSTRACT also simplifies file analysis. ABSTRACT provides information about your database, display and printer files (including external and internal file layouts), and database and member definitions. ABSTRACT can create exception reports to pinpoint potential problems with your applications or ABSTRACT cross-reference data. You can search source and message files using the Find String option.

Interface with Robot/SCHEDULE
You can load your Robot/SCHEDULE batch environment into your cross-reference repository. Use the command LOADJOBSCD to load your Robot/SCHEDULE jobs from ROBOTLIB into ABSTRACT.

When your batch environment is loaded, you can work with objects referenced by your jobs. For each scheduled job, all programs and commands that are executed within the job are listed. In addition to the programs and commands, other object types, such as job descriptions, job queues, output queues, user profiles and message queues can be listed. If you need to change any of these types of objects, you can list which job(s) would be affected easily.

If you are using the iSeries Navigator or WDSc interface, you can create a flowchart (using ABSTRACT’s built-in flowcharting tool or Microsoft Visio) of objects used by a job or the program cross-reference data. Select the object, job, program, or file to chart and right-click to generate a flowchart.

An example of an MS Visio flowchart  for a Robot/SCHEDULE job.

Another option when working with an object such as a job description or job queue, is to display “where-used” information. This option is available in the traditional 5250 interface, the iSeries Navigator interface, and the WDSc interface.

Finally, if you prefer the WDSc interface, you will see the same information, plus you can review a source flowchart that will show you a visual representation of your program.

An example of the WDSc interface showing a visual representation of a program.

In summary
Whether your main responsibility is your job schedule or maintaining a complex application, take advantage of the power of ABSTRACT. Start using the cross-reference repository, file analysis, where-used, and flowcharting options to understand data relationships more fully and to work more efficiently in your environment.

Contributed by Jill Martin, Technical Services Manager

August Q&A Column

Wednesday, August 8th, 2007

I have a library on my system called HELPNETLIB. Do the Robot products use this library?
This library is no longer used by the Robot products. Here’s how to remove it:

  • Add the Help/NET library to your library list: ADDLIBLE HELPNETLIB
  • Start the cleanup process: CALL HLPCLEAN
      • Note: If Help/NET is at Release 2.31 (or higher), skip to step 5. Otherwise, continue with step 3.
  • Delete the routing table entry, distribution queue, and secondary names: CFGDSTSRV
  • When the menu displays:
      • Select option 3 to display the secondary names. Remove all eight entries that begin with NETCUST.
      • Select option 2 to display the routing table entry. Remove the entry that has HELPNET in it.
      • Select option 1 to display the distribution queue. Remove the entry that has HELPNET in it.
  • Delete the HELP/NET library: DLTLIB HELPNETLIB

The name of a data library changed. How do I change my SEQUEL views to use the new library name?
Here’s an easy way using the SEQUEL command DSPVIEWD.

  1. Create a source file that you can edit using these commands:
    CHGCMDDFT CMD(SEQUEL/CRTVIEW) NEWDFT(’replace(*yes)’)
    DSPVIEWD LIB/*ALL TYPE(*SRC) OUTPUT(*OUTFILE) OUTFILE(QTEMP/QXLSRC) OUTMBR(ALLVIEWS)

  2. Start the source edit utility: STRSEU QTEMP/QXLSRC ALLVIEWS

  3. Select option 2 (Edit) and press function key 14 (Find/Change) to change the old name to the new name.

  4. Compile and run the program. All the views will be re-created.

  5. Reset the CRTVIEW command to its default value: CHGCMDDFT CMD(SEQUEL/CRTVIEW) NEWDFT(’replace(*no)’)

Report Management: Add or delete recipients by command

Wednesday, August 8th, 2007

When you install Robot/REPORTS, it automatically populates its database of recipients with all the user profiles defined on your system. After that, you need to define new recipients (or delete recipients who leave) individually by working with the Recipient and the Recipient Bundling Options panels. Now, with Robot/REPORTS 7.30 (or higher), you also can add and delete recipients using commands!

When to use these commands
Many companies run a CL program to set up new employees on the System i. By using the new Add Recipient command (REPADDREC), you can add the new employee to Robot/REPORTS at the same time.

Similarly, when an employee leaves, companies often run a clean-up program to remove the user profile from the System i. Now they can add the Delete Recipient command (REPDLTREC) to the program to remove the employee record from the Robot/REPORTS database.

These commands also are useful when you need to add or delete a group of recipients, such as a special project team.

Using the REPADDREC command
The REPADDREC command includes much of the information you normally enter on the Recipient and Recipient Bundling Options panels. Here are some tips for entering the parameters:

  • The User Profile parameter can be *NONE if the user does not sign on to the System i and receives printed output only.
  • For local output on the System i, enter an output queue and library.
  • For remote output on a different System i, enter the remote system name and *YES for “Is system an iSeries” to preserve print attributes for the report.
  • If you print a packet index, Robot/REPORTS generates a cover page listing all the reports in the packet and page number information.
  • If you request page numbers, Robot/REPORTS numbers each page in the packet in the lower left-hand corner to make it easier to find reports in the packet. All of the pages in the packet have a report page number and a packet page number.
  • If you request separator pages, Robot/REPORTS inserts a blank separator page between each report in the packet.

Using the REPDLTREC command
The REPDLTREC command deletes a recipient from the Robot/REPORTS database. You can delete a recipient by entering the recipient name or the user profile. You must tell Robot/REPORTS what to do if the recipient is set up to receive a report segment. If you enter *YES to “Delete even if distribution exists,” Robot/REPORTS removes the recipient. If you enter *NO, Robot/REPORTS does not remove the recipient.

These new commands provide additional ways to work with Robot/REPORTS recipients. We hope you will find them useful.

Contributed by Marie Stangl, Maintenance Software Engineer

John Egan wins Magellan GPS sweepstakes

Friday, August 3rd, 2007

As part of the introduction of Robot/NETWORK 10, Help/Systems sent a mailing to selected customers describing the new release as “putting the entire world at your fingertips.” This mailer included the option to enter a sweepstakes to win a Magellan GPS system (another cool tech gadget that puts the world at your fingertips). Entrants had to read the mailing carefully and enter the correct answer on a special landing page on the Help/Systems Web site.

When the sweepstakes closed on July 25, all the entries with the correct answer were put in a hat. The winner is:
John J. Egan
Director, IT Operations

Our congratulations go out to John. When informed he had won, John commented “Great! Thank you. Now, ROBOT not only helps me at work, it helps me get to work.”

We thank everyone who entered the sweepstakes. And, in case you were wondering, the correct answer was SYDNEY.

Help/Systems 6533 Flying Cloud Drive,
Suite 200
Eden Prairie, MN 55344
Ph. (952) 933-0609
Fx. (952) 933-8153
Contact information
Map/Driving Directions
Privacy Policy

Free Email Sign-Up

To get the latest operations automation and business intelligence news, sign up for Robot Direct by entering your e-mail address. We'll let you know about site updates or breaking news about twice a month!

Email Marketing Email:(required)


Please select default option:
HTML Version
Text-Only Version
!
Try our software FREE for 30 days!