iSeries (AS400) monitoring reference guide
search cancel

iSeries (AS400) monitoring reference guide

book

Article ID: 198850

calendar_today

Updated On: 07-15-2024

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

One of our clients is requesting iSeries (AS400) Nimsoft (CA UIM) robot monitoring. We are Ok with all parameters shared by them which need to be placed into monitoring except the items listed below. Please confirm if these AS400 parameters can be monitored or not in DX UIM (Nimsoft). If monitored, could you please let us know how to do it?

1) transaction response time  --> For example, when user runs a command monitor the response time

2) Total number of jobs  --> For example, if total number of Jobs are greater than 183000

Environment

  • Release: UIM 20.4 or higher
  • Component: UIM JOBS

Cause

  • Guidance
  • Info request

Resolution

1) transaction response time  --> For eg: When user runs a command then response time.

iSeries / AS/400 performance tools can monitor this but I don't see any way of achieving the same exact metrics with iSeries probes we currently support.

Check the monitoring results for the job's interactive response time and compare it to what is expected.

2) Total number of jobs  --> For e.g., : if total number of Jobs are greater than 183000

Possibly the history and jobs probe:

Jobs Metrics

Total number of jobs appears to be possible via AS400 command line:

Using Qshell (QSH) to Find How Many Jobs Are Running On A System
https://www.ibm.com/support/pages/using-qshell-qsh-find-how-many-jobs-are-running-system 

iSeries versions supported:

 - V5R3
 - V5R4
 - V6R1
 - V7R1
 - V7R2
 - V7R3 

All of the AS400 / iSeries probes are listed below.

Check the probe matrix for specific version compatibility.

The DX UIM Probe Support Matrix spreadsheet can be downloaded from here:
Platform support Availability

AS400/iSeries probes


- fetchmsg
The Fetch System Messages on iSeries (fetchmsg) probe monitors message queues on IBM iSeries systems. The probe sets up a message space and retrieves messages from specified queues to monitor them. The probe can generate alarms when the specified threshold conditions are breached. For example, you can generate alarm messages when specific messages appear. You can also check messages which require an answer for missing responses.

- history
The history (iSeries QHST Data Monitoring) probe monitors history messages from the QHST logs. The logs contain messages related to system failure, warning messages, security issues, and so on. The logs are present on the same iSeries servers that host the probe. The probe only reads the QHST log files, and automatically detects new logs and new messages as they are written to the log files.  The log contains the history of the system activities that are as follows:
Status of the system, ***Jobs running on the system,*** and System operated messages.

- jobs
The iSeries Job Monitoring (jobs) probe helps you monitor all the jobs running on the IBM iSeries system. The jobs are identified through parameters such as name, type, subtype, subsystem, and queue name. You can monitor if any given job is slowing down the system or is consuming valuable system resources that a high-priority job requires for its execution. That is, you can monitor whether the job utilizes system resources such as CPU usage, processing units, and memory units than that is expected. The probe allows you to create and configure profiles for monitoring these jobs. You can also generate alarm messages when any given job has failed to execute as planned. For example, you can generate alarm messages for jobs that are running, not running or appearing in a specific number of instances in the system. The probe also supports the generation of quality of service (QoS) messages that are used for identifying the performance issues occurred while executing the jobs. This helps you drill down to the cause that triggered the issue and take preventive measures by scheduling the execution of jobs in such a way that the system resources are utilized efficiently. 

- sysstat
The sysstat probe monitors the iSeries  systems statistics. Alarm messages can be generated on current variable values. Quality of Service messages directed towards the Nimsoft SLA (Service Level Agreement) family can be generated on all variables.

- diskstat
The iSeries Disk Monitoring (diskstat) probe monitors disks that are assigned to an Auxiliary Storage Pool (ASP) on IBM iSeries systems. The probe identifies disks through disk properties such as ASP number, Disk Type and, Disk Unit Number. The probe enables you to monitor disk performance and track disk activities such as disk usage, disk capacity, and the number of read and writes completed per second.

- jobqs
The jobqs probe monitors job queues in the iSeries system. Alarm messages can be generated when specific job queues are running, not running or appear in a specific number of instances. The probe also supports QoS (Quality of Service) messages, directed towards the Nimsoft SLA (Service Level Agreement) family.

- jobsched
The iSeries Job Schedule Monitoring probe monitors the scheduled jobs on IBM iSeries systems. The jobsched probe generates alarms and quality of service (QoS) messages for the scheduled jobs in the following cases: 
Unexpected status of the jobs, Failed scheduled jobs, or Runtime of the scheduled jobs. The probe also generates information about the scheduled jobs such as job name, job queue status, job creation date and job description.

- journal
The iSeries Journal Message Monitoring (journal) probe monitors the journal messages and journal files on the IBM iSeries system hosting the probe. The probe allows you to configure specific journals for monitoring. The probe can generate alarms when the specified threshold conditions are breached. For example, you can generate alarm messages when specific messages appear.The Audit Journal (QAUDJRN in the QSYS library) is an example of a journal file monitored by the probe.

- outqs
Output queues are objects defined in the IBM iSeries system to contain the spooled files or printer output files that are queued for printing. Output queues are created by a user or by the system.  Spooled files are created from the application program, from a system program, or by pressing the Print key from your keyboard. The iSeries Output Queue Monitoring (outqs) probe uses profiles to monitor output queues in the IBM iSeries systems. You can create and activate profiles to monitor the number of spooled files present in an output queue. When you configure a profile, you can set a threshold value to generate an alarm or QoS message. The probe generates alarms or QoS messages when the total number of files in an output queue outnumbers or equals the threshold value specified in the profile. The probe scans all the output queues in the system against the profile. This ensures you that the system is not overloaded with continuous print requests. 

Other probes


- logmon
The Logfile Monitoring (logmon) probe scans ASCII-based logfiles and automatically looks for the essential information in system and application logfiles. The probe monitors the following items:
 
Log files: The files are monitored at defined time intervals for new entries.
 
Content of HTML web pages: You can use the URL Endpoint Response Monitoring (url_response) probe with the logmon probe to monitor the text in a web page.
 
Text output after executing specified commands For example, you can execute the following command to generate alarms when the packet loss is more than 50 percent: ping <IP Address>
 
Text Messages in CA UIM queues
Example: you can define a custom queue, such as Queue1, on a CA UIM hub. The queue is configured to read all messages where the message subject is SMS-IN. You can specify the queue name in the monitoring profile to scan messages in the Queue1 queue. You can then generate alarms on identifying any unexpected text.

Files: EBCDIC files (on AS400/iSeries) and ASCII-based system and application log files (on other platforms)
The probe searches the specified targets and matches text against string patterns or regular expressions. The probe generates alarms when the log file content matches the defined expression.

- dirscan
The File and Directory Scan (dirscan) probe monitors files in specified directories. Alarms can be sent on the number, age, and space that is used by files. This probe monitors files and directories for the following:

   - Existence of directories

   - Shared directories (Windows systems only)

   - Named files or file patterns in a directory (option to include subdirectories)

The probe is configured by defining one or more profiles. Each profile identifies a particular directory and the required files. You can configure different parameters that can be checked. All the following parameters can generate alarm messages if the specified threshold is breached:

Number of files
The number of files that are found in the specified directory matching the specified pattern.

Age of file
The age of the files that are found in the specified directory matching the specified pattern.

Space that is used by files
The space that is used by all files that are found in the specified directory matching the specified pattern.

Size of files
The size of the files that are found in the specified directory matching the specified pattern.

Read response time
The time that is required to read the specified file.

Directory check
Verifies if the specified directory is present.

Directory age
The time that has passed from the previous change in the directory.

File integrity
Verifies if the files that are specified for file integrity monitoring have changed

Additional Information

iSeries / AS/400 performance TOOLS can monitor transaction response time. 

That stated, IF some useful-related information is actually logged by the iSeries system on the total number of jobs, or transaction response time for user-run commands, you can try using logmon to parse it in the log, and generate QOS/Alarms.