IBM I 7.1 System MGMT - Performance Ref Info
IBM I 7.1 System MGMT - Performance Ref Info
IBM I 7.1 System MGMT - Performance Ref Info
IBM i
Systems management
Performance reference information
7.1
IBM
IBM i
Systems management
Performance reference information
7.1
Note
Before using this information and the product it supports, read the information in “Notices,” on
page 267.
This edition applies to IBM i 7.1 (product number 5770-SS1) and to all subsequent releases and modifications until
otherwise indicated in new editions. This version does not run on all reduced instruction set computer (RISC)
models nor does it run on CISC models.
© Copyright IBM Corporation 1998, 2010.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Reference information for Performance 1 Disk Watcher data files: QAPYDWSTAT . . . 237
Collection Services data files . . . . . . . . . 1 Disk Watcher data files: QAPYDWTDER . . . 239
Collection Services data files containing time Disk Watcher data files: QAPYDWTRC . . . . 240
interval data . . . . . . . . . . . . . 1 Data files: File abbreviations . . . . . . . . 244
Collection Services data files: Field data for CL commands for performance . . . . . . . 244
configuration database files. . . . . . . . 221 Intelligent Agents . . . . . . . . . . . . 247
Collection Services database files: Field data for Intelligent Agent concepts . . . . . . . . 247
trace database files . . . . . . . . . . 229 Developing agents. . . . . . . . . . . 250
Collection Services data files: System category Set up your agent environment . . . . . . 252
and file relationships . . . . . . . . . . 229 Managing agents . . . . . . . . . . . 260
Collection Services data files: Task type extender 231
Disk Watcher data files . . . . . . . . . . 234 Appendix. Notices . . . . . . . . . 267
Disk Watcher data files: QAPYDWINTI. . . . 234 Programming Interface Information . . . . . . 268
Disk Watcher data files: QAPYDWOBJR . . . 235 Trademarks . . . . . . . . . . . . . . 269
Disk Watcher data files: QAPYDWPGMR . . . 236 Terms and conditions. . . . . . . . . . . 269
Disk Watcher data files: QAPYDWRUNI . . . 236
Performance data is a set of information about the operation of a system (or network of systems) that can
be used to understand response time and throughput. You can use performance data to make
adjustments to programs, system attributes, and operations. These adjustments can improve response
times and throughputs. Adjustments can also help you to predict the effects of certain changes to the
system, operation, or program.
Collection Services collects performance data into a management collection object (*MGTCOL). The
Create Performance Data (CRTPFRDTA) command processes data from that collection object and stores
the result into performance database files.
Additional field information, such as number of bytes and buffer position, is available by using the
Display File Field Description (DSPFFD) command. For example, type the following on any command
line:
DSPFFD file(QSYS/QAPMCONF)
Related information:
Collection Services
Use Collection Services to collect performance data for later analysis.
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Display File Field Description (DSPFFD) command
See the Display File Field Description (DSPFFD) command for information on how to display field
information.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
This optional secondary file is created only when the system collects performance data for ARM
transactions. The QAPMARMTRT file contains one record for each ARM transaction type that is known
to the system.
You can identify the ARM transaction type by a combination of the ARM application name and the ARM
application group name.
The ARM transaction type name has a prefix of “QARM” followed by a 16-character representation of an
8-byte internal ARM transaction type ID.
Related reference:
“Collection Services data files: QAPMUSRTNS” on page 205
This database file contains performance data for the user-defined and Application Response Measurement
(ARM) transactions.
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Enable ARM on IBM-instrumented applications
See the Enable ARM on IBM-instrumented applications topic for information on how to information on
how to enable ARM APIs on a system.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Note: The counters BSLNK through BSLQAK are error recovery counters and are increased the first time
the error is detected. The counters BSLTNK and BSLTQA are error recovery counters and are
increased every time the error occurs. The same errors are being counted in each set of counters, so
the first set indicates how many times an error was detected and the second set indicates how
many retries it took to recover from the errors.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
| The metrics supported are dependent on the instrumentation within the hardware chips. Support for a
| particular bus is dependent on both the type of bus as well as the chip family. Initially only the RIO HSL
| busses with Galaxy chip families are supported.
| There may be one or more records each interval for a reported bus. The number of records as well as the
| metrics supported are dependent on both bus type and chip type.
| The collection partition must be authorized to obtain this data (reference the "Allow performance
| information collection" option within the HMC partition configuration).
|| Field Name Description Attribute
| INTNUM Interval number: The nth sample database interval PD (5,0)
| based on the start time specified in the Create
| Performance Data (CRTPFRDTA) command.
| DATETIME Interval date and time. The date and time of the sample Timestamp
| interval.
| INTSEC Elapsed interval seconds. The number of seconds since PD (7, 0)
| the last sample interval.
| BUNBR Bus number. The hardware assigned number associated B (9, 0)
| with the bus.
| BUTYPE Bus type. Supported bus types are: B (4, 0)
| v 4 - RIO HSL Loop
| BUDFMT Bus data format. This field is being provided to help Char (4)
| understand what data is instrumented by the hardware
| components of the bus should there be future
| differences.
| BUATTR1 Bus attribute 1. The meaning of this field depends on B (4, 0)
| the bus type.
| v Type 4: Port identifier. One record will be present for
| each supported port
| 0 = even port
| 1 = odd port
| BUPKTSND Packets sent. B (18, 0)
| BUPKTRCV Packets received. B (18, 0)
| BUBYTESND Bytes sent. B (18, 0)
| Note: This metric is an estimate based on the number of
| packets and maximum byte rate.
| BUBYTERCV Bytes received. B (18, 0)
| Note: This metric is an estimate based on the number of
| packets and maximum byte rate.
| BUMAXRATE Maximum byte rate. The estimated maximum rate that B (18, 0)
| data may be both sent and received in bytes per second.
Note:
The idle loop count and time are used to calculate the communications IOP utilization as follows:
Value Description
00 No time value supplied
11 Integrated xSeries Server pipe task (Integrated xSeries
Server was previously known as file server I/O
processor and FSIOP)
42 Localtalk task
43 Wireless task
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
It lists the fields in the storage device IOP file. Consider the following information in these fields:
v Device means disk.
v The idle loop count and time are used to calculate the storage device controller IOP utilization as
follows:
Convert the product of the idle loop count times the idle loop time from hundredths of microseconds
to seconds. Subtract this from the interval time, and divide the result by the interval time. For example:
IOP Utilization = (INTSEC - (DIIDLC * DIIDLT)/10**8)/INTSEC
Note: The performance monitor reports I/O processor (IOP) statistics different beginning with Version 3
Release 7. Therefore, performance statistics for IOPs introduced in Version 3 Release 7 or later
releases are reported in the QAPMMIOP file. Performance statistics are reported in the
QAPMMIOP file even if the IOP supports only one of the three IOP functions (communications,
disk, or local workstation). Performance statistics for IOPs that were introduced before Version 3
Release 7 will continue to be reported in the appropriate IOP file (QAPMCIOP, QAPMDIOP,
QAPMLIOP, and QAPMMIOP).
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
| Typically, there is one disk resource per disk unit except for a multipath disk unit that has multiple disk
| resources associated with it. The associated disk response time boundaries (in milliseconds) are reported
| in the QAPMCONF file in GKEY fields B1-B5.
Notes:
1. The idle loop count and time are used to calculate the storage device controller utilization as
follows:
Convert the product of the idle loop count times the idle loop time from hundredths of
microseconds to seconds. Subtract this from the interval time, and divide the result by the
interval time. For example:
| This file reports separate response bucket entries for read operations and for write operations. The
| response times and service times are reported in microseconds. The associated disk response time
| boundaries (in microseconds) are reported in the QAPMCONF file in GKEY fields G1-GA.
|| Field Name Description Attribute
| INTNUM Interval number: The nth sample PD (5,0)
| database interval based on the start
| time specified in the Create
| Performance Data (CRTPFRDTA)
| command.
| DSDRN Device resource name. Typically, C (10)
| there is one disk (device) resource per
| disk unit except for a multipath disk
| unit that has multiple disk resources
| associated with it.
| DSRBKCTR1 Disk read operations in disk response B (9, 0)
| time bucket 1. Number of read
| operations since last sample, the
| response time of which was less than
| the first disk response time boundary.
| DSRBKRTR1 Disk response time in disk read B (18, 0)
| response time bucket 1. Combined
| response time of all disk read
| operations since last sample, the
| response time of which was less than
| the first disk response time boundary
| (microseconds).
| DSRBKSTR1 Disk service time in disk read B (18, 0)
| response time bucket 1. Combined
| service time of all disk read
| operations since last sample, the
| response time of which was less than
| the first disk response time boundary
| (microseconds).
This file contains 1 record per interval for each Domino server active on the system.
Note: These descriptions include the name of the metric as it is found in the Domino “show stat”
function.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Data port services, such as remote independent ASP mirroring, is used by LIC clients. There is one record
per IP address per client per collection interval.
Related reference:
Token-ring protocol statistics are reported for active token-ring line descriptions that are associated with
token-ring ports and with asynchronous transfer mode ports that support token-ring LAN emulation.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Ethernet LAN protocol statistics are reported for the active Ethernet line descriptions that are associated
with Ethernet ports and with asynchronous transfer mode ports that support Ethernet LAN emulation.
| There will be one record per line per port per interval. Port resource name should be used to uniquely
| associate records across intervals.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Statistics are kept on a line basis for the fields in the HDLC file.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
This file represents basic data associated with each instance of the server. This file will contain one record
per interval per server instance.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
This file contains detailed data that is repeated for different request types which are processed by the
server. One record will be written to this file for each configured request type in each active server
instance each interval.
Note: Request types are reported as long as they are configured for the server regardless of whether any
data was processed by them.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Data is reported for the Network Server (*IPCS category) and I/O adapters (*IOPBASE category).
Network server data includes Integrated xSeries Server data and virtual I/O data. Virtual I/O data
consists of one record for each virtual device in use. If Network Server is associated with a Network
Server Host Adapter, virtual device might have more than one record reported per interval--one record
Note:
D (Delta counter): Number of occurrences in the interval (what most performance counters are).
S (State counter): The value at the time of collection or the maximum value during the interval.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Collection Services provides data only for jobs that consume CPU during an interval.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
“Collection Services data files: Task type extender” on page 231
A task type extender identifies the area of functional support provided by the task.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Notes:
Table 1. Job flags:
Bit
0 Pass-through service
1 Pass-through target
2 Emulation active
3 System i Access application
4 Target DDM job
5 MRT
6-15 not used
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
| The QAPMJOBS file is created when the performance monitor database files are migrated with the
| Convert Performance Collection (CVTPFRCOL) command to a newer release. Collection Services does not
| create the QAPMJOBS file.
The database files contain data for each job, task or thread (one record per job, task, or thread). Collection
Services provides data only for jobs that consume CPU during an interval. “Job” means job, task, or
thread. Data in this file comes from the *JOBMI and *JOBOS categories.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
“Collection Services data files: Task type extender” on page 231
A task type extender identifies the area of functional support provided by the task.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
| There will be one record per job for each operation type it has performed (see field JSTYPE).
|| Field Name Description Attribute
| INTNUM Interval number: The nth sample database interval PD (5,0)
| based on the start time specified in the Create
| Performance Data (CRTPFRDTA) command.
| DATETIME Interval date and time. The date and time of the sample Timestamp
| interval.
| INTSEC Elapsed interval seconds. The number of seconds since PD (7, 0)
| the last sample interval.
| JSTDE System task identifier. C (8)
| JSTYPE Record/operation type. This field identifies the type of C (1)
| data contained within the record. Record types are
| based on the save/restore operation performed:
| v '1' - IFS save
| v '2' - IFS restore
| v '3' - Library save
| v '4' - Library restore
| JSOPSSTR Operations started. The number of save or restore B (9, 0)
| operations started.
| JSGRPSTR Groups started. The number of groups of objects started. B (9, 0)
| JSGPREPRC Groups preprocessed. The number of groups of objects B (9, 0)
| that have completed preprocessing.
| JSGCHKRDY Groups checkpoint ready. The number of groups of B (9, 0)
| objects ready for checkpoint processing. (This metric is
| supported only for IFS save operations).
At least one record will be written for each job, task, or thread that consumed CPU during the interval
(multiple records are possible especially during service activities).
The purpose of this file is to account for the time a job (this means a task, primary thread, or secondary
thread) spends waiting and to provide some indication as to the type of wait. Since the reasons for a wait
are too numerous to handle individually, they are grouped into sets of functionally related waits. For
each group, both the number of waits and time the job spent waiting are reported. The QAPMJOBWTD
file provides a description of the type of wait conditions for each counter set.
Although the file contains fields for up to 32 sets of counters, not all may be used. The counter sets
(buckets) actually used are reported in a separate file QAPMJOBWTD.
User of this file should be aware of the dynamic nature of the content of this file. Counter sets can be
added or redefined by the new release of the operating system. In addition, IBM service representatives
can define new counter sets or redefine existing counter sets to allow more granular or more specialized
view of the job wait statistics. As a result, user cannot assume that the content of this file is always the
same.
Note:
1. When QAPMJOBWT file data was collected on a system with operating system version i5/OS
V5R4, only the first 16 counter sets are provided.
2. A job that is waiting will not be reported if it has done no processing in the interval. However,
current waits for jobs that have used no CPU are reported in the wait gap file QAPMJOBWTG.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
One record will be written for each active counter set when the first instance of wait data is encountered
(normally at the beginning of the collection). Multiple instances of this data are possible during service
activities.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
One record will be written for each job, task, or thread that did not consume CPU during the interval –
those that are not reported in QAPMJOBWT.
Note:
1. If job data was collected on a release prior to V6R1, the collected data does not contain
sufficient information for the wait gap file:
v Records are only written for the jobs which eventually ran during the collection. Jobs which
never ran during collection will not be represented.
v Total wait in this wait state (JWCURT field) is estimated and should not be viewed as an
accurate measurement.
This file is produced only when *JOBMI, *JOBOS, and *SYSLVL categories are all requested from the
Create Performance Data (CRTPFRDTA) command.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Note: The only supported JVM is IBM Technology for Java (J9).
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Notes: The idle loop count and time are used to calculate the communications IOP utilization as follows:
1. Convert the product of the idle loop count times the idle loop time from hundredths of
microseconds to seconds. Subtract this from the interval time, and divide the results by the
interval time. For example:
This data is collected if the collecting partition has been authorized to obtain it. This authorization is a
partition configuration attribute set on the Hardware Management Console (HMC).
| A POWER6® system with firmware level xx340_075 or later is required for this data to be available.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Notes: The idle loop count and time are used to calculate the multifunction IOP utilization as follows:
1. Convert the product of the idle loop count times the idle loop time from hundredths of
microseconds to seconds. Subtract this from the interval time, and divide the results by the
interval time. For example:
Value Description
00 No time value supplied.
11 Integrated xSeries Server pipe task (Integrated xSeries Server was previously known as file
server I/O processor and FSIOP)
20 Storage subsystem task
22 Tape task
23 Diskette task
24 Optical task
30 Communications subsystem task
42 Localtalk task
43 Wireless task
60 Cryptography task
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
This data includes main storage pool file entries and lists the fields in the storage pool file.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
SAP statistics are reported for active TRLAN, Ethernet, DDI, and frame relay line descriptions associated
with TRLAN, Ethernet, DDI and Frame Relay ports, respectively. SAP statistics are also reported for ATM
ports that support token-ring and Ethernet LAN emulation.
| There will be one record per service access point per line per port per interval. Port resource name
| should also be used to uniquely associate records across intervals.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
| Data is generated only when a partition is defined to use a shared memory pool. Data is reported for
| both the partition's use of the pool as well as pool metrics that are the sum of activity caused by all
| partitions using the pool.
| A POWER6 system with firmware level xx340_075 or later is required for this data to be available.
|| Field Name Description Attribute
| INTNUM Interval number: The nth sample database interval PD (5,0)
| based on the start time specified in the Create
| Performance Data (CRTPFRDTA) command.
| DATETIME Interval date and time. The date and time of the sample Timestamp
| interval.
| INTSEC Elapsed interval seconds. The number of seconds since PD (7, 0)
| the last sample interval.
| SMPOOLID Shared memory pool identifier. The identifier of the B (5,0)
| shared memory pool which this partition is using.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
This is the station counter file for distributed data interface (DDI) information. These fields are in the DDI
station counter file.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Token-ring LAN station statistics are reported for active token-ring line descriptions that are associated
with token-ring ports and with ATM ports that support token-ring LAN emulation.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Collection Services does not create this file. The QAMPSYSL file is provided for compatibility with the
performance monitor and combines data from QAPMJSUM, QAPMSYSCPU, and QAPMSYSTEM files.
This file is produced when all of these categories are requested from the Create Performance Data
(CRTPFRDTA) command. This file contains system interval file entries.
The following terms are used in the field descriptions and are repeated for each group of jobs:
v Number of database read operations. Total number of physical read operations for database functions.
v Number of nondatabase read operations. Total number of physical read operations for nondatabase
functions.
v Number of write operations. Total number of physical write operations.
v Number of print lines. Number of lines written by the program, which does not reflect what is actually
printed. Spooled files can be ended or printed with multiple copies.
v Number of database writes/reads (logical). Number of times the database module was called, which
does not include I/O operations to readers/writers or I/O operations caused by the Copy Spooled File
(CPYSPLF) or Display Spooled File (DSPSPLF) command. If SEQONLY(*YES) is in effect, these
numbers show each block of records read or written, not the number of individual records read or
written.
v Number of communications writes/reads (logical). These do not include remote workstation activity.
They include only activity related to intersystem communications function (ICF) files when the I/O is
for a communications device.
Users should note that blocked I/O is considered one I/O operation.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Virtual processors represent the operating system's view, within a logical partition, of the processors
assigned to it. The utilization reported for virtual processors is the operating system's view of how much
it has used the virtual processor.
Related concepts:
Reporting CPU utilization
Find out how the total CPU that is consumed across virtual processors is reported.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Physical processor data is reported only if the collecting partition has been authorized to obtain it. This
authorization is a partition configuration attribute set on the Hardware Management Console (HMC).
| A POWER6 system with firmware level xx340_075 or later is required for this data to be available.
‘ ‘ = unknown
‘ ‘ = unknown
‘ ‘ = unknown
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
| Data is generated only when one or more workload capping groups were in use during the collection. A
| record is written for each group that is active.
|| Field Name Description Attribute
| INTNUM Interval number: The nth sample PD (5,0)
| database interval based on the start
| time specified in the Create
| Performance Data (CRTPFRDTA)
| command.
| DATETIME Interval date and time: The date and Timestamp
| time of the sample interval.
| INTSEC Elapsed interval seconds: The number PD (7,0)
| of seconds since the last sample
| interval.
| SWGROUP Group ID. The identifier for the B (9,0)
| workload group.
| SWGNAME Group Name. The name assigned to C (10)
| the workload group when allocated
| by License Management
| SWPRCASN Processors assigned. The maximum B (4,0)
| number of processors which may be
| used concurrently by all threads of all
| processes which are associated with
| the workload group. This is the value
| associated with the group at the time
| data was sampled.
| SWPRCAVL Processor time available (in B (18,0)
| microseconds). The amount of
| processor time that this group had
| available to it based on the number of
| processors assigned to the group over
| time.
| SWPRCUSE Processor unscaled time used (in B (18,0)
| microseconds). The amount of
| unscaled processor time used within
| threads assigned to this group.
| Note: This does not include time
| charged to a thread by server tasks.
| SWSPRCUSE Processor scaled time used (in B (18,0)
| microseconds). The amount of scaled
| processor time used within threads
| assigned to this group.
| Note: This does not include time
| charged to a thread by server tasks.
| SWDELAY Dispatch latency time . The amount B (18,0)
| of time ready to run threads could
| not be dispatched due to the group's
| maximum concurrent processor limit.
| It contains one record per interval per tape device connected to the system.
|| Field Name Description Attribute
| INTNUM Interval number: The nth sample PD (5,0)
| database interval based on the start
| time specified in the Create
| Performance Data (CRTPFRDTA)
| command.
| DATETIME Interval data and time. The date and Timestamp
| time of the sample interval.
| INTSEC Elapsed interval seconds. The number PD (7,0)
| of seconds since the last sample
| interval.
| TPDRN Tape device resource name. C (10)
| TPTYPE Tape device type. C (4)
| TPMDLN Model number. The model number of C (4)
| the tape drive.
| TPIOPRN IOP resource name. C (10)
| TPIOARN Storage adapter (IOA) resource name. C (10)
| TPRDS Number of reads. B (18, 0)
| TPWRTS Number of writes. B (18, 0)
| TPBRD Bytes read. B (18, 0)
| TPBWRT Bytes written. B (18, 0)
| TPWREQ Time spent waiting for a request from B (18, 0)
| the client (in milliseconds).
| TPWRESP Time spent waiting for a response B (18, 0)
| from the drive (in milliseconds).
| TPSFMCMD Space by file mark commands. B (18, 0)
| TPFLMRKSPC File marks spaced. B (18, 0)
| TPSBCMD Space block commands. B (18, 0)
| TPBLCKSPC Blocks spaced. B (18, 0)
| TPWFMCMD Write file mark commands. B (18, 0)
| TPFLMRKWRT File marks written. B (18, 0)
| TPSEODCMD Space to EOD commands. B (18, 0)
| TPWBCMD Write buffer commands. B (18, 0)
Note: The TCP/IP performance data includes data for both for Internet Protocol version 4 (IPv4) and
Internet Protocol version 6 (IPv6).
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
| There are one or two records per TCP/IP interface per collection interval. If both Internet Protocol
| version 4 (IPv4) and Internet Protocol version 6 (IPv6) data are available for an interface, the primary
| record will contain the combined data. If the data was collected on a release that supports the collection
| of independent data for IPv6, a secondary record will contain the data specific to IPv6. If data is available
| for only one Internet Protocol version, the primary record will contain data specific to that Internet
| Protocol version and there will not be a secondary record.
| Note: The TCP/IP performance data includes data for both for Internet Protocol version 4 (IPv4), for
| Internet Protocol version 6 (IPv6), or for both Internet Protocol version 4 and Internet Protocol
| version 6.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
One record is created for each type of transaction that occurs for a given job during the interval.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
“Collection Services data files: QAPMARMTRT” on page 15
This database file contains information about Application Response Measurement (ARM) transaction
types that are reported in the QAPMUSRTNS file.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
The data file contains one record for each application per interval. Applications can be either of the
following types:
v Servlet sessions
v Web applications (servlets and JSPs)
Much of the data comes from WebSphere Performance Monitoring Infrastructure (PMI) data and
transaction counters. Where PMI data is used directly, the name of the PMI field is provided.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
WebSphere servlet session counters
See WebSphere servlet session counters for more information about WebSphere servlet session counters
data.
WebSphere Web application counters
See WebSphere Web application counters for more information about WebSphere Web application
This information is static and therefore does not change during the life of the server. There will be one
record per server. If a WebSphere server stops and is restarted later, it will have a different job name/user
name/job number, but the same server name.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Each record represents one type of EJB (such as stateful, stateless, entity, or message-driven) per
application per interval. If there is no bean activity for a particular EJB type, then no record will be
written.
Much of the data comes from WebSphere Performance Monitoring Infrastructure (PMI) data and
transaction counters. Where PMI data is used directly, the name of the PMI field is provided.
‘1' = Stateful
‘2' = Stateless
‘3' = Entity
‘4' = Message driven
WEHOME EJB homes. Number of EJB homes at the time the data B (9,0)
was sampled.
WECRT Beans created. The total number beans created during B (9,0)
the interval.
(PMI: beanModule.creates; CountStatistic)
WERMV Beans removed. The total number of beans removed B (9,0)
during the interval.
(PMI: beanModule.removes; CountStatistic)
WEPSV Beans passivated. The total number of beans that were B (9,0)
passivated during the interval.
(PMI: beanModule.passivates; CountStatistic)
WELOAD Beans loaded. The total number of beans that were B (9,0)
loaded during the interval. This field applies only to
entity beans.
(PMI: beanModule.loads; CountStatistic)
WESTORE Beans stored. The total number of beans that were B (9,0)
stored during the interval. This field applies only to
entity beans.
(PMI: beanModule.stores; CountStatistic)
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
Each record represents one pooled resource per interval. The type of pooled resource can be a JDBC
connection pool, a J2C connection pool, or a thread pool. Not all fields are applicable to each pooled
resource type. If a resource exists but is not being used (nothing created, destroyed, allocated or
returned), then no record will be written.
Much of the data comes from WebSphere Performance Monitoring Infrastructure (PMI) data and
transaction counters. Where PMI data is used directly, the name of the PMI field is provided.
‘1' = JDBC
‘2' = J2C
‘3' = Thread pool
WPCRT Creates. The total number of connections or threads B (9,0)
created during the interval.
(PMI: JDBC: connectionPoolModule.numCreates;
CountStatistic)
(PMI: J2C: j2cModule.numManagedConnectionsCreated;
CountStatistic)
(PMI: Thread pool: threadPoolModule.threadCreates;
CountStatistic)
WPDST Destroys. The total number of connections or threads B (9,0)
destroyed during the interval.
(PMI: JDBC: connectionPoolModule.numDestroys;
CountStatistic)
(PMI: J2C:
j2cModule.numManagedConnectionsDestroyed;
CountStatistic)
(PMI: Thread pool: threadPoolModule.threadDestroys;
CountStatistic)
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
WebSphere JDBC connection pool counters
See WebSphere JDBC connection pool counters for more information about WebSphere JDBC connection
pool counters data.
WebSphere J2C connection pool counters
See WebSphere J2C connection pool counters for more information about WebSphere J2C connection pool
counters data.
WebSphere thread pool counters
See WebSphere thread pool counters for more information about WebSphere thread pool counters data.
It contains one record for each server job per interval. Much of the data comes from WebSphere
Performance Monitoring Infrastructure (PMI) data and transaction counters. Where PMI data is used
directly, the name of the PMI field is provided.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
“Data files: File abbreviations” on page 244
The database files use abbreviations in the field and byte data tables.
Related information:
Create Performance Data (CRTPFRDTA) command
See the Create Performance Data (CRTPFRDTA) command for information on how to create performance
database files.
The following performance data files show the file names, brief descriptions, and references to field data
detail (when provided) for the system configuration data, subsystem data, and hardware configuration
data.
Related reference:
“Collection Services data files: System category and file relationships” on page 229
When you collect performance data using Collection Services, the data is stored in a management
collection (*MGTCOL) object.
Related information:
Collection Services
Use Collection Services to collect performance data for later analysis.
| The GKEY fields B1-B5 apply to the disk response time bucket data in the QAPMDISK file. The GKEY
| fields G1-GA apply to the disk response time bucket data in the QAPMDISKRB file.
GRES Reserved.
Attributes: C (4)
GKEY Identifier to indicate what data is contained in the GDES field. See descriptions in the following
table.
Attributes: C (2)
GDES Data for the associated GKEY value. See values in the following table. Unless otherwise noted, all
system values pertain to the partition for which the data was collected. Unless otherwise
indicated, all the data is left-justified in this field.
Attributes: C (10)
GKEY GDES
1 Performance monitor or data start date. Data is reported as a C(7) value with the following
format: (yymmddc).
2 Performance monitor or data start time. Time is reported as a C(6) value with the following
format: (hhmmss).
3 A 4-character model number followed by a 4-character system type.
4 Memory for the partition (zoned (10,0)) in kilobytes (KB).
5 Communications data collected, which will be set to Y only if any communication files were
created.
6 Machine serial number (character 10).
7 First response time boundary (zoned (10,0)) in milliseconds. The first response time monitor
bracket is from 0 up to and including the first response time boundary.
8 Second response time boundary (zoned (10,0)) in milliseconds. The second response time monitor
bracket is from the first response time boundary up to and including the second response time
boundary.
9 Third response time boundary (zoned (10,0)) in milliseconds. The third response time monitor
bracket is from the second response time boundary up to and including the third response time
boundary.
10 Fourth response time boundary (zoned (10,0)) in milliseconds. The fourth response time monitor
bracket is from the third response time boundary up to and including the fourth response time
boundary. Responses greater than the fourth response time boundary fall under the fifth response
time monitor bracket.
11 System ASP capacity (zoned (10,0)) in kilobytes (KB). This is the total number of kilobytes (KB) of
auxiliary storage allocated to the system ASP for the storage of data.
If this field is set to the largest number it can hold (9999999999), system ASP capacity is too large
to fit in this record and the record with GKEY 21 should be used instead.
12 Checksum protection on (Y/N).
13 Number of logical processors assigned to the partition (PD (3,0)).
14 First remote response time boundary (zoned (10,0)) in milliseconds. The first response time
monitor bracket is from 0 up to and including the first response time boundary. This data only
appears when requested with the Start Performance Monitor (STRPFRMON) command.
| Tasks and secondary threads whose lifespan is shorter than the reporting threshold are not
| individually collected in the *JOBMI category data. Instead one entry per node is accumulated for
| tasks running on that node and one entry per job is accumulated for secondary threads of that
| job. See QAPMJOBMI field JBSLTCNT.
| The short lifespan reporting thresholds used during data collection can be overridden via system
| environment variables that specify the reporting threshold (number of milliseconds) to use. The
| following example will cause data for all tasks and secondary threads to be individually collected:
| ADDENVVAR ENVVAR(QPM_TASK_SL_THRESHOLD) VALUE(0) LEVEL(*SYS)
| ADDENVVAR ENVVAR(QPM_THREAD_SL_THRESHOLD) VALUE(0) LEVEL(*SYS)
| G1 The first disk response time boundary in microseconds (B(9,0)). The first disk response time
| bucket is from 0 up to the first response time boundary.
| G2 The second disk response time boundary in microseconds (B(9,0)). The second disk response time
| bucket is from and including the first response time boundary up to the second boundary.
| G3 The third disk response time boundary in microseconds (B(9,0)). The third disk response time
| bucket is from and including the second response time boundary up to the third boundary.
Related concepts:
Shared processor pools
See the Shared processors topic for information about processors whose processing capacity is shared
among multiple logical partitions.
Related information:
i5/OS licensing
See the i5/OS licensing topic for information about feature 5052 (user entitlement key).
This file contains one record for each hardware component in the partition.
The format of the output file is the same as that of the physical file model, QARZALLF, and its associated
record format model, QRZALL.
When Collect Services starts, it issues the DSPHDWRSC command with the following parameters:
DSPHDWRSC TYPE(*AHW) OUTPUT(*OUTFILE)
OUTFILE(myperformance_lib/QAPMHDWR)
OUTMBR(myperformance_mbr *REPLACE)
OUTFILFMT (*type2)
Collection Services database files: Field data for trace database files
Trace data is collected only when you choose to do so. You can find the QAPMDMPT file in the trace
data files.
Trace data includes internal system trace data. This is detailed data that you collect to gain additional
information about specific jobs and transactions. This type of data should not be collected unless you use
the Performance Tools licensed program to analyze it. The system supports the following performance
data file when using the Start Performance Trace (STRPFRTRC) command.
The Create Performance Data (CRTPFRDTA) command exports data from that management collection
object and then writes the data to the performance data files. Each type of data that can be independently
controlled and collected by Collection Services is represented by a data category. Each data category
contains or provides data that is written to one or more performance data files. For a database file or
member to be created, the category (or group of categories) that the file or member is dependent on must
exist and be processed by CRTPFRDTA. The following table identifies the category-to-file relationships.
There are three types of relationships.
Relationship Description
Primary files These files are related to and generated from the
category.
Compatibility files These files are logical files that join primary files to
provide performance database compatibility with the
previous file structure. If the system generates all
participating files (primary categories), compatibility files
are also generated.
Secondary files These files are related to and contain some data that is
derived from data contained in the category or in the
primary file. However, they are not controlled by that
category.
The following table illustrates the relationships between system categories and performance database
files.
Related concepts:
“Collection Services data files: Field data for configuration database files” on page 221
Configuration data is collected once per session. You can find the QAPMCONF, QAPMHDWR, and
QAPMSBSD files in the configuration data files.
Related information:
Collection Services
Use Collection Services to collect performance data for later analysis.
The task type extender field is used to logically group together tasks that perform similar operations. This
field is used primarily for performance monitoring. The table below lists the task type extender as two
EBCDIC characters followed by the task type extender description.
Note: Resolution data may not be available for every object. There is a chance that the data could have
been unavailable at the time collection was attempted.
This file includes object information associated with the records in the QAPYDWTRC file. One record is
created per object on which an I/O operation was performed.
Note: Resolution data may not be available for every program or procedure. There is a chance that the
data could have been unavailable at the time collection was attempted.
This file includes program or procedure information associated with the records in the QAPYDWTRC file.
One record is created per program or procedure initiating an I/O operation.
0 = SLIC frame
1 = NMI frame
2 = OMI frame
3 = Java frame
4 = PASE frame
PRSTRHDL Procedure start handle. The start handle of this H (8)
procedure.
PRENDHDL Procedure end handle. The end handle of this H (8)
procedure.
PRNAME Procedure name. The name of this procedure. Varchar (256)
Dft (64)
One record is created per Disk Watcher session. This record is overwritten with current data each time a
new interval is collected.
0 = no data missed.
1 = data missed for this disk unit.
STRESERVE1 Reserved B (8)
STRESERVE2 Reserved B (8)
STRESERVE3 Reserved B (8)
This file includes TDE information for the records in the QAPYDWTRC file. One record is created per
unique taskcount in the QAPYJWTRC file.
T = Task.
P = Primary thread.
S = Secondary thread.
L = Licensed Internal Code (LIC) thread.
TRTDENAME Job or task name. The job or task name associated with C (26)
this TDE. For jobs this will be the fully qualified job
name which is made up of the job name, user name,
and job number.
TRCURRUSER Current user. The current user associated with this TDE. C (10)
This is the user associated with the job when the TDE
information was initially collected. This value will not
be updated if the user associated with the job changes.
TRJVTHD Java thread name. If this is a Java thread, this value is Varchar (256)
the Java thread name. If this is not a Java thread, this Dft (16)
value will be blank.
Abbreviation Description
Primary files These files are related to and generated from the
category.
C Character in the Attributes column.
H Hexadecimal in the Attributes column.
PD Packed decimal in the Attributes column.
Z Zoned decimal in the Attributes column.
IOP Input/output processor or I/O processor. The processors
that control the activity between the host system and
other devices, such as disks, display stations, and
communication lines.
DCE Data circuit-terminating equipment.
MAC Medium-access control. An entity in the communications
IOP.
LLC Logical link control. An entity in the communications
IOP.
Beacon frame A frame that is sent when the ring is inoperable.
Type II frame A connection-oriented frame (information frame) used by
Systems Network Architecture (SNA).
I-frame An information frame.
B The DDS binary data type of 4 digits, which is 2 bytes, in
the Attributes column.
G Graphic - used to hold double-byte Unicode data.
This table provides a list of some CL commands that are a part of IBM Performance Tools for i. For more
commands, see the Performance Tools for i Commands topic in the Programming topic collection.
Table 8. General CL commands
Command Function
Analyze Performance Data (ANZPFRDTA) Produces recommendations to improve the performance
of your system.
Display Performance Data (DSPPFRDTA) Displays performance data collected by Collection
Services.
Print Activity Report (PRTACTRPT) Prints the activity report.
Print Component Report (PRTCPTRPT) Prints the component report.
Print Job Interval Report (PRTJOBRPT) Prints the job interval report.
Print Job Trace Report (PRTTRCRPT) Prints the job trace report.
Print Lock Report (PRTLCKRPT) Prints the lock report.
Print Pool Report (PRTPOLRPT) Prints the pool report.
Print Resource Report (PRTRSCRPT) Prints the resource report.
Print System Report (PRTSYSRPT) Prints the system report.
Print Transaction Report (PRTTNSRPT) Prints the transaction report.
Start Performance Tools (STRPFRT) Calls the performance tools menu interface.
Related information:
System i Navigator monitors
Performance Tools for i5/OS commands
See the Performance Tools for i5/OS commands topic for a list of Performance Tools for i5/OS
commands.
Intelligent Agents
The Intelligent Agents console for System i Navigator provides system administrators with an easy way
to manage one or more Agent Building and Learning Environment (ABLE) agents running on a single
system or across different systems.
Intelligent agents are Java-based software components that are capable of learning certain behaviors over
time through complex autonomic algorithms. Intelligent agents can have many different capabilities, from
simply monitoring for certain events to more complex actions like analyzing network problems,
preventing unplanned system restarts, or managing storage. Although the goal of using agents is to
simplify the system administrators tasks through autonomic computing, system administrators still need
a way of starting, stopping, responding to, and monitoring the actions of their agents.
The Intelligent Agents console for System i Navigator provides system administrators with an easy way
to manage one or more ABLE agents running on a single system or across different systems. After the
agent console connects to the agent services that exist across your domain, you can monitor and work
with any number of preconfigured agents on any of the systems in your domain.
ABLE agents are Java objects capable of automating tasks through the use of rule-based reasoning and
learning certain behaviors over time by using data mining algorithms contained in the ABLE component
library. ABLE is a Java framework and toolkit used for building multiagent intelligent autonomic systems,
and provides specific support for developing agents that work with the System i Navigator Intelligent
Agent platform and console. Intelligent agents developed using ABLE can have the following capabilities:
v Learn from experience and predict future states
v Analyze metric data using classification and clustering algorithms to detect complex states and
diagnose problems
v Interface with other autonomic components via web services
v Reason using domain-specific Java application objects
v Use powerful machine reasoning, including: Boolean forward and backward chaining, predicate logic
(Prolog), Rete'-based pattern match, and fuzzy systems
v Have autonomous (proactive) behavior and goals
v Correlate events into situations, reason, and take actions
The ABLE toolkit contains several examples of how to design your own agent, and a template agent is
included that you can use as a model when developing your own agent. To create an agent that can be
fully managed from the console, the agent should extend the AbleEServerDefaultAgent example.
Agent platform
Agent Services live on your system or across your distributed platform, and are responsible for the life
cycle, security, and behavior of your agent.
The Intelligent Agents console in System i Navigator requires that an agent platform be configured on
your system, or across a distributed network. An agent platform is nothing more than a set of Java
Virtual Machines, or agent pools, that run the services and agents of the platform. The platform is
defined by a preferences file called ableplatform.preferences. This file lists the location (system and port)
of each agent pool (JVM), the services that will run on or across the platform, and the agents that are
allowed to run in the platform. If security is configured, the preferences file also lists the Kerberos user
and service principals used to authenticate each service, agent, and user that is part of the platform.
Agent services, which can exist on any of the systems across your distributed platform, are responsible
for the life cycle, security, and behavior of your agent. Agents running on the same system or distributed
agents running across different systems use the defined set of platform services for different tasks such as
getting a unique name, looking up other agents in a directory, logging, and passing messages to another
agent.
Developing agents
Create and customize your own agent to perform the tasks that you want. The Agent Building and
Learning Environment (ABLE) toolkit and its associated documentation provide a working development
environment and a template agent that can be used as a guide for developing your own agents.
ABLE is a Java framework, component library, and productivity tool kit for building intelligent agents
using machine learning and reasoning.
You can use the ABLE toolkit to develop your own hybrid intelligent agents. This Java framework has its
own rule language called ABLE rule language (ARL) and its own GUI-based interactive development
environment, the ABLE Agent Editor; both are provided to assist in the construction of ABLE agents.
ABLE 2.0
Both the ABLE toolkit and complete ABLE documentation are available to download in .zip
packages.
The System i Navigator Intelligent Agents console is included with a template agent that you can use as a
guideline for developing agents to work with the console. The source code for AbleEserverTemplateAgent
is stored in ableplatform.jar, located in QIBM/ProdData/OS400/Able.
AbleEserverTemplateAgent makes use of many of the features available when developing agents using
the ABLE framework. It demonstrates how an agent would create a set of capabilities that could be
managed through the console. It includes a Customize panel that can be used to alter agent settings and
an About panel that is used to display information about the agent. It also shows how an agent uses the
logging service to log requests and history entries that can be displayed and responded to through the
console.
Agent capabilities
Customization panel
The agent supplies a customization panel that allows you to adjust the interval at which the agent checks
if the minute or hour has changed.
About panel
The agent supplies an about panel that allows you to provide detailed information about the agent.
Both the ABLE 2.0 Toolkit and the ABLE Documentation bundle are available to download as .zip
packages:
v ABLE 2.0 Toolkit: AbleAll_2.0.0.zip
This 6 MB zipped package contains the ABLE Java framework, component library, and tool kit.
v ABLE Documentation: doc.zip
This 12 MB zipped package contains complete ABLE documentation, including an FAQ, the README,
license agreement, JavaDoc, and more. Also included in doc.zip is a second zipped package
(Able-Class.zip) that contains several exercises and presentations designed to help you develop ABLE
agents.
The System i Navigator Intelligent Agents console functions by connecting to an agent platform running
on your system, or across a distributed network. The agent platform defines the agent pools (JVMs) that
your agent services and agents will run in. Before you begin setting up your agent platform, you need to
determine your security preferences. A secure platform requires that you configure Kerberos.
To manage agents using the intelligent agents console, you must first define, secure, and start an agent
platform that the console will connect to. An agent platform is nothing more than a set of Java Virtual
Machines, or agent pools, that run the services and agents of the platform. The ableplatform.preferences
and able.preferences files are used to define a platform.
Once the agent platform is set up, the services that run on or across the platform allow an agent to
receive a unique name, look up other agents in a directory, log history or requests, pass messages to one
another, or control the state of an agent.
To begin configuring your platform, you must define your agent pools, agent services, permitted agents,
and add Kerberos security principals by modifying the ableplatform.preferences file.
Notes:
1. Multiple platforms can be configured, and you need to ensure that your platform does not
reside at the same location as an existing platform using the same port. See the Start the agent
platform topic for more details.
2. When you open the file and begin making changes to the content, understand that small
errors and misspellings will cause the agent platform to fail, and there is currently no easy
way to debug your mistakes. Avoid commenting out properties that are unused, commenting
out an unused property can cause the platform to fail. For example, if you choose to run the
platform with security turned off, do not comment out the principal properties through the
file.
The following code samples taken from ableplatform.preferences provide examples of how to modify the
platform preferences. To configure your platform, follow these steps:
AgentPool.2.Alias = Pool2
AgentPool.2.IpAddress = systemname.ibm.com
AgentPool.2.Port = 55552
AgentPool.2.Principal = servicePrincipal1
AgentPool.3.Alias = Pool3
AgentPool.3.IpAddress = systemname.ibm.com
AgentPool.3.Port = 55553
AgentPool.3.Principal = servicePrincipal2
#----------------------------------------------------------------------
2. Define agent services.
Define the agent services that you want to run on the platform, and specify the alias of the agent pool
you want them to run in. Each agent service must point to a factory. The factory is a Java Class that
creates the agent service. The Persistence service is used to restart a platform to its previous state.
Specify to turn persistence on or off. If you turn persistence on, you must specify a Database, Table,
and Schema so that persistence has a location to store backed up data on. You can also specify a value
for the PersistenceRetry property. If the persistence service fails and you specified a value of 5000 for
the PersistenceRetry property, it will attempt to retry every 5000 milliseconds. The following code
example shows how three different services, Directory, Logging, and Persistence, could be defined:
Services=Agent-Directory-Service,Agent-Logging-Service,
Persistence-Service
Agent-Directory-Service.AgentPool = Pool1
Agent-Directory-Service.Factory =
com.ibm.able.platform.RMIVerifiableDirectoryServiceFactory
Agent-Directory-Service.Persistence = off
Agent-Directory-Service.PersistenceDatabase = *LOCAL
Agent-Directory-Service.PersistenceTable = qahadir
Agent-Directory-Service.PersistenceSchema = QUSRSYS
Agent-Directory-Service.PersistenceRetry = 5000
Agent-Logging-Service.AgentPool = Pool1
Agent-Logging-Service.Factory =
com.ibm.able.platform.RmiAgentLoggingServiceFactory
Agent-Logging-Service.Persistence = off
Agent-Logging-Service.PersistenceDatabase = *LOCAL
Agent-Logging-Service.PersistenceTable = qahalog
Agent-Logging-Service.PersistenceSchema = QUSRSYS
Agent-Logging-Service.PersistenceRetry = 5000
Agent-Logging-Service.Properties = history-log-max : 100
Results
After you have defined your agent pools, agent services, and permitted agents, and optionally set up
security, you need to start the agent platform.
Platform security can be turned on or off. If you choose to run on or across a platform that has security
turned off, anyone can deregister or modify another person's agent descriptions. Anyone can change the
capabilities or state of any agent. Anyone can remove or answer any requests, even if they are not their
own. Agents can potentially take destructive actions when being used incorrectly or by the wrong user.
To ensure that agents are used the way they were intended, security features have been added to the
infrastructure of the platform.
When security is turned on, agents and services can authenticate and authorize every action that is taken
on or across the platform. An agent can only deregister or alter its own agent description. An agent must
authorize all answered requests and capability changes. A certain authority level is required to alter the
state of an agent. The use of an agent can be limited to certain users and locations. When security is
turned on, every action that occurs can be traced back to a known user so that platform authentication
and authorization can occur.
If you choose to secure your agent platform, you can turn security on by changing the Security property
to Security=on in the able.preferences file that defines your platform.
The intelligent agent platform uses Kerberos principals to authenticate users and services throughout the
agent platform. Kerberos protocol, developed by Massachusetts Institute of Technology, allows a principal
(a user or service) to prove its identity to another service within an insecure network.
Authentication of principals is completed through a centralized server called a key distribution center
(KDC). The KDC authenticates a user with a Kerberos ticket. These tickets prove the principal's identity
to other services in a network. After a principal is authenticated by these tickets, they can exchange
encrypted data with a target service.
The platform uses Kerberos to authenticate user sign on and initial platform startup. To use Kerberos to
secure your platform, you must either find an existing KDC, or create a working KDC that all parts of
the platform use. Every system running a piece of the platform and every PC running a console that
connects to this platform must be configured to use this KDC. You need to list all Kerberos principals in
the ableplatform.preferences file that are used by the platform to authenticate users and services. Each
platform Java Virtual Machine (agent pool) has a service principal associated with it, and each user
logging onto the platform from a console needs a user principal. All of these principals need to be added
to the KDC.
Procedure
1. Find or create a usable Kerberos key distribution center (KDC).
The agent platform does not require a KDC on IBM i. A KDC running on any platform will work. If
you cannot find an existing KDC to use, you can create your own. In V5R3 or later, IBM i supports a
Kerberos server in IBM i PASE. You can configure and manage a Kerberos server from your system.
To configure a Kerberos server in IBM i PASE, complete the following steps:
a. In a character-based interface, type call QP2TERM. This command opens an interactive shell
environment that allows you to work with IBM i PASE applications.
b. At the command line, enter export PATH=$PATH:/usr/krb5/sbin. This command points to the
Kerberos scripts that are necessary to run the executable files.
c. At the command line, enter config.krb5 -S -d iseriesa.myco.com -r MYCO.COM. This command
updates the krb5.config file with the domain name and realm for the Kerberos server, creates the
Kerberos database within the integrated file system, and configures the Kerberos server in IBM i
PASE. You are prompted to add a database master password and a password for the
admin/admin principal, which is used to administer the Kerberos server.
d. At the command line, enter /usr/krb5/sbin/start.krb5 to start the servers.
2. Configure systems in your agent environment to use Kerberos.
After you create a Kerberos server (KDC), you need to individually configure each client PC that will
attempt to connect to the secure platform, and each system in your agent platform to point to your
Kerberos server (KDC).
v Configure your client PC
To configure a client PC, you need to create a text file called krb5.conf in the security folder of the
JVM that runs your System i Navigator intelligent agents console located here (where C: is the
drive where your System i Access driver is installed):
[realms]
KDC_REALM.PASE.COM = {
kdc = system1.rchland.ibm.com:88
}
[domain_realm]
.rchland.ibm.com = KDC_REALM.PASE.COM
v Configure your system
To point your system to your KDC, you need to modify the following file:
/QIBM/userdata/OS400/networkauthentication/ krb5.conf
The krb5.conf file tells all JVMs started from this JRE which KDC to use when dealing with
Kerberos. The following is an example of what a generic krb5.conf file might look like on the server
if the KDC realm is KDC_REALM.PASE.COM and is found on system1.ibm.com:
??(libdefaults??)
default_realm = KDC_REALM.PASE.COM
??(appdefaults??)
??(realms??)
KDC_REALM.PASE.COM = {
kdc = system1.rchland.ibm.com:88
}
??(domain_realm??)
system1.rchland.ibm.com = KDC_REALM.PASE.COM
3. Acquire Kerberos user and service principals.
After you configure a KDC, you need to create the user and service principals you plan to use to
secure the platform, and register these principals to the KDC:
Service principals:
Each agent pool (JVM) defined in the ableplatform.preferences file must have a service
principal associated with it. Service principals are specific to the system that they run on, so
they must include that system name and be in the following format: ServicePrincipalName/
systemName@KDCRealm. Each of the agent pools on the platform can use the same service
principal, or you can specify that each pool use its own service principal. If each of your
agent pools has different authority levels, then different principals should be used for each
different authority level.
User principals:
Each user that you want to allow to connect to the secure platform through the console needs
a user principal. User principals can be associated with each agent definition listed in the
ableplatform.preferences file. A user principal can connect to a platform from the console,
regardless of the system the console is running on. Because of this, a user principal only needs
to include the principal name and the KDC realm that the principal belongs to:
UserPrincipalName@KDCRealm.
You need to add a principal to the KDC for each service and user principal that your platform uses.
To add your principals to your KDC if you are using the integrated KDC on the server, follow these
steps:
a. In a character-based interface, type call QP2TERM.
b. At the command line, enter export PATH=$PATH:/usr/krb5/sbin. This command points to the
Kerberos scripts that are necessary to run the executable files.
c. At the command line, type kadmin -p admin/admin, and press Enter.
d. Sign in with administrator's password.
e. Enter the following at a command line:
Results
After you set up your KDC and create your user and service principals, you need to configure security in
your ableplatform.preferences file.
Before you begin, ensure that you have configured your Kerberos key distribution center (KDC).
When security is turned on, ableplatform.preferences acts as a policy file for the security of the platform
it defines. The following steps provide examples for how principals, trust levels, and permissions could
be configured:
Procedure
1. Define user and service principals.
After you acquire user and service principals, and register them with your KDC, you need to add
these principals to the ableplatform.preferences file. When security is turned on, a user must be
defined with a valid Kerberos user principal to gain access to the platform, and all agent services and
agent pools must have a valid Kerberos service principal assigned to them. Add the user or service
principals you have registered with your KDC, and specify an alias for each principal (the alias can be
any unique name you want to use).
#----------------------------------------------------------------------
# Principals
#----------------------------------------------------------------------
Principal.1.Alias = servicePrincipal1
Principal.1.Principal = name1/systemName@REALM
Principal.3.Alias = userPrincipal1
Principal.3.Principal = name1@REALM
Principal.4.Alias = userPrincipal2
Principal.4.Principal = name2@REALM
2. Define trust levels.
After you add user and service principals, you need to define the trust level associated with each
principal. A trust level is associated with a principal to help define the capabilities of a user or service
on the platform. Associating a trust level with a principal is also a way to group principals. The same
trust level can be associated with multiple user and service principals. Add the principal alias you
assigned to your service and user principals in step 1 (comma delineated), to the trust level you want
to associate it with, and provide a unique name for trust level alias.
#----------------------------------------------------------------------
# Trust Levels
#----------------------------------------------------------------------
TrustLevel.1.Alias = HighlyTrusted
TrustLevel.1.Principals = servicePrincipal1,userPrincipal1
TrustLevel.2.Alias = SomewhatTrusted
TrustLevel.2.Principals = servicePrincipal2,userPrincipal2
3. Associate service principals with agent pools.
A distributed platform can span multiple ports on multiple systems. Each agent pool defines where
one part (JVM) or the platform will run. Each agent pool entry contains an alias, an IP address, a port,
and a service principal alias. The principal alias specifies what service principal this pool is associated
with. Add the service principal alias that you defined above to associate it with your agent pool.
#----------------------------------------------------------------------
# Agent Pools (Java Virtual Machines)
#----------------------------------------------------------------------
AgentPool.1.Alias = Pool1
AgentPool.1.IpAddress = systemname.ibm.com
AgentPool.1.Port = 55551
AgentPool.1.Principal = servicePrincipal1
AgentPool.2.Alias = Pool2
AgentPool.2.IpAddress = systemname.ibm.com
AgentPool.2.Port = 55552
AgentPool.2.Principal = servicePrincipal1
AgentPool.3.Alias = Pool3
AgentPool.3.IpAddress = systemname.ibm.com
AgentPool.3.Port = 55553
AgentPool.3.Principal = servicePrincipal2
4. Define agent startup authority.
Define which users have the capability to start each of the agents defined on your secure platform.
Add one or more user principal aliases to the EligiblePrincipal parameter.
#----------------------------------------------------------------------
# Permitted Agents
#----------------------------------------------------------------------
Agent.1.Alias=Agent1
Agent.1.AutonomyLevel=Medium
Agent.1.ClassName=com.ibm.able.platform.examples.EServerTemplateAgent
Agent.1.ConstructorArgs=String:AgentName1
Agent.1.EligiblePrincipals=userPrincipal1,userPrincipal2
Agent.1.EligibleAgentPools=Pool2,Pool3
Agent.1.InitArgs=
Results
After you add the necessary security data to the ableplatform.preferences file, save your changes. Turning
on security for the platform once it is correctly configured is as simple as opening the able.preferences file
that defines your platform, and changing the Security property to Security=on. If you are running an
unsecured platform, you need to end and restart the agent platform for security changes to take effect.
Because the platform is made up of one or more Java Virtual Machines, to start the platform you need to
start all of the JVMs that make up the platform.
Procedure
1. Use the Start Agent Services (STRAGTSRV) command to start the agent platform.
2. Use the End Agent Services (ENDAGTSRV) command to stop the agent platform.
What to do next
Note: If you have trouble starting or ending the agent platform, you can turn on tracing for the startup
programs by adding or setting the QAHA_TRACE system environment variable to '1'. This will
create log files in QUSRSYS/QAAHALOG. Files named QSBR<job number>, QSBE<job number,
and QEND<job number> will be created for each QAHASBMTER, QAHASBMTEE, and
QAHAPLTEND job that has run.
Managing agents
Use the agent console to connect to your domain and begin managing your agents. Find out how to
control the level of automation associated with your agents, and how to easily respond to requests and
track agent history.
The Intelligent Agents console is a powerful management tool that allows you to work with your agents,
and ensure that they are behaving in a manner that meets your expectations. To display the Intelligent
Agents node in System i Navigator, select View > Intelligent Agents from the main menu.
After you set up your agent environment, you can begin working with the agent console by connecting
to your host system (or systems) and creating an instance of an agent to run on that system. Use the
console to start, stop, suspend, delete, respond to, and view the history of the agents running on your
system or systems. You can also use the console to set up limitations on what actions an agent can
perform automatically and what actions require permission.
Automating agents
The agent console gives you the capability to control and customize an agent's behavior by associating a
level of automation with that agent.
The Intelligent Agents console provides a way for you to control the automated actions an agent can take.
To view an agent's capabilities, and change an agent's automation setting in System i Navigator, follow
these steps:
Procedure
1. Expand Intelligent Agents.
2. Expand your intelligent agent's platform.
3. Select All Agents.
4. Right-click the agent you want to work with and select Properties.
5. Select the Automation tab to display the agent's currently configured automation level.
6. Click Capabilities to display a list of the actions this agent can take, and the automation level
associated with these capabilities.
Figure 4. Viewing the automation level associated with the capabilities of a TimeMonitor agent
Every agent has a set of capabilities that define what kinds of actions that agent can perform. The agent
console displays an agent's available capabilities associated with the agent's corresponding automation
level. Each automation level setting (High automation, Medium automation, Low automation, and
Custom automation) will change the states (Automate, Ask first, Never ask) of the available capabilities
for the agent.
For example, if an agent has the capability to clear log files when full, when you change the level of
automation from High automation to Medium automation, the agent's capability changes from a state of
Automate to a state of Ask first. The agent now requests permission before it deletes a log file.
Specifying an agent's automation level will determine if an agent automatically performs an action, asks
before performing an action, or never performs an action. The possible automation values are:
v High automation
The agent will perform most actions automatically, but will ask before performing certain destructive
actions. Depending on the agent, certain actions may require that the agent always request outside
intervention before it performs that action, even when set to High automation.
v Medium automation
If the automation setting associated with an agent's capability is set to Ask first, before an agent
performs an action, the agent will request a response from a user. Some agents will always request a
response, regardless of their current automation setting. When an agent requests a response or is waiting
to perform an action, the agent's Status field displays Needs response.
Procedure
1. Expand Intelligent Agents.
2. Expand your intelligent agents platform.
3. Select All Agents.
4. Right-click the agent and select Respond.
5. Select the response you want to work with and click the Respond button. The agent will display the
problem it is currently seeking a response for.
6. Select a response from the list of possible responses in the Response field, and click OK.
You can also view a list of all current requests by selecting Current Requests under the main Intelligent
Agents menu.
The agent console allows you to view the history of an agent's requests and actions. The history does not
display current requests, only requests and actions that have been responded to. The history log is
limited to 1000 entries, and will clear the oldest entry for each new entry that exceeds 1000.
Procedure
1. Expand Intelligent Agents.
2. Expand your intelligent agents platform.
Results
IBM may not offer the products, services, or features discussed in this document in other countries.
Consult your local IBM representative for information on the products and services currently available in
your area. Any reference to an IBM product, program, or service is not intended to state or imply that
only that IBM product, program, or service may be used. Any functionally equivalent product, program,
or service that does not infringe any IBM intellectual property right may be used instead. However, it is
the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or
service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not grant you any license to these patents. You can send
license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property
Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
3-2-12, Roppongi, Minato-ku, Tokyo 106-8711
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some
states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically
made to the information herein; these changes will be incorporated in new editions of the publication.
IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in
any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of
the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
Such information may be available, subject to appropriate terms and conditions, including in some cases,
payment of a fee.
The licensed program described in this information and all licensed material available for it are provided
by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement,
IBM License Agreement for Machine Code, or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the
results obtained in other operating environments may vary significantly. Some measurements may have
been made on development-level systems and there is no guarantee that these measurements will be the
same on generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products and
cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal without
notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate
them as completely as possible, the examples include the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs
in any form without payment to IBM, for the purposes of developing, using, marketing or distributing
application programs conforming to the application programming interface for the operating platform for
which the sample programs are written. These examples have not been thoroughly tested under all
conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must include a copyright
notice as follows:
© (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. ©
Copyright IBM Corp. _enter the year or years_.
If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
Personal Use: You may reproduce these publications for your personal, noncommercial use provided that
all proprietary notices are preserved. You may not distribute, display or make derivative works of these
publications, or any portion thereof, without the express consent of IBM.
Commercial Use: You may reproduce, distribute and display these publications solely within your
enterprise provided that all proprietary notices are preserved. You may not make derivative works of
these publications, or reproduce, distribute or display these publications or any portion thereof outside
your enterprise, without the express consent of IBM.
Except as expressly granted in this permission, no other permissions, licenses or rights are granted, either
express or implied, to the publications or any information, data, software or other intellectual property
contained therein.
IBM reserves the right to withdraw the permissions granted herein whenever, in its discretion, the use of
the publications is detrimental to its interest or, as determined by IBM, the above instructions are not
being properly followed.
You may not download, export or re-export this information except in full compliance with all applicable
laws and regulations, including all United States export laws and regulations.
Printed in USA