  ù  ISO8859-1             |    ¨  :  ¼  >  ÷  &  6  &  ]    „    š  -  ² 	 -  à 
       ,  >  F  6  …  B  ¼  ;  ÿ   D  	; ! D  	€ "7  	Å #J  
ý <ÿ  H =	  H >c  R ?[  ¶ @   A   B¥  ## C¡  'É D¨  ,k E–  1 FÇ  5« Gñ  :s Hî  ?e I  DT Jè  Il K  NU LP  Sh M³  V¹ No  Zm Oa  ]Ý P\  a? Q³  dœ R½  iP S¸  n Tá  rÇ U¯  w© VÓ  |Y Wî  - Xþ  † Y  ‹ ZL  5 [_  ”‚ n‰  ™â o;  žl p.  ¡¨ q;  ¤× rI  ¨ sÁ  «] t €  ® uµ  ®  v#  ±V w5  ´z x9  ·° y;  ºê z;  ¾& {9  Áb |8  Äœ }>  ÇÕ ~<  Ë 9  ÎQ €"  Ñ‹ À  Ô® ‚Â  ×o ƒ$  Û2 „)  ßW …S  ã †.  çÕ ‡Q  ì ˆV  ðV ‰õ  ô­ Šú  ø£ ‹ô  üž Œµ  “ » I Ž¯   µ é · ‘t ¡ ’€  “x — ”„  •q • ––  —“ %ž ˜. -2 ™˜ 3a šÂ 9ú ›1 @½ œX Fï Ä MH ž T Ÿ_ [  V `r ¡7 fÉ ¢ê m £  rì ¤] y ¥ß ë ¦e …Ë §é ‹1 ¨è ’ ©R – ªS ™W «P œ« ¬z Ÿü ­t ¢w ® ¤ì ¯Û § °3 «Ý ±À ® ²À ¯Ò Èú ±“ æ ¸Ž çG ¾š èÕ Åâ   Ò Ë¸ 9 æ‹  <  Å  I   > L   m ‹ E ù  5 ?    u y •  2 !  0 !B   !s   !’   ¶ !ª > %a   )    )¸  = « )Ð æ :| Ý Kc Â \A å m  €ê  ”ý è © 	
M ¼ê 

° Ç8 
µ Ñé ¶ ÜŸ  êV ë üZ Ô F ¼  ß 1Ø â F¸ Á [› ­ p] X … ° ’d t   Ï ­Š ¹ »Z ¼ Í ¸ ÞÑ ^ ðŠ ä é ð Î j (¿  ó ;* !÷ N "E a #® v\ $© ƒ %´ µ &œ j 'á µ (“ Áé )} É} * B Ðû + B Ñ> , , Ñ - 5 Ñ® .  Ñä / @ Ò  0 A ÒA 1 C Òƒ 2 B ÒÇ 3 ! Ó
 4 ; Ó, 5 % Óh 6 B ÓŽ 7 ú ÓÑ 8 B ÔÌ 9 B Õ : B ÕR ; L Õ• < B Õâ = B Ö%    8 Öh  O Ö¡  X ÖñIBM data suppliers. Statistics provided by the harmld resource monitor daemon. Virtual Shared Disk server device statistics (locally served). Virtual Shared Disk driver statistics. Virtual Shared Disk device statistics. SP Switch statistics. LoadLeveler statistics. LoadLeveler statistics for the startd daemon. LoadLeveler statistics for the schedd daemon. Processors enabled statistic. harmld daemon statistics. Each L1 context contains up to 10 L2 contexts for VSD devices. Each L2 context contains up to 10 VSD device contexts. NodeNum: The number of the node for which the information applies. VSD: The name of the virtual shared disk device to monitor. STARTD: Name of the LoadLeveler startd daemon (the string "startd"). SCHEDD: Name of the LoadLeveler schedd daemon (the string "schedd"). L1: Level 1 instances of device Virtual Shared Disk variables. 
There are up to 10 Level 2 instance vectors for each Level 1 vector value. 
The Level 1 and Level 2 instance vectors are used to distribute the 
Virtual Shared Disk device variables on large systems for improved 
performance and viewing in xmperf. L2: Level 2 instances of device Virtual Shared Disk variables. 
There are up to 10 Virtual Shared Disk device instance vectors for each 
Level 2 vector value. The Level 1 and Level 2 instance vectors are used 
to distribute the Virtual Shared Disk device variables on large systems 
for improved performance and viewing in xmperf. The number of job steps managed by the LoadL_startd daemon.

IBM.PSSP.LL.STARTD.current_jobs provides a current snapshot
of the number of job steps that the LoadL_startd daemon
is managing.  The total current_jobs of all LoadL_startds
do not necessarily add up to the total number of jobs.
For parallel jobs, different LoadL_startds may be managing
the same job step.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
current_jobs variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.current_jobs
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 25

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs steps managed that are in the running state.

IBM.PSSP.LL.STARTD.jobs_running provides a current snapshot
of the number of job steps that the LoadL_startd daemon
is running.  The total jobs_running of all LoadL_startds
do not necessarily add up to the total number of running jobs.
For parallel jobs, different LoadL_startds may be running
the same job step.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
jobs_running variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.jobs_running
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 25

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs steps managed that are in the pending state.

IBM.PSSP.LL.STARTD.jobs_pending provides a current snapshot
of the number of job steps that the LoadL_startd daemon
is in the process of starting.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
jobs_pending variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.jobs_pending
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 25

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs steps managed that are in the suspended state.

IBM.PSSP.LL.STARTD.jobs_suspended provides a current snapshot
of the number of job steps that the LoadL_startd daemon
has suspended.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
jobs_suspended variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.jobs_suspended
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 25

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of start job requests that have been received by the startd.

IBM.PSSP.LL.STARTD.total_jobs_received represents a continuously
increasing accumulator of the number of job steps that the
LoadL_startd daemon has been asked to start. This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_jobs_received variable has not changed on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_jobs_received
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X == X@P

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs steps started that have been completed.

IBM.PSSP.LL.STARTD.total_jobs_completed represents a continuously
increasing accumulator of the number of job steps that the
LoadL_startd daemon started and ran to completion. This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_jobs_completed variable remains at 0 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_jobs_completed
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X == 0

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs steps canceled by the user, or by LoadLeveler.

IBM.PSSP.LL.STARTD.total_jobs_removed represents a continuously
increasing accumulator of the number of job steps that the
LoadL_startd daemon has put in the removed state. This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_jobs_removed variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_jobs_removed
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of jobs
removed exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs terminated and returned to be rescheduled.

IBM.PSSP.LL.STARTD.total_jobs_vacated represents a continuously
increasing accumulator of the number of job steps that the
LoadL_startd daemon has put in the vacated state. This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_jobs_vacated variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_jobs_vacated
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of jobs
vacated exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs that could not be run by the startd daemon.

IBM.PSSP.LL.STARTD.total_jobs_rejected represents a continuously
increasing accumulator of the number of job steps that the
LoadL_startd daemon has put in the rejected state.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_jobs_rejected variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_jobs_rejected
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of jobs
rejected exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of jobs suspended by the LoadL_startd daemon.

IBM.PSSP.LL.STARTD.total_jobs_suspended represents a continuously
increasing accumulator of the number of job steps that the
LoadL_startd daemon has suspended.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_jobs_suspended variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_jobs_suspended
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of jobs
suspended exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of connections attempted by the LoadL_startd daemon.

IBM.PSSP.LL.STARTD.total_connections represents a continuously
increasing accumulator of the number of connections that the
LoadL_startd daemon has attempted between other LoadLeveler
daemons or commands.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_connections variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_connections
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total connections exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The total number of connection attempts that have been unsuccessful.

IBM.PSSP.LL.STARTD.failed_connections represents a continuously
increasing accumulator of the number of connections that were
unsuccessful when the LoadL_startd daemon attempted to connect with
other LoadLeveler daemons or commands.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
failed_connections variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.failed_connections
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful connections exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of outbound transactions that have been attempted.

IBM.PSSP.LL.STARTD.total_out_transactions represents a continuously
increasing accumulator of the total number of outbound transactions
that the LoadL_startd daemon has attempted between other LoadLeveler
daemons or commands.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_out_transactions variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_out_transactions
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total outbound transactions exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of outbound transaction attempts that were unsuccessful.

IBM.PSSP.LL.STARTD.failed_out_transactions represents a continuously
increasing accumulator of the number of outbound transactions that
were unsuccessful when the LoadL_startd daemon attempted to communicate
with other LoadLeveler daemons or commands.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
failed_out_transactions variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.failed_out_transactions
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful outbound transactions exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of inbound transactions that have been attempted.

IBM.PSSP.LL.STARTD.total_in_transactions represents a continuously
increasing accumulator of the total number of inbound transactions
that the LoadL_startd daemon has attempted between other LoadLeveler
daemons or commands.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
total_in_transactions variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.total_in_transactions
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total inbound transactions exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless. The number of inbound transaction attempts that were unsuccessful.

IBM.PSSP.LL.STARTD.failed_in_transactions represents a continuously
increasing accumulator of the number of inbound transactions that
were unsuccessful when the LoadL_startd daemon attempted to communicate
with other LoadLeveler daemons or commands.  This counter is
initialized to 0 during each LoadL_startd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
startd daemon. For example, to register an event that the startd
failed_in_transactions variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.STARTD.failed_in_transactions
    Resource ID:       NodeNum=5;STARTD=startd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful inbound transactions exceeds 50.

Resource ID wildcarding:

The STARTD and NodeNum elements may be wildcarded but only one
instance per node is generated for the STARTD element regardless.
 The number of job steps managed by the LoadL_schedd daemon.

IBM.PSSP.LL.SCHEDD.current_jobs provides a current snapshot
of the number of job steps that this LoadL_schedd daemon
is managing.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
current_jobs variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.current_jobs
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs in idle state managed by the LoadL_schedd daemon.

IBM.PSSP.LL.SCHEDD.jobs_idle provides a current snapshot
of the number of job steps that this LoadL_schedd daemon
manages which are in the process of being considered to run
on a machine, but no machine has been selected yet.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
jobs_idle variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.jobs_idle
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs managed that are in the pending state.

IBM.PSSP.LL.SCHEDD.jobs_pending provides a current snapshot
of the number of job steps that this LoadL_schedd daemon
manages which are in the process of starting.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
jobs_pending variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.jobs_pending
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs managed that are in the starting state.

IBM.PSSP.LL.SCHEDD.jobs_starting provides a current snapshot
of the number of job steps that this LoadL_schedd daemon
manages which are starting.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
jobs_starting variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.jobs_starting
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs managed that are in the running state.

IBM.PSSP.LL.SCHEDD.jobs_running provides a current snapshot
of the number of job steps that this LoadL_schedd daemon
manages which are running.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
jobs_running variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.jobs_running
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The total number of job steps submitted to the schedd.

IBM.PSSP.LL.SCHEDD.total_jobs_submitted represents a continuously
increasing accumulator of the number of job steps that the
LoadL_schedd daemon has been asked to manage. This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_jobs_submitted variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_jobs_submitted
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total_jobs_submitted transactions exceeds 25.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. THe number of jobs steps submitted that have completed.

IBM.PSSP.LL.SCHEDD.total_jobs_completed represents a continuously
increasing accumulator of the number of job steps managed by the
LoadL_schedd daemon that have run to completion. This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_jobs_completed variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_jobs_completed
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total_jobs_completed transactions exceeds 25.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs canceled by the user, or by LoadLeveler.

IBM.PSSP.LL.SCHEDD.total_jobs_removed represents a continuously
increasing accumulator of the number of job steps managed by the
LoadL_schedd daemon that have been canceled. This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_jobs_canceled variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_jobs_canceled
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total_jobs_canceled transactions exceeds 25.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs terminated and returned to be rescheduled.

IBM.PSSP.LL.SCHEDD.total_jobs_vacated represents a continuously
increasing accumulator of the number of job steps managed by the
LoadL_schedd daemon that were terminated and returned to the queue
to be rescheduled.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_jobs_vacated variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_jobs_vacated
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total_jobs_vacated transactions exceeds 25.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of jobs submitted that could not be run.

IBM.PSSP.LL.SCHEDD.total_jobs_rejected represents a continuously
increasing accumulator of the number of job steps managed by the
LoadL_schedd daemon that could not be run. This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_jobs_rejected variable has exceeded 25 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_jobs_rejected
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 25

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total_jobs_rejected transactions exceeds 25.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of connections that have been attempted by LoadL_schedd.

IBM.PSSP.LL.SCHEDD.total_connections represents a continuously
increasing accumulator of the number of connections that the
LoadL_schedd daemon has attempted between other LoadLeveler
daemons or commands.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_connections variable has exceeded 1000 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_connections
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 1000

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
total connections exceeds 1000.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The total number of connection attempts that were unsuccessful.

IBM.PSSP.LL.SCHEDD.failed_connections represents a continuously
increasing accumulator of the number of connections that were
unsuccessful when the LoadL_schedd daemon attempted to connect with
other LoadLeveler daemons or commands.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
failed_connections variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.failed_connections
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful connections exceeds 50.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of outbound transactions that were attempted by LoadL_schedd.

IBM.PSSP.LL.SCHEDD.total_out_transactions represents a continuously
increasing accumulator of the total number of outbound transactions
that the LoadL_schedd daemon has attempted between other LoadLeveler
daemons or commands.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_out_transactions variable has exceeded 1000 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_out_transactions
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 1000

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful connections exceeds 1000.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of outbound transaction attempts that were unsuccessful.

IBM.PSSP.LL.SCHEDD.failed_out_transactions represents a continuously
increasing accumulator of the number of outbound transactions that
were unsuccessful when the LoadL_schedd daemon attempted to communicate
with other LoadLeveler daemons or commands.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
failed_out_transactions variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.failed_out_transactions
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful outbound transactions exceeds 50.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of inbound transactions that were attempted by LoadL_schedd.

IBM.PSSP.LL.SCHEDD.total_in_transactions represents a continuously
increasing accumulator of the total number of inbound transactions
that the LoadL_schedd daemon has attempted between other LoadLeveler
daemons or commands.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
total_in_transactions variable has exceeded 1000 on node number 5, the
variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.LL.SCHEDD.total_in_transactions
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 1000

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of inbound transaction attempts that were unsuccessful.

IBM.PSSP.LL.SCHEDD.failed_in_transactions represents a continuously
increasing accumulator of the number of inbound transactions that
were unsuccesful when the LoadL_schedd daemon attempted to communicate
with other LoadLeveler daemons or commands.  This counter is
initialized to 0 during each LoadL_schedd daemon's startup and
is not reset during the life of the daemon.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.
\n
The resource variable's resource ID specifies the node number of
the variable and the variable instance for the LoadLeveler
schedd daemon. For example, to register an event that the schedd
failed_in_transactions variable has exceeded 50 on node number 5, the
variable, resource ID and expression would be:

IBM.PSSP.LL.SCHEDD.failed_in_transactions
		NodeNum=5;SCHEDD=schedd   X > 50
    Resource Variable: IBM.PSSP.LL.SCHEDD.failed_in_transactions
    Resource ID:       NodeNum=5;SCHEDD=schedd
    Expression:        X > 50

This event registration may also want to define a re-arm expression so
that the client only gets one notification when the number of
unsuccessful inbound transactions exceeds 50.

Resource ID wildcarding:

The SCHEDD and NodeNum elements may be wildcarded but only one
instance per node is generated for the SCHEDD element regardless. The number of requests queued which are waiting for a request block.

The VSD driver keeps a pool of free request blocks to carry out user
requests as needed. When there are no free request blocks, then the
user request is queued waiting for a request block to free up.  The
request shortage count is incremented whenever this happens.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a shortage for a request block occurs
on node number 5, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.request_block_shortage
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Example: To be informed whenever a shortage for a request block occurs
on any node in the domain, one could register for an event with the
disgnations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.request_block_shortage
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests queued which are waiting for a pbuf.

The VSD driver keeps a pool of free pbuf structures to carry out the
requests to the logical volume as needed.  When there are no free pbuf
structures, then the request is queued waiting for a pbuf structure to
free up.  The pbuf shortage count is incremented whenever this happens.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a shortage for a pbuf occurs, one
could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.pbuf_shortage
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests queued which are waiting for a cache block.

The VSD driver keeps a pool of free cache blocks to carry out requests
as needed.  When there are no free cache blocks, then the request is
queued waiting for a cache block to free up.  The cache block shortage
count is incremented whenever this happens.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a shortage for a cache block occurs,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.cache_shortage
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests queued which are waiting for a buddy buffer.

The VSD driver keeps a pool of free buddy buffers to carry out requests
as needed.  When there are no free buddy buffers, then the request is
queued waiting for a buddy buffer to free up.  The buddy buffer
shortage count is incremented whenever this happens.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a shortage for a buddy buffer occurs,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.buddy_buffer_shortage
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of rejected requests.

The VSD driver will reject a request for the reasons that follow; the VSD
driver incarnation number does not match the request's incarnation
number, the request's sequence id is not valid, or this packet falls
outside of the message.  The rejected request count is incremented
whenever one of the above conditions is detected.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a request is rejected, one could
register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.rejected_requests
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of rejected responses.

The VSD driver will reject a response from a remote VSD server when it
cannot find the matching request for the response.  The rejected
response count is incremented whenever this happens.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a response is rejected, one could
register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.rejected_responds
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. Rejected no buddy buffer.

This counter is no longer used in the current VSD driver.  It was
used by KCI when KCI was supported. The number of requests which require rework.

This counter is incremented whenever the data being copied to the user
buffer or from the user buffer is unsuccessful.  The copy request is
queued and retried later.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a request requires rework, one could
register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.request_rework
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of timeouts.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  When the
retry count is exhausted, then the Timeouts counter is incremented
and the request is unsuccessful.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a timeout occurs, one could register
for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.timeout_error
   Resource ID:            NodeNum=*
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least one retry.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the first retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a first retry on node 5 occurs, one
could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.1_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least two retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the second retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a second retry on node 5 occurs, one
could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.2_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least three retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the third retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a third retry on node 5 occurs, one 
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.3_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least four retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the fourth retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a fourth retry on node 5 occurs, one
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.4_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least five retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the fifth retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a fifth retry on node 5 occurs, one
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.5_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least six retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the sixth retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a sixth retry on node 5 occurs, one
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.6_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least seven retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the seventh retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a seventh retry on node 5 occurs, one
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.7_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least eight retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the eighth retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a eighth retry on node 5 occurs, one
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.8_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of requests that had at least nine retries.

The VSD driver keeps a timer and retry count for every remote request.
When the timer expires for a request that has not completed, the
request will be retried if the retry count is not exhausted.  If this
retry is the ninth retry for this request, then this counter is
incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever a ninth retry on node 5 occurs, one
could register for the event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.9_retry_count
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The average buddy buffer wait_queue size.

The VSD driver keeps a running sum counter of buddy buffer shortages
and a counter of the requests that might require a buddy buffer.  By
dividing these counters, an average number of requests that had to wait
for a buddy buffer is obtained.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the average number of requests that
had to wait was greater then 5, one could register for an event with
the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.avg_buddy_wait
   Resource ID:            NodeNum=5
   Expression:             X > 5

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. I/O is not performed directly from the mbuf.

The VSD driver keeps a counter of when the i/o has to use a buddy
buffer.  This indicates that the i/o could not be done directly to or
from the mbuf, hence, indirect i/o.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the i/o has to use a buddy buffer, one
could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.indirect_io
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. Shortage on the Communication Buffer pool.

The VSD driver will attempt to use the communications adapter buffer
pool if supported and conditions are correct for its use. If an attempt
is made and is unsuccessful, then the counter for communications adapter
buffer shortage is incremented.  This counter would be an indication
that better performance is possible if the amount of communications
adapter buffer pool could be increased.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the attempt to use the communications
adapter buffer is unsuccessful, one could register for an event with
the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.comm_buf_shortage
   Resource ID:            NodeNum=5
   Expression:             X@R > X@PR

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain. The number of local read requests.

In the case where the VSD driver is performing as the server node for
the VSD and has received a local read request for that VSD, it keeps a
count of the number of local read requests for the VSD that it
receives.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of local reads exceeds 25,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.local_req_read
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of local write requests.

In the case where the VSD driver is performing as the server node for
the VSD and has received a local write request for that VSD, it keeps a
count of the number of local write requests for the VSD that it
receives.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of local writes exceeds 25,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.local_req_write
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of remote read requests.

In the case where the VSD driver is performing as the server node for
the VSD and has received a remote read request for that VSD, it keeps a
count of the number of remote read requests for the VSD that it
receives.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of remote reads for the
vsd named <vsdn21> on node 5 exceeds 25, one could register for
an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.remote_req_read
   Resource ID:            VSD=vsdn21;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of remote write requests.

In the case where the VSD driver is performing as the server node for
the VSD and has received a remote write request for that VSD, it keeps
a count of the number of remote write requests for the VSD that it
receives.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of remote writes exceeds 25,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.remote_req_write
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of client read requests.

In the case where the VSD driver is performing as a client node for the
remote VSD and has received a local read request for the remote VSD, it
keeps a count of the number of local read requests for the VSD that it
must send to the remote VSD server node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of remote reads exceeds 25,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.client_req_read
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of client write requests.

In the case where the VSD driver is performing as a client node for the
remote VSD and has received a local write request for the remote VSD, it
keeps a count of the number of local write requests for the VSD that it
must send to the remote VSD server node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of remote writes exceeds 25,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.client_req_write
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of physical reads.

In the case where the VSD driver is performing as the server node for
the VSD and is doing a read i/o to the logical volume, it increments
the physical read counter.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of physcial reads exceeds
25, one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.physical_req_read
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of physical writes.

In the case where the VSD driver is performing as the server node for
the VSD and is doing a write i/o to the logical volume, it increments
the physical write counter.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of physcial writes exceeds
25, one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.physical_req_write
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 25

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of cache hits.

In the case where the VSD driver is performing as the server node for
the VSD and the data for a remote read request is found in the cache,
this counter is incremented.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of cache hits on node 5
exceeds 50, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSD.cache_hits
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 50

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element valuess are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The total number of bytes (read).

The VSD driver keeps a running count of the number of 512 byte blocks
per VSD that it reads.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of 512 byte blocks read
exceeds 2,048, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSD.bytes_read
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 2,048

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The total number of bytes (write).

The VSD driver keeps a running count of the number of 512 byte blocks
per VSD that it writes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the value of 512 byte blocks written
exceeds 2,048, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSD.bytes_write
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 2,048

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. VSD state: STOPPED/ACTIVE/SUSPENDED.

This is the state that the VSD is in.  It can be one of the three
states, STOPPED, ACTIVE, or SUSPENDED.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the state of a VSD is not active,
one could register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.state
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X@R != 2

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. Current VSD server.

All nodes that can be either client VSD nodes or server VSD nodes are
assigned a logical cpu number.  This is the logical cpu number for the
server node for this VSD.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor. The total number of data blocks read or written.

The VSD subsystem can be queried for the total number of data
blocks read or written,  to or from this VSD, or its rate.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the rate of blocks read and written
on node 5 exceeds 5,000 one could register for an event with the
designations that follow:

   Resource Variable Name: IBM.PSSP.VSD.blocks_rw
   Resource ID:            VSD=*;NodeNum=5;L1=*;L2=*
   Expression:             X > 5000

Resource ID wildcarding:

Both the "NodeNum" and "VSD" resource ID elements may be wildcarded.
If the "VSD" resource ID element is wildcarded, the query or event
registration will be applied to all VSDs on the target node or nodes.
Wildcarding "NodeNum" will apply the action to all nodes in the
domain.

Note: Since the "L1" and "L2" resource ID element values are arbitrary numbers
and cannot be predicted, it is recommended that they always be wildcarded. The number of VSDs that are active on this node.

The VSD subsystem can be queried for the number of VSDs that are
active on the node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the number of active VSDs on node 5
changes, one could register for an event with the designations that
follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.num_active
   Resource ID:            NodeNum=5
   Expression:             X != X@P

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to
apply a query or event registration to all nodes within the domain. The number of VSDs that are suspended on this node.

The VSD subsystem can be queried for the number of VSDs that are
suspended on the node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the number of suspended VSDs on
node 5 changes, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.num_suspended
   Resource ID:            NodeNum=5
   Expression:             X != X@P

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to
apply a query or event registration to all nodes within the domain. The number of VSDs that are stopped on this node.

The VSD subsystem can be queried for the number of VSDs that are
stopped on the node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the number of stopped VSDs on
node 5 changes, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.num_stopped
   Resource ID:            NodeNum=5
   Expression:             X != X@P

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to
apply a query or event registration to all nodes within the domain. The number of VSDs that are not active on this node.

The VSD subsystem can be queried for the number of VSDs that are not
active on the node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example: To be informed whenever the number of not active VSDs on
node 5 changes, one could register for an event with the designations
that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.num_not_active
   Resource ID:            NodeNum=5
   Expression:             X != X@P

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to
apply a query or event registration to all nodes within the domain. The state of the RVSD on this node.

The VSD subsystem can be queried for the state of RVSD on the node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

   The possible states are:
     (-2) RVSD_Can_Not_Tell
     (-1) RVSD_NotAvail
     ( 0) RVSD_Idle
     ( 1) RVSD_Activating
     ( 2) RVSD_Node_Join
     ( 3) RVSD_Node_Recovery
     ( 4) RVSD_Fence
     ( 5) RVSD_Quorum
     ( 6) RVSD_Tail_Recoveryn
     ( 7) RVSD_Wait_GS
     ( 8) RVSD_Refresh

Example: To be informed whenever node 5 is changing states, one could
register for an event with the designations that follow:

   Resource Variable Name: IBM.PSSP.VSDdrv.RVSD_status
   Resource ID:            NodeNum=5
   Expression:             X != X@P

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to
apply a query or event registration to all nodes within the domain. The number of packets received on the interface (msw bits 61-31).

A message sent to a node over the Communication SubSystem (CSS)
switch is comprised of packets.  IBM.PSSP.CSS.ipackets_msw is a portion
of the count of packets sent successfully over the switch to the subject
node, since that interface was last initialized.

IBM.PSSP.CSS.ipackets_msw is the most significant word of the count of
packets received by the subject node on its CSS interface.
The variable IBM.PSSP.CSS.ipackets_msw (bits 61-31) may be prepended to
its companion IBM.PSSP.CSS.ipackets_lsw (bits 30-0) to form a 62-bit
counter of inbound CSS packets.

This is a total count of protocol-level (IP, MPI, and switch service)
packets received by the node since the node's CSS interface was last
initialized.  For performance reasons, this count is only updated
approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when IBM.PSSP.CSS.ipackets_lsw -- bits 30-0 of the
received packet count -- first rolls over on node 5, register for the
event that follows:

      Resource variable:  IBM.PSSP.CSS.ipackets_msw
      Resource ID:        NodeNum=5
      Expression:         X>0
      Re-arm expression:  X==0

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_lsw     Total number (lsw bits 30-0) of octets received.
  IBM.PSSP.CSS.ibytes_msw     Total number (msw bits 31-61) of octets received.
  IBM.PSSP.CSS.ipackets_dlt   Packets received on interface (delta).
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0). The number of packets received on the interface (lsw bits 30-0).

A message received by a node over the switch of the Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.ipackets_lsw is a
portion of the count of packets sent successfully over the switch to the
subject node, since that interface was last initialized.

IBM.PSSP.CSS.ipackets_lsw is the least significant word of the count
of packets received by the subject node on its CSS interface.
IBM.PSSP.CSS.ipackets_lsw (bits 30-0) may be appended to its companion
IBM.PSSP.CSS.ipackets_msw (bits 61-31) to form a 62-bit counter of
inbound CSS packets.

This is a total count of protocol-level (IP, MPI, and switch service)
packets received by the node since the node's CSS interface was last
initialized.  For performance reasons, this count is only updated
approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed each time IBM.PSSP.CSS.ipackets_lsw exceeds 1024
on any node (initially or following a roll over of the value),
register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.ipackets_lsw
      Resource ID:        NodeNum=*
      Expression:         X>1024
      Re-arm expression:  X<=1024

Of course, such a notification can only occur once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_lsw     Total number (lsw bits 30-0) of octets received.
  IBM.PSSP.CSS.ibytes_msw     Total number (msw bits 31-61) of octets received.
  IBM.PSSP.CSS.ipackets_dlt   Packets received on interface (delta).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The number of packets received on the interface (delta).

A message sent to a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.ipackets_dlt is
the change, since the previous sample, in the total count of packets
received by the subject node on its CSS interface.

This is a total count of protocol-level (IP, MPI, and switch service)
packets received by the node.  For performance reasons, such counts are
only updated approximately once every 2 minutes.

IBM.PSSP.CSS.ipackets_dlt constitutes the increase, since the previous
sample, in the 62-bit counter comprised of the pair of variables
IBM.PSSP.CSS.ipackets_msw and IBM.PSSP.CSS.ipackets_lsw.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed whenever IBM.PSSP.CSS.ipackets_dlt is zero on node 5,
register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.ipackets_dlt
      Resource ID:        NodeNum=5
      Expression:         X==0

This event can occur, at most, once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_dlt     Total number of octets received (delta).
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The total number (msw bits 31-61) of octets received.

A message received by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets, and each such packet consists
of a string of bytes, or bit octets.  IBM.PSSP.CSS.ibytes_msw is the
most significant word of the count of octets received by the subject
node on its CSS interface, since that interface was last initialized.

The variable IBM.PSSP.CSS.ibytes_msw (bits 61-31) may be prepended to
its companion IBM.PSSP.CSS.ibytes_lsw (bits 30-0) to form a 62-bit
counter of incoming CSS octets.  For performance reasons, such counts
are only updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when IBM.PSSP.CSS.ibytes_lsw first rolls over on any node,
register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.ibytes_msw
      Resource ID:        NodeNum=*
      Expression:         X>0
      Re-arm expression:  X==0

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_dlt     Total number of octets received (delta).
  IBM.PSSP.CSS.ibytes_lsw     Total number (lsw bits 30-0) of octets received.
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The total number (lsw bits 30-0) of octets received.

A message received by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets, and each such packet consists
of a string of bytes, or bit octets.  IBM.PSSP.CSS.ibytes_lsw is the
least significant word of the count of octets received by the subject
node on its CSS interface, since that interface was last initialized.

The variable IBM.PSSP.CSS.ibytes_lsw (bits 30-0) may be appended to its
companion IBM.PSSP.CSS.ibytes_msw (bits 61-31) to form a 62-bit counter
of incoming CSS octets.  For performance reasons, such counts are only
updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed each time IBM.PSSP.CSS.ibytes_lsw exceeds 4K on
any node (initially or following a roll over of the counter),
register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.ibytes_lsw
      Resource ID:        NodeNum=*
      Expression:         X>4096
      Re-arm expression:  X<=4096

Of course, such a notification can only occur once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_dlt     Total number of octets received (delta).
  IBM.PSSP.CSS.ibytes_msw     Total number (msw bits 31-61) of octets received.
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The total number of octets received (delta).

A message received by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets, and each such packet consists
of a string of bytes, or bit octets. IBM.PSSP.CSS.ibytes_dlt is the
change, since the previous sample, in the total count of octets received
by the subject node at its CSS interface.

IBM.PSSP.CSS.ibytes_dlt constitutes the increase, since the previous
sample, in the 62-bit counter comprised of the pair of variables
IBM.PSSP.CSS.ibytes_msw and IBM.PSSP.CSS.ibytes_lsw.  For performance
reasons, such counts are only updated approximately once every
2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when IBM.PSSP.CSS.ibytes_dlt falls below 30 on node 4,
register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.ibytes_dlt
      Resource ID:        NodeNum=4
      Expression:         X<30
      Re-arm expression:  X>=30

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_dlt     Total number of octets received (delta).
  IBM.PSSP.CSS.ibytes_msw     Total number (msw bits 31-61) of octets received.
  IBM.PSSP.CSS.ipackets_dlt   Packets received on interface (delta). The number of receive interrupts (msw bits 61-31).

A message received by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.recvintr_msw is
the most significant word of the count of interrupts raised by the
adapter microcode to cause the subject node's CSS software to handle
incoming CSS packets, since that interface was last initialized.

The variable IBM.PSSP.CSS.recvintr_msw (bits 61-31) may be prepended to
its companion IBM.PSSP.CSS.orecvintr_lsw (bits 30-0) to form a 62-bit
counter of receive interrupts raised by the CSS interface.  For
performance reasons, such counts are only updated approximately once
every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when IBM.PSSP.CSS.recvinit_msw becomes non-zero on node
12, register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.recvinit_msw
      Resource ID:        NodeNum=12
      Expression:         X>0
      Re-arm expression:  X==0

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31).
  IBM.PSSP.CSS.recvintr_dlt   Number of receive interrupts (delta).
  IBM.PSSP.CSS.recvintr_lsw   Number of receive interrupts (lsw bits 30-0). The number of receive interrupts (lsw bits 30-0).

A message received by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.recvintr_lsw is
the least significant word of the count of interrupts raised by the
adapter microcode to cause the subject node's CSS software to handle
incoming CSS packets, since that interface was last initialized.

The variable IBM.PSSP.CSS.recvintr_lsw (bits 30-0) may be appended to
its companion IBM.PSSP.CSS.recvintr_msw (bits 61-31) to form a 62-bit
counter of receive interrupts raised by the CSS interface.  For
performance reasons, such counts are only updated approximately once
every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed each time IBM.PSSP.CSS.recvinit_lsw exceeds 2K on
any node (initially or following a roll over of the value), register
for the event that follows:

      Resource variable:  IBM.PSSP.CSS.recvinit_lsw
      Resource ID:        NodeNum=*
      Expression:         X>2048
      Re-arm expression:  X<=2048

This event can occur, at most, once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31).
  IBM.PSSP.CSS.recvintr_dlt   Number of receive interrupts (delta).
  IBM.PSSP.CSS.recvintr_msw   Number of receive interrupts (msw bits 61-31). The number of receive interrupts (delta).

A message sent to a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.recvintr_dlt is
the change, since the previous sample, in the total count of receive
interrupts raised by the subject node's CSS interface.  These interrupts
are used by the adapter microcode to notify the node that incoming
packets are available to be processed.  These interrupts might only be
sent to avoid possible backup of the CSS interface.

IBM.PSSP.CSS.recvintr_dlt constitutes the increase, since the previous
sample, in the 62-bit counter comprised of the pair of variables
IBM.PSSP.CSS.recvintr_msw and IBM.PSSP.CSS.recvintr_lsw.  For
performance reasons, such counts are only updated approximately once
every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To receive a notification each time IBM.PSSP.CSS.recvinit_dlt falls
below 10 on any node, register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.recvinit_dlt
      Resource ID:        NodeNum=*
      Expression:         X<10
      Re-arm expression:  X>=10

This event can occur at most once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_dlt     Total number of octets received (delta).
  IBM.PSSP.CSS.ipackets_dlt   Packets received on interface (delta).
  IBM.PSSP.CSS.recvintr_lsw   Number of receive interrupts (lsw bits 30-0).
  IBM.PSSP.CSS.recvintr_msw   Number of receive interrupts (msw bits 61-31). The number of input errors on the CSS interface.

Errors may be seen at a node's interface to the switch of the Communi-
cation SubSystem (CSS).  IBM.PSSP.CSS.ierrors is the count of errors
seen on the receive side of that CSS interface for the subject node,
since that interface was last initialized.  For performance reasons,
such counts are only updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when such an error occurs on any node, register for the
event that follows:

      Resource variable:  IBM.PSSP.CSS.ierrors
      Resource ID:        NodeNum=*
      Expression:         X!=X@P

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibytes_lsw     Total number (lsw bits 30-0) of octets received.
  IBM.PSSP.CSS.ibytes_msw     Total number (msw bits 31-61) of octets received.
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The number of packets sent on the interface (msw bits 61-31).

A message sent by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.opackets_msw is
the most significant word of the count of packets sent out by the
subject node on its CSS interface, since that interface was last
initialized.

The variable IBM.PSSP.CSS.opackets_msw (bits 61-31) may be prepended to
its companion IBM.PSSP.CSS.opackets_lsw (bits 30-0) to form a 62-bit
counter of outbound CSS packets.  For performance reasons, such counts
are only updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when IBM.PSSP.CSS.opackets_lsw first rolls over on any
node, register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.opackets_msw
      Resource ID:        NodeNum=*
      Expression:         X>0
      Re-arm expression:  X==0

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_lsw     Total number of octets sent (lsw bits 30-0).
  IBM.PSSP.CSS.obytes_msw     Total number of octets sent (msw bits 61-31).
  IBM.PSSP.CSS.opackets_dlt   Packets sent on interface (delta).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31). The number of packets sent on the interface (lsw bits 30-0).

A message sent by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.opackets_lsw is
the least significant word of the count of packets sent out by the
subject node on its CSS interface, since that interface was last
initialized.

The variable IBM.PSSP.CSS.opackets_lsw (bits 30-0) may be appended to
its companion IBM.PSSP.CSS.opackets_msw (bits 61-31) to form a 62-bit
counter of outbound CSS packets.  For performance reasons, such counts
are only updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed each time IBM.PSSP.CSS.opackets_lsw exceeds 2K on any
node (initially or following a roll over of the value), register for
the event that follows:

      Resource variable:  IBM.PSSP.CSS.opackets_lsw
      Resource ID:        NodeNum=*
      Expression:         X>2048
      Re-arm expression:  X<=2048

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_lsw     Total number of octets sent (lsw bits 30-0).
  IBM.PSSP.CSS.obytes_msw     Total number of octets sent (msw bits 61-31).
  IBM.PSSP.CSS.opackets_dlt   Packets sent on interface (delta).
  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0). The number of packets sent on the interface (delta).

A message sent by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.opackets_dlt is
the change, since the previous sample, in the total count of packets
sent out by the subject node on its CSS interface.

IBM.PSSP.CSS.opackets_dlt constitutes the increase, since the previous
sample, in the 62-bit counter comprised of the pair of variables
IBM.PSSP.CSS.opackets_msw and IBM.PSSP.CSS.opackets_lsw.  For
performance reasons, such counts are only updated approximately once
every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To receive a notification each time IBM.PSSP.CSS.opackets_dlt falls
below 50 on node 3, register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.opackets_dlt
      Resource ID:        NodeNum=3
      Expression:         X<50
      Re-arm expression:  X>=50

This event can occur at most once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_dlt     Total number of octets sent (delta).
  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31). The total number of octets sent (msw bits 61-31).

A message sent to a node over the Communication SubSystem (CSS)
switch is comprised of packets, and each such packet consists of a
string of bytes, or bit octets. IBM.PSSP.CSS.obytes_msw is the most
significant word of the count of octets sent out by the subject node
on its CSS interface, since that interface was last initialized.

The variable IBM.PSSP.CSS.obytes_msw (bits 61-31) may be prepended to its
companion IBM.PSSP.CSS.obytes_lsw (bits 30-0) to form a 62-bit counter
of outbound CSS packets. For performance reasons, such counts are only
updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when IBM.PSSP.CSS.obytes_msw -- bits 30-0 of the
received packet count -- first rolls over on node 5, register for the
event that follows:

      Resource variable:  IBM.PSSP.CSS.obytes_msw
      Resource ID:        NodeNum=5
      Expression:         X>0
      Re-arm expression:  X==0

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_dlt     Total number of octets sent (delta).
  IBM.PSSP.CSS.obytes_lsw     Total number of octets sent (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31). The total number of octets sent (lsw bits 30-0).

A message sent by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets, and each such packet consists of
a string of bytes, or bit octets. IBM.PSSP.CSS.obytes_lsw is the least
significant word of the count of octets sent out by the subject node
on its CSS interface, since that interface was last initialized.

The variable IBM.PSSP.CSS.obytes_lsw (bits 30-0) may be appended to its
companion IBM.PSSP.CSS.obytes_msw (bits 61-31) to form a 62-bit counter
of outbound CSS octets.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed each time IBM.PSSP.CSS.obytes_lsw exceeds 1024 on any
node (initially or following a roll over of the value), register for
the event that follows:

      Resource variable:  IBM.PSSP.CSS.obytes_lsw
      Resource ID:        NodeNum=*
      Expression:         X>1024
      Re-arm expression:  X<=1024

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_dlt     Total number of octets sent (delta).
  IBM.PSSP.CSS.obytes_msw     Total number of octets sent (msw bits 61-31).
  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31). The total number of octets sent (delta).

A message sent from a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets, and each such packet consists
of a string of bytes, or bit octets.  IBM.PSSP.CSS.obytes_dlt is the
change, since the previous sample, in the total count of octets received
by the subject node on its CSS interface.

IBM.PSSP.CSS.obytes_dlt constitutes the increase, since the previous
sample, in the 62-bit counter comprised of the pair of variables
IBM.PSSP.CSS.obytes_msw and IBM.PSSP.CSS.obytes_lsw.  For performance
reasons, counts such as this are only updated approximately once every
2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To receive a notification each time IBM.PSSP.CSS.obytes_dlt falls below 30
on node 4, register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.obytes_dlt
      Resource ID:        NodeNum=4
      Expression:         X<30
      Re-arm expression:  X>=30

This event can occur at most once every 2 minutes.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_lsw     Total number of octets sent (lsw bits 30-0).
  IBM.PSSP.CSS.obytes_msw     Total number of octets sent (msw bits 61-31). The number of output errors on the interface.

Errors may be seen at a node's interface to the switch of the SP
Communication SubSystem (CSS).  IBM.PSSP.CSS.oerrors is the count of
errors on the send side of that CSS interface for the subject node,
since that interface was last initialized.  For performance reasons,
such counts are only updated approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be informed when such an error first occurs on node 9, register for
the event that follows:

      Resource variable:  IBM.PSSP.CSS.oerrors
      Resource ID:        NodeNum=9
      Expression:         X>0
      Re-arm expression:  X==0

Of course, notification can only be promised within 2 minutes of the
actual event.

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_lsw     Total number of octets sent (lsw bits 30-0).
  IBM.PSSP.CSS.obytes_msw     Total number of octets sent (msw bits 61-31).
  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31). The number of packets not passed up.

A message received by a node from the switch of the Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.ipackets_drop is
the count of the number of good incoming packets at the subject node's
CSS interface which were dropped by the adapter microcode, since that
interface was last initialized.

If a node has too heavy a general workload, it may not service its CSS
interface often enough, causing its messages to linger in the switch
network.  If this is allowed to continue, the switch can become backed
up causing other nodes to encounter poor switch performance; in fact,
this condition can cause the entire switch to clog.  Instead, the
adapter microcode drops any "excess" packet -- a reliable protocol will
eventually retry the message.

For performance reasons, counts such as this are only updated
approximately once every 2 minutes.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Example expression:

To be notified when IBM.PSSP.CSS.ipackets_drop exceeds 100 on any
node, register for the event that follows:

      Resource variable:  IBM.PSSP.CSS.ipackets_drop
      Resource ID:        NodeNum=*
      Expression:         X>100
      Re-arm expression:  X<100

Resource ID wildcarding:

The resource variable's resource ID is used to specify the number of
the node (NodeNum) to be monitored. The NodeNum resource ID element
value may be wildcarded to apply a query or event registration
to all nodes in the domain.

Related Resource Variables:

  IBM.PSSP.CSS.ibadpackets    Number of bad packets received by the adapter.
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The number of bad packets received by the adapter.

A message received by a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.ibadpackets is
the count of badly formed incoming packets at the CSS interface of
the subject node, since that interface was last initialized.  This
counter is not supported due to the design outlined below.

When a bad packet is received, the incident is logged by CSS recovery
code; the log includes several bytes from the bad packet.  The bad packet
is then ignored, and CSS resumes normal activity until the number of bad
packets achieves a threshold, at which point the node is fenced from the
switch.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.ipackets_drop  Number of packets not passed up.
  IBM.PSSP.CSS.ipackets_lsw   Packets received on interface (lsw bits 30-0).
  IBM.PSSP.CSS.ipackets_msw   Packets received on interface (msw bits 61-31). The number of transmit interrupts (msw bits 61-31).

A message sent to a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.xmitintr_msw is
the most significant word of the total count of transmit interrupts
raised by the subject node's CSS adapter interface, since that
interface was last initialized.  Interrupts are not used in the transmit
flow of the CSS adapter interface, so this variable is always 0.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31).
  IBM.PSSP.CSS.xmitintr_dlt   Number of transmit interrupts (delta).
  IBM.PSSP.CSS.xmitintr_lsw   Number of transmit interrupts (lsw bits 30-0). The number of transmit interrupts (lsw bits 30-0).

A message sent to a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.xmitintr_lsw is
the least significant word of the total count of transmit interrupts
raised by the subject node's CSS adapter interface, since that
interface was last initialized.  Interrupts are not used in the transmit
flow of the CSS adapter interface, so this variable is always 0.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31).
  IBM.PSSP.CSS.xmitintr_dlt   Number of transmit interrupts (delta).
  IBM.PSSP.CSS.xmitintr_msw   Number of transmit interrupts (msw bits 61-31). The number of transmit interrupts (delta).

A message sent to a node over the switch of the SP Communication
SubSystem (CSS) is comprised of packets.  IBM.PSSP.CSS.xmitintr_dlt is
the change, since the previous sample, in the total count of transmit
interrupts raised by the subject node's CSS adapter interface, since that
interface was last initialized.  Interrupts are not used in the transmit
flow of the CSS adapter interface, so this variable is always 0.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.obytes_dlt     Total number of octets sent (delta).
  IBM.PSSP.CSS.opackets_dlt   Packets sent on interface (delta).
  IBM.PSSP.CSS.xmitintr_lsw   Number of transmit interrupts (lsw bits 30-0).
  IBM.PSSP.CSS.xmitintr_msw   Number of transmit interrupts (msw bits 61-31). The number of instances when no buffers were available.

A message sent to a node over the Communication SubSystem (CSS)
switch is comprised of packets.  These packets are transferred from the
adapter to buffers in the node's main memory.  In addition, there are
queue slots on the CSS adapter via which packets exit the adapter to
flow through the high performance switch on the way to a target node.
It is acceptable in the CSS design for these "buffers" to be unavailable
or full at different times, and later become free.  Hence, this counter is
not supported.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor. The maximum number of transmits ever queued.

IBM.PSSP.CSS.xmitque_max is the largest number of entries ever queued
for transmission over the CSS interface, since that interface was last
initialized.  This maximim is the sum of the entries in main memory and
on the CSS adapter.  For performance reasons, transmit queue counters
are not supported by CSS, so this variable will always be 0.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.xmitque_cur    Sum of driver and adapter transmit queues.
  IBM.PSSP.CSS.xmitque_ovf    Number of transmit queue overflows. The number of transmit queue overflows.

IBM.PSSP.CSS.xmitque_ovf is the number of times, since the CSS interface
was last initialized, that a transmit queue for the CSS interface
overflowed.  For performance reasons, transmit queue counters are not
supported by CSS, so this variable will always be 0.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.xmitque_cur    Sum of driver and adapter transmit queues.
  IBM.PSSP.CSS.xmitque_max    Max transmits ever queued. The number of packets not transmitted.

A message sent by a node over the Communication SubSystem (CSS)
switch is comprised of packets.  IBM.PSSP.CSS.opackets_drop is the
count of the number of packets intended to be sent out via the subject
node's CSS interface which were dropped by the adapter microcode, since
that interface was last initialized.  This count is not supported, due
to the design outlined below.

Poorly formed packets cannot be presented to the CSS interface without
a DMA or other hardware error occurring; such an error is generally
treated as a permanent error, and the node will drop from the switch.
That error is logged and the packet is discarded.

If a packet is sent by the CSS adapter, and that packet is flawed, it
will be noted by either the switch fabric or the receiving node.  Hence,
that incident will either be logged by the switch primary node, or
counted in ipackets_drop on the receiving node.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.ipackets_drop  Number of packets not passed up.
  IBM.PSSP.CSS.opackets_lsw   Packets sent on interface (lsw bits 30-0).
  IBM.PSSP.CSS.opackets_msw   Packets sent on interface (msw bits 61-31). The sum of the driver and adapter transmit queues.

IBM.PSSP.CSS.xmitque_cur is the total number of entries currently
queued for transmitting via the CSS adapter.  These entries may be
either in main memory or on the CSS adapter.  For performance reasons,
transmit queue counters are not supported by CSS, so this variable
will always be 0.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.xmitque_max    Max transmits ever queued.
  IBM.PSSP.CSS.xmitque_ovf    Number of transmit queue overflows. The number of broadcast packets transmitted.

IBM.PSSP.CSS.bcast_tx_ok is the count of the broadcast packets sent out
successfully via the CSS interface of the subject node.  Currently, CSS
supports broadcasts only for UDP.  For performance reasons, this variable
is not supported.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resouce Variables:

  IBM.PSSP.CSS.bcast_rx_ok    Number of broadcast packets received. The number of broadcast packets received.

IBM.PSSP.CSS.bcast_rx_ok is the count of the broadcast packets received
successfully at the CSS interface of the subject node.  Currently, CSS
supports broadcasts only for UDP.  For performance reasons, this variable
is not supported.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Related Resource Variables:

  IBM.PSSP.CSS.bcast_tx_ok    Number of broadcast packets transmitted. The number of active processors.

IBM.PSSP.PRCRS.procs_online represents the number of active
processors on a node. The resource variable's resource ID
"NodeNum" is used to specify the number of the node to be
monitored.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

On a uniprocessor system, the value of the "procs_online" variable
will be 1. On a multiprocessor system, it will be the number of
processors that were enabled before the system was started.

The cpu_state command can be used to enable or disable, and display
processor status on a multiprocessor system. For example:

    # cpu_state -l 
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that three of four processors were enabled at system start. The
value of "procs_online" would therefore be 3. If proc1 were to be 
enabled, the value of "procs_online" would be 4 when the system is 
restarted.

The "procs_online" variable is supplied as a convienince to EMAPI
clients for determining the number of active processors. Since changes
to processor state only take effect when the system is restarted, the
value of the resource variable remains constant. Registering for a 
specific event it is therefore not necessary, as the value may be 
obtained by a query.

For example, to determine the number of processors active on node
number 5, query using the parameters that follow:

    Resource Variable: IBM.PSSP.PRCRS.procs_online
    Resource ID:       NodeNum=5

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded which will result
in the query or event registration being applied to all nodes in the
domain.   The number of resource managers connected to harmld.

IBM.PSSP.HARMLD.mgrs_conn represents the number of resource
managers currently connected to the IBM.PSSP.harmld resource
monitor. The resource variable's resource ID, "NodeNum", is used
to specify the number of the node the resource monitor is executing
on. Resource managers which connect to the "harmld" monitor
are haemd (Event Manager Daemon), and PTPE (Performance Toolbox
Parallel Extensions) daemons.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Note:

The IBM.PSSP.HARMLD.mgrs_conn resource variable is intended 
for demonstration and testing purposes only. As such, it does not 
supply a value which would be of significant use to monitor on a 
production system.

Example expression:

To be notified that the number of resource managers connected to
the harmld daemon has changed on any node, register for the event
that follows:

    Resource Variable: IBM.PSSP.HARMLD.mgrs_conn
    Resource ID:       NodeNum=*
    Expression:        X != X@P

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

There are two additional example resource variables supplied by 
the "harmld" resource monitor.

  IBM.PSSP.harmld.err_count     Number of errors logged by the 
                                resource monitor.

  IBM.PSSP.harmld.refresh_cntr  Value updates to the IBM.PSSP.HARMLD 
                                class of variables.
 Value updates to the IBM.PSSP.HARMLD class of variables.

IBM.PSSP.HARMLD.refresh_cntr is a sample variable. The initial
value of "refresh_cntr" is 0. When a resource manager requests 
that its value be updated (for example, when an event has been
registered against it), the value will be incremented by 1 with 
each passing of the number of seconds defined for the reporting  
interval of the variable's resource class (IBM.PSSP.HARMLD). The
resource variable's resource ID, "NodeNum", is used to specify
the number of the node the resource monitor is executing on.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Note:

The IBM.PSSP.HARMLD.refresh_cntr resource variables is intended 
for demonstration and testing purposes only. As such, it does not 
supply a value which would be of use to monitor on a production 
system.

Example expression:

While the value of the "refresh_cntr" variable has no significance
for monitoring, it may be of interest to developers of EMAPI clients.
Since its value is easily predicted, it can be useful for testing
event registrations. For example, to receive an event notification 
when the value of "refresh_cntr" is a multiple of 16, specify
the designations that follow:

    Resource Variable: IBM.PSSP.HARMLD.refresh_cntr
    Resource ID:       NodeNum=*
    Expression:        (X % 16) == 0

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

There are two additional example resource variables supplied by
the "harmld" resource monitor.

  IBM.PSSP.harmld.mgrs_conn     Number of resource managers 
                                connected to harmld.
  
  IBM.PSSP.harmld.err_count     Number of errors logged by the 
                                resource monitor. The number of errors logged by the "harmld" resource monitor.

IBM.PSSP.HARMLD.err_count represents the number of errors that
have been logged to the AIX Error Log by the IBM.PSSP.harmld
resource monitor. The resource variable's resource ID, "NodeNum",
is used to specify the number of the node the resource monitor
is executing on.

This variable is supplied by the "IBM.PSSP.harmld" resource monitor.

Note:

The IBM.PSSP.HARMLD.err_count resource variable is intended 
for demonstration and testing purposes only. As such, it does not 
supply a value which would be of significant use to monitor on a 
production system. For monitoring the AIX Error Log, refer to
the Problem Management feature of PSSP. 

Example expression:

To be notified when the harmld daemon on node 7 has logged an error 
to the AIX Error Log facility, register for the event that follows:

    Resource Variable: IBM.PSSP.HARMLD.err_count
    Resource ID:       NodeNum=7
    Expression:        X > X@P

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

There are two additional example resource variables supplied by
the "harmld" resource monitor.

  IBM.PSSP.harmld.mgrs_conn     Number of resource managers 
                                connected to harmld.
  
  IBM.PSSP.harmld.refresh_cntr  Value updates to the IBM.PSSP.HARMLD 
                                class of variables. A count of, and list of, processes running a program for a user. 

IBM.PSSP.Prog.pcount represents processes running a specified program 
on behalf of a specified user.  The resource variable's resource 
ID specifies the program name (ProgName), user name (UserName), 
and node number (NodeNum) of interest.  The ProgName value specifies 
the base name of the file containing the program.  The UserName value 
specifies the real user name, not the effective user name, associated 
with the process.  The NodeNum value specifies the node or nodes on
which the processes are running. 

The resource variable's value is a structured byte string that 
includes: 

    - A count of the current number of processes running the program 
      for the user (field serial number 0; long data type). 

    - A count of the previously known number of processes that had 
      been running the program for the user (field serial number 1: 
      long data type). 

    - A comma separated list of the process identifiers (PIDs) of the 
      processes currently running the program for the user (field 
      serial number 2: character string data type). 

For example, assume the six processes shown in the ps output that follows
are running the biod program on node 5. 

# ps -e -o "ruser,pid,ppid,comm" | grep biod 
    root  7786  8040 biod 
    root  8040  5624 biod 
    root  8300  8040 biod 
    root  8558  8040 biod 
    root  8816  8040 biod 
    root  9074  8040 biod 

The value of the IBM.PSSP.Prog.pcount instance represented by the 
resource ID "ProgName=biod;UserName=root;NodeNum=5" would include 
a current process count of 6 and a current process list of 
"7786,8040,8300,8558,8816,9074".  The value of the previous process 
count would depend on the history of processes running the biod 
program on node 5. 

A change in the value of an IBM.PSSP.Prog.pcount instance either 
indicates that fewer processes are running the program represented by 
the resource variable instance or more processes are running the 
program.  Which condition is indicated can be determined by comparing 
the value of the current process count with the value of the previous 
process count. 

To be informed whenever the set of processes running the biod program 
for the root user changes on node 5, one could register for an event 
specified as follows: 

    Resource Variable Name: IBM.PSSP.Prog.pcount 
    Resource ID:            ProgName=biod;UserName=root;NodeNum=5 
    Expression:             X@0 != X@1 

To only be informed whenever no processes are running the biod program 
for the root user on node 5, one could register for an event 
specified as follows: 

    Resource Variable Name: IBM.PSSP.Prog.pcount 
    Resource ID:            ProgName=biod;UserName=root;NodeNum=5 
    Expression:             X@0 == 0 

Limitations: 

  The IBM.PSSP.Prog.pcount resource variable is designed to be used to 
  monitor programs that are expected to have long lifetimes.  If it is 
  used to monitor a program that runs for only a few seconds, all 
  processes that run the program may not be detected. 

  The resource variable monitors a program based on the base name of 
  the file containing the program.  This name is displayed by the ps 
  command when -l or -o "comm" is specified.  The program name 
  displayed by ps when -f or -o "args" is specified may not be the 
  same as the base name of the file containing the program. 

  The resource variable matches processes running with the specified 
  real user name.  The real user name of a process is displayed by the 
  ps command when -f or -l or -o "ruser" is specified.  The effective 
  user name displayed by ps when -o "user" is specified may not be 
  the same as the real user name. 

Resource ID wildcarding: 

  Neither the ProgName nor the UserName resource ID element may be 
  wildcarded.  The NodeNum resource ID element may be wildcarded. 

Related Resource Variable: 

  There is another resource variable closely related to 
  IBM.PSSP.Prog.pcount.  It is named IBM.PSSP.Prog.xpcount.  The 
  "pcount" resource variable represents all processes running a 
  specified program, regardless of why the processes are running the 
  program.  The "xpcount" resource variable only represents those 
  processes that are running a specified program as a result of having 
  called one of the exec() routines. 

  A typical process runs a program because it called an exec() routine 
  specifying the program.  However, a process may be running a program 
  because it inherited the program from its parent process, and it 
  never called an exec() routine to execute another program.  Some 
  daemons, including biod, do this.  For example, the ps output below 
  shows that only the process whose PID is 8040 called an exec() 
  routine to run the biod program.  All the other processes running 
  biod do not have the SEXECED process flag (200000) set.  These 
  processes inherited the biod program from their parent process - the 
  process with PID 8040. 

   # ps -e -o "flag,pid,ppid,comm" | grep biod 
      40001  7786  8040 biod 
     240001  8040  5624 biod 
      40001  8300  8040 biod 
      40001  8558  8040 biod 
      40001  8816  8040 biod 
      40001  9074  8040 biod 

  To monitor processes that inherit programs, the IBM.PSSP.Prog.pcount 
  resource variable should be used.  To only monitor processes that 
  explicitly call an exec() routine to run a program, the 
  IBM.PSSP.Prog.xpcount resource variable should be used. 

  Using IBM.PSSP.Prog.pcount to monitor certain programs may be a 
  mistake.  For example, if a program creates child processes that run 
  other programs, registering for an event using "pcount" may generate 
  unintended events.  Consider the inetd program as an example.  The 
  purpose of the inetd program is to spawn other daemons.  As the 
  services of a daemon it controls are requested, inetd calls fork() to 
  create a child process.  That child process starts out running the 
  inetd program, but quickly calls an exec() routine to run the 
  appropriate daemon, such as telnetd.  Therefore, for brief periods 
  of time, more than one process will be running the inetd program. 
  If "pcount" was used to monitor inetd, events might be generated 
  showing these child processes running inetd for small periods of 
  time.  To avoid these "false" events, it would be better to use 
  "xpcount" to monitor inetd. 

  As can be seen from the previous discussion, some knowledge about 
  how a program operates may be needed before deciding how to monitor 
  the program.  For most cases, it is probably appropriate to use the 
  "xpcount" resource variable to monitor a program.  However, if the 
  program to be monitored is inherited by long running processes that 
  do not call an exec() routine, "pcount" might be appropriate.  A count of, and list of, processes running a program for a user. 

IBM.PSSP.Prog.xpcount represents processes running a specified program 
on behalf of a specified user.  The resource variable's resource 
ID specifies the program name (ProgName), user name (UserName), 
and node number (NodeNum) of interest.  The ProgName value specifies 
the base name of the file containing the program.  The UserName value 
specifies the real user name, not the effective user name, associated 
with the process.  The NodeNum value specifies the node or nodes on
which the processes are running. 

The resource variable's value is a structured byte string that 
includes: 

    - A count of the current number of processes running the program 
      for the user (field serial number 0; long data type). 

    - A count of the previously known number of processes that had 
      been running the program for the user (field serial number 1: 
      long data type). 

    - A comma separated list of the process identifiers (PIDs) of the 
      processes currently running the program for the user (field 
      serial number 2: character string data type). 

For example, assume the process shown in the ps output that follows is 
running the inetd program on node 5. 

# ps -e -o "ruser,pid,ppid,comm" | grep inetd 
    root  7218  5624 inetd 

The value of the IBM.PSSP.Prog.xpcount instance represented by the 
resource ID "ProgName=inetd;UserName=root;NodeNum=5" would include 
a current process count of 1 and a current process list of "7218". 
The value of the previous process count would depend on the history of 
processes running the inetd program on node 5. 

A change in the value of an IBM.PSSP.Prog.xpcount instance either 
indicates that fewer processes are running the program represented by 
the resource variable instance or more processes are running the 
program.  Which condition is indicated can be determined by comparing 
the value of the current process count with the value of the previous 
process count. 

To be informed whenever the set of processes running the inetd program 
for the root user changes on node 5, one could register for an event 
specified as follows: 

    Resource Variable Name: IBM.PSSP.Prog.xpcount 
    Resource ID:            ProgName=inetd;UserName=root;NodeNum=5 
    Expression:             X@0 != X@1 

To only be informed whenever no processes are running the inetd 
program for the root user on node 5, one could register for an event 
specified as follows: 

    Resource Variable Name: IBM.PSSP.Prog.xpcount 
    Resource ID:            ProgName=inetd;UserName=root;NodeNum=5 
    Expression:             X@0 == 0 

Limitations: 

  The IBM.PSSP.Prog.xpcount resource variable is designed to be used 
  to monitor programs that are expected to have long lifetimes.  If it 
  is used to monitor a program that runs for only a few seconds, all 
  processes that run the program may not be detected. 

  The resource variable monitors a program based on the base name of 
  the file containing the program.  This name is displayed by the ps 
  command when -l or -o "comm" is specified.  The program name 
  displayed by ps when -f or -o "args" is specified may not be the 
  same as the base name of the file containing the program. 

  The resource variable matches processes running with the specified 
  real user name.  The real user name of a process is displayed by the 
  ps command when -f or -l or -o "ruser" is specified.  The effective 
  user name displayed by ps when -o "user" is specified may not be 
  the same as the real user name. 

Resource ID wildcarding: 

  Neither the ProgName nor the UserName resource ID element may be 
  wildcarded.  The NodeNum resource ID element may be wildcarded. 

Related Resource Variable: 

  There is another resource variable closely related to 
  IBM.PSSP.Prog.xpcount.  It is named IBM.PSSP.Prog.pcount.  The 
  "pcount" resource variable represents all processes running a 
  specified program, regardless of why the processes are running the 
  program.  The "xpcount" resource variable only represents those 
  processes that are running a specified program as a result of having 
  called one of the exec() routines. 

  A typical process runs a program because it called an exec() routine 
  specifying the program.  However, a process may be running a program 
  because it inherited the program from its parent process, and it 
  never called an exec() routine to execute another program.  Some 
  daemons, including biod, do this.  For example, the ps output below 
  shows that only the process whose PID is 8040 called an exec() 
  routine to run the biod program.  All the other processes running 
  biod do not have the SEXECED process flag (200000) set.  These 
  processes inherited the biod program from their parent process - the 
  process with PID 8040. 

   # ps -e -o "flag,pid,ppid,comm" | grep biod 
      40001  7786  8040 biod 
     240001  8040  5624 biod 
      40001  8300  8040 biod 
      40001  8558  8040 biod 
      40001  8816  8040 biod 
      40001  9074  8040 biod 

  To monitor processes that inherit programs, the IBM.PSSP.Prog.pcount 
  resource variable should be used.  To only monitor processes that 
  explicitly call an exec() routine to run a program, the 
  IBM.PSSP.Prog.xpcount resource variable should be used. 

  Using IBM.PSSP.Prog.pcount to monitor certain programs may be a 
  mistake.  For example, if a program creates child processes that run 
  other programs, registering for an event using "pcount" may generate 
  unintended events.  Consider the inetd program as an example.  The 
  purpose of the inetd program is to spawn other daemons.  As the 
  services of a daemon it controls are requested, inetd calls fork() to 
  create a child process.  That child process starts out running the 
  inetd program, but quickly calls an exec() routine to run the 
  appropriate daemon, such as telnetd.  Therefore, for brief periods 
  of time, more than one process will be running the inetd program. 
  If "pcount" was used to monitor inetd, events might be generated 
  showing these child processes running inetd for small periods of 
  time.  To avoid these "false" events, it would be better to use 
  "xpcount" to monitor inetd. 

  As can be seen from the previous discussion, some knowledge about 
  how a program operates may be needed before deciding how to monitor 
  the program.  For most cases, it is probably appropriate to use the 
  "xpcount" resource variable to monitor a program.  However, if the 
  program to be monitored is inherited by long running processes that 
  do not call an exec() routine, "pcount" might be appropriate.  ProgName: the short program name of the program of interest. UserName: the real user name of the user running the program of interest. NodeNum: the node on which the program of interest is running. Summary data from an entry written to the AIX error log. 

IBM.PSSP.pm.Errlog provides summary data from an entry written to the
AIX error log.  The resource variable's resource ID specifies the
node number (NodeNum) of interest.  The NodeNum value identifies the
nodes on which the AIX error log entry is written.

The resource variable's value is a structured byte string that
consists of the fields that follow, from the AIX error log entry:

    - Sequence number   (field number 0: character string data type)
    - Error ID          (field number 1: character string data type)
    - Error class       (field number 2: character string data type)
    - Error type        (field number 3: character string data type)
    - Alert flags value (field number 4: character string data type)
    - Resource name     (field number 5: character string data type)
    - Resource type     (field number 6: character string data type)
    - Resource class    (field number 7: character string data type)
    - Error label       (field number 8: character string data type)

Refer to the AIX documentation for descriptions of these fields.

The value of the IBM.PSSP.pm.Errlog instance represented by the
resource ID "NodeNum=5" includes the sequence number, error ID,
error class, error type, alert flags value, resource name, resource
type, resource class and error label of the most recent AIX error log
entry that is known to Event Management.  A change in the value of
an IBM.PSSP.pm.Errlog instance indicates that a new entry has been
written to the AIX error log.

To be informed whenever anything gets written to the AIX error log on
node 15, one could register for an event specified as follows:

    Resource Variable Name:  IBM.PSSP.pm.Errlog 
    Resource ID:             NodeNum=15 
    Expression:              X@0 != X@P0 

The expression "X@0 != X@P0" is true if the sequence number of the
current AIX error log entry is different than the sequence number of
the previous AIX error log entry.  Since every AIX error log entry
has a unique sequence number, an event gets generated every time an
AIX error log entry gets written on node 15.

To be informed whenever any permanent errors get written to the AIX
error log on any node in the current system partition, one could
register for an event specified as follows:

    Resource Variable Name:  IBM.PSSP.pm.Errlog 
    Resource ID:             NodeNum=* 
    Expression:              X@3 == "PERM" 

To be informed whenever an error log entry, whose error label equals
"REALLY_BAD_ERROR" and whose resource name refers to the "tok1"
token ring adapter, gets written to the AIX error log on any one of
nodes 1, 2 or 3, one could register for an event specified as
follows:

    Resource Variable Name:  IBM.PSSP.pm.Errlog 
    Resource ID:             NodeNum=1-3 
    Expression:              X@5=="tok1" && X@8=="REALLY_BAD_ERROR"

One could also register for the same event by using the error ID
(X@1) in the expression instead of the error label (X@8).  However,
the error ID for the same error can vary between different releases
of AIX, so it is always better to use the error label (X@8) in the
expression.

Limitation:  If an AIX error log entry is written while either of the
Problem Management or Event Management subsystems are not running (on
the node where the AIX error log entry is written), no events are
generated for the AIX error log entry.  This behavior is consistent
with most other resource variables--if either the resource monitor
or the Event Management subsystem (on the node where the resource
monitor resides) is not running when the event occurs, the event
is missed.  However, there is one case where IBM.PSSP.pm.Errlog
encounters this problem consistently:  When a severe problem causes
a node to crash, the AIX error log entry for the problem is written
into non-volatile memory (NVRAM), and the AIX error log entry does
not get processed until the node gets rebooted.  At reboot time, the
AIX error logging daemon (errdemon) usually processes the error log
entry from NVRAM before the Event Management and Problem Management
subsystems are ready to process the event, so the IBM.PSSP.pm.Errlog
event gets missed.  This problem can be avoided by using the AIX
error notification facility instead of IBM.PSSP.pm.Errlog.  Since AIX
error notification does not depend on the Problem Management or Event
Management subsystems, it is more reliable than IBM.PSSP.pm.Errlog.
 Data from the system administrator's resource monitor. 

The Problem Management subsystem defines 16 resource variables, named
IBM.PSSP.pm.User_state1 through IBM.PSSP.pm.User_state16, which are
reserved for use by system administrators.  System administrators can
control these resource variables through a simplified resource
monitoring facility that is provided by the Problem Management
subsystem.  Refer to the Problem Management documentation for further
details.

These resource variables all have the same definition:  The resource
ID specifies the node number (NodeNum) of interest.  The NodeNum
value identifies nodes where the system administrator's resource
monitor data is obtained by the Problem Management subsystem.

The resource variable value is a structured byte string that consists
of one field:

    - String  (field number 0: character string data type)

The system administrator determines the meaning of the string field.

If the system administrator's resource monitor on node 11 for the
IBM.PSSP.pm.User_state16 resource variable provides the string
"READY", then the value of the IBM.PSSP.pm.User_state16 instance
represented by the resource ID "NodeNum=11" is "READY".

To be informed whenever the value of IBM.PSSP.pm.User_state16 on node
11 becomes equal to the string "READY", one could register for an
event specified as follows:

    Resource Variable Name:  IBM.PSSP.pm.User_state16 
    Resource ID:             NodeNum=11 
    Expression:              X@0 == "READY" 

See the Problem Management documentation for further details about
using these resource variables.
 The number of the node on which the resource resides. Indicates whether a LAN adapter has connectivity.

IBM.PSSP.Membership.LANAdapter.state indicates if a LAN adapter in a node
has connectivity, as determined by the High Availability Topology Services
subsytem and reported by the High Availability Group Services subsystem.
A value of 1 indicates connectivity; 0 indicates no connectivity.

This variable is supplied by the "Membership" resource monitor.

The resource variable's resource ID specifies the number of the node
containing the LAN adapter, the type of the Adapter and the instance
of the adapter. To register an event that indicates the switch adapter on
node 5 has lost connectivity, the variable, resource ID and expression
would be:

    Resource Variable: IBM.PSSP.Membership.LANAdapter.state
    Resource ID:       NodeNum=5;AdapterType=css;AdapterNum=0
    Expression:        X == 0

Resource ID wildcarding:

All resource ID elements may be wildcarded.

Related Resource Variables:

    IBM.PSSP.Membership.Node.state
    IBM.PSSP.Response.Host.state
    IBM.PSSP.Response.Switch.state
 Indicates whether a node has connectivity.

IBM.PSSP.Membership.Node.state indicates if a node has connectivity,
as determined by the High Availability Topology Services subsystem and
reported by the High Availability Group Services subsystem. A value
of 1 indicates connectivity; 0 indicates no connectivity.

This variable is supplied by the "Membership" resource monitor.

The resource variable's resource ID specifies the number of the node.
To register an event that indicates node 5 has lost connectivity,
the variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.Membership.Node.state
    Resource ID:       NodeNum=5
    Expression:        X == 0

Resource ID wildcarding:

The resource ID element may be wildcarded.

Related Resource Variable:

    IBM.PSSP.Membership.LANAdapter.state
    IBM.PSSP.Response.Host.state
    IBM.PSSP.Response.Switch.state
 The number of the node containing the LAN adapter. The type of the LAN adapter, i.e. "en" or "css". The number of the LAN adapter. The number of the node. Indicates if the node has connectivity over the en0 adapter.

IBM.PSSP.Response.Host.state indicates if a node has connectivity
over the en0 LAN adapter, as determined by the High Availability Topology
Services subsystem and reported by the High Availability Group Services
subsystem. A value of 1 indicates connectivity; 0 indicates no connectivity.

This variable is supplied by the "Response" resource monitor.

The resource variable's resource ID specifies the number of the node.
To register an event that indicates node 5 has lost connectivity over its
en0 adapter, the variable, resource ID and expression would be:

    Resource Variable: IBM.PSSP.Response.Host.state
    Resource ID:       NodeNum=5
    Expression:        X == 0

Resource ID wildcarding:

The resource ID element may be wildcarded.

Related Resource Variables:

    IBM.PSSP.Response.Switch.state
    IBM.PSSP.Membership.LANAdapter.state
    IBM.PSSP.Membership.Node.state
 Indicates the state of the switch adapter.

IBM.PSSP.Response.Switch.state indicates the state of the switch
adapter within a node, as specified by information in the "switch_responds"
SDR class. A value of 1 indicates the adapter is functional; 0 indicates it
is not. A value of 2 indicates the adapter has "autojoin" enabled, but is
currently not on the switch; 3 indicates the adapter is not configured.

This variable is supplied by the "Response" resource monitor.

This variable only applies to HiPS and SP switch adapters.

The resource variable's resource ID specifies the number of the node
containing the adapter. To register an event that indicates the switch
adapter on node 5 is not functional, the variable, resource ID and expression
would be:

    Resource Variable: IBM.PSSP.Response.Switch.state
    Resource ID:       NodeNum=5
    Expression:        X == 0

Resource ID wildcarding:

The resource ID element may be wildcarded.

Related Resource Variables:

    IBM.PSSP.Response.Host.state
    IBM.PSSP.Membership.LANAdapter.state
    IBM.PSSP.Membership.Node.state
 The number of the node. The number of the node. System-wide time CPU is idle (percent).

IBM.PSSP.aixos.CPU.glidle represents the system-wide percent of time 
the CPU or CPUs are idle. The resource variable's resource ID specifies the
number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate average percent of time all   
active CPUs are currently spending in each state. Therefore the sum of
these resource variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU are executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

On a multiprocessor system, the cpu_state command can be used to
display which processors are active:

    # cpu_state -l   
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has 3 of 4 processors
active. The value of the variable, IBM.PSSP.aixos.CPU.glidle, for 
example, will be the average amount of time that the processors with logical 
numbers 0, 1, and 2 are idle.

Example expression:

To be notified when the average time all processors are idle at least
70% of the time on node 7, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.CPU.glidle
    Resource ID:       NodeNum=7
    Expression:        X >= 80

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply a query
or event registration being applied to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).

  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).
                            
The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID name and value pair "CPU=cpu0"), will be the same as the
equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). System-wide time executing in kernel mode (percent). 

IBM.PSSP.aixos.CPU.glkern represents the system-wide percent of time 
the CPU or CPUs are executing in kernel mode. The resource variable's resource
ID specifies the number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate average percent of time all   
active CPUs are currently spending in each state. Therefore the sum of
these resource variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU or CPUs are executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

On a multiprocessor system, the cpu_state command can be used to 
display which processors are active:

    # cpu_state -l   
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has 3 of 4 processors
active. The value of the variable, IBM.PSSP.aixos.CPU.glidle, for
example, will be the average amount of time the processors with logical 
numbers 0, 1, and 2 are idle.

Example expression:

To be notified when the average time all processors are executing
in kernel mode at least 70% of the time on node 7, one could 
register for the  event that follows:

    Resource variable: IBM.PSSP.aixos.CPU.glkern
    Resource ID:       NodeNum=7
    Expression:        X >= 70

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply a query
or event registration being applied to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).

  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).
                            
The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID name and value pair "CPU=cpu0"), will be the same as the
equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). System-wide time executing in user mode (percent). 

IBM.PSSP.aixos.CPU.gluser represents the system-wide percent of time 
the CPU or CPUs are executing in user mode. The resource variable's resource
ID specifies the number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate average percent of time all   
active CPUs are currently spending in each state. Therefore the sum of
these resource variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU or CPUs are executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

On a multiprocessor system, the cpu_state command can be used to
display which processors are active:

    # cpu_state -l   
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has 3 of 4 processors
active. The value of the variable, IBM.PSSP.aixos.CPU.glidle, for
example, will be the average amount of time the processors with logical
numbers 0, 1, and 2 are idle.

Example expression:

To be notified when the average time all processors are executing
in user mode at least 70% of the time on node 7, one could 
register for the event that follows:

    Resource variable: IBM.PSSP.aixos.CPU.gluser
    Resource ID:       NodeNum=7
    Expression:        X >= 70

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply a query
or event registration being applied to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).

  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).
                            
The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID name and value pair "CPU=cpu0"), will be the same as the
equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). System-wide time waiting for I/O (percent). 

IBM.PSSP.aixos.CPU.glwait represents the system-wide percent of time 
the CPU or CPUs are in wait state. The resource variable's resource ID
specifies the number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate average percent of time all   
active CPUs are currently spending in each state. Therefore the sum of
these resource variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU or CPUs are executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

On a multiprocessor system, the cpu_state command can be used to 
display which processors are active:

    # cpu_state -l   
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has 3 of 4 processors
active. The value of the variable, IBM.PSSP.aixos.CPU.glidle, for
example, will be the average amount of time the processors with logical
numbers 0, 1, and 2 are idle.

Example expression:

To be notified when the average time all processors are in wait 
state at least 50% of the time on node 7, one could register for 
the event that follows:

    Resource variable: IBM.PSSP.aixos.CPU.glwait
    Resource ID:       NodeNum=7
    Expression:        X >= 50

Resource ID wildcarding:

The "NodeNum" resource ID element may be wildcarded to apply a query
or event registration being applied to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).

  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).
                            
The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID name/value pair "CPU=cpu0"), will be the same as the
equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). Time CPU is idle (percent).

IBM.PSSP.aixos.cpu.idle represents the percent of time a CPU  
is in idle state. The resource variable's resource ID specifies
the processor (CPU) and node number (NodeNum) of interest.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate percent of time a specific   
CPU is currently spending in each state. Therefore the sum of these      
variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU is executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

The "CPU" resource ID element value is formed by concatenating
the string "cpu" with the logical number of the processor to be
monitored. On a uniprocessor system, this will always be the string,
"cpu0". On a multiprocessor, the value is dependent on the number
of processors enabled when the system was started. The cpu_state
command can be used to display the state of processors on a 
multiprocessor system:

    # cpu_state -l
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has four processors,
three of which are active. The "Name" field is the ODM processor name,
which is in the form procx, where x is the physical processor number. 
The "Cpu" field is the logical processor number. Logical numbers are 
assigned to processors by numbering all currently enabled processors 
starting with physical processor 0. In the example system above, 
with 3 enabled processors, the logical numbers 0, 1, and 2 are used. 
The possible values of the "CPU" resource ID element would then be
"cpu0", "cpu1" and "cpu2".

Example expression:

To be notified each time any processor on node 5 is idle at least 80%
of the time for two consecutive observations of the resource variable,
one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.cpu.idle
    Resource ID:       CPU=*;NodeNum=5
    Expression:        (X >= 80) && (X@P >= 80)

Resource ID wildcarding:

Both the "CPU" and "NodeNum" resource ID elements may be wildcarded. If
the "CPU" resource ID element is wildcarded, the event registration or
query will be applied to all processors on the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).
                            
  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).

The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID element name and value pair "CPU=cpu0"), will be the same
as the equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). Time CPU executing in kernel mode (percent). 

IBM.PSSP.aixos.cpu.kern represents the percent of time a CPU is 
executing in kernel mode. The resource variable's resource ID specifies
the processor (CPU) and node number (NodeNum) of interest.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate percent of time a specific   
CPU is currently spending in each state. Therefore the sum of these      
variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU is executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

The "CPU" resource ID element value is formed by concatenating
the string "cpu" with the logical number of the processor to be
monitored. On a uniprocessor system, this will always be the string,
"cpu0". On a multiprocessor, the value is dependent on the number
of processors enabled when the system was started. The cpu_state
command can be used to display the state of processors on a 
multiprocessor system:

    # cpu_state -l
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has four processors,
three of which are active. The "Name" field is the ODM processor name,
which is in the form procx, where x is the physical processor number.
The "Cpu" field is the logical processor number. Logical numbers are
assigned to processors by numbering all currently enabled processors
starting with physical processor 0. In the example system above,
with 3 enabled processors, the logical numbers 0, 1, and 2 are used.
The possible values of the "CPU" resource ID element would then be
"cpu0", "cpu1" and "cpu2".

Example expression:

To be notified each time any processor on node 5 is executing in kernel 
mode at least 70% of the time for two consecutive observations of the 
resource variable, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.cpu.kern
    Resource ID:       CPU=*;NodeNum=5
    Expression:        (X >= 70) && (X@P >= 70)

Resource ID wildcarding:

Both the "CPU" and "NodeNum" resource ID elements may be wildcarded. If
the "CPU" resource ID element is wildcarded, the event registration or
query will be applied to all processors on the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).
                            
  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).

The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID element name and value pair "CPU=cpu0"), will be the same as
the equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). Time CPU executing in user mode (percent). 

IBM.PSSP.aixos.cpu.user represents the percent of time a CPU is 
executing in user mode. The resource variable's resource ID
specifies the number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate percent of time a specific   
CPU is currently spending in each state. Therefore the sum of these      
variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU is executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

The "CPU" resource ID element value is formed by concatenating
the string "cpu" with the logical number of the processor to be
monitored. On a uniprocessor system, this will always be the string,
"cpu0". On a multiprocessor, the value is dependent on the number
of processors enabled when the system was started. The cpu_state
command can be used to display the state of processors on a 
multiprocessor system:

    # cpu_state -l
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has four processors,
three of which are active. The "Name" field is the ODM processor name,
which is in the form procx, where x is the physical processor number.
The "Cpu" field is the logical processor number. Logical numbers are
assigned to processors by numbering all currently enabled processors
starting with physical processor 0. In the example system above,
with 3 enabled processors, the logical numbers 0, 1, and 2 are used.
The possible values of the "CPU" resource ID element would then be "cpu0",
"cpu1" and "cpu2".

Example expression:

To be notified each time any processor on node 5 is executing in user 
mode at least 80% of the time for two consecutive observations of the 
resource variable, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.cpu.user
    Resource ID:       CPU=*;NodeNum=5
    Expression:        (X >= 80) && (X@P >= 80)

Resource ID wildcarding:

Both the "CPU" and "NodeNum" resource ID elements may be wildcarded. If
the "CPU" resource ID element is wildcarded, the event registration or
query will be applied to all processors on the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).
                            
  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).

The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID element name and value pair "CPU=cpu0"), will be the same as
the equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). Time CPU waiting for I/O (percent).

IBM.PSSP.aixos.cpu.wait represents the percent of time a CPU is
in wait state. The resource variable's resource ID specifies
the number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

The system tracks the amount of time CPU or CPUs spend idle, in wait
state and executing in kernel and user modes. Each clock tick, an array 
of counters is incremented to reflect the CPU activity based on the  
state of the current running process. The CPU user, kern, wait and idle
resource variables provide the approximate percent of time a specific   
CPU is currently spending in each state. Therefore the sum of these      
variables will be 100 at any given observation.

There are two protection modes that processes execute in, kernel 
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services 
(such as system calls and device drivers).

Processes executing in user level are normal applications with
user level privileges and run in their own unique process space.
When a user level process invokes a kernel service, for example
making a system call, a mode switch occurs causing the process
to execute in kernel mode while the service is executing.

The "kern" and "user" CPU utilization variables supply the
average time the CPU is executing processes in each of the
two modes.

When the current executing process makes a request that cannot be
immediately satisfied, such as an I/O operation, the process is put
into wait state.

A CPU is considered idle when the current process running is 
the 'wait' process. The 'wait' process is a kernel process (kproc)
which is dispatched when no other processes are ready to run. 

The "CPU" resource ID element value is formed by concatenating
the string "cpu" with the logical number of the processor to be
monitored. On a uniprocessor system, this will always be the string,
"cpu0". On a multiprocessor, the value is dependent on the number
of processors enabled when the system was started. The cpu_state
command can be used to display the state of processors on a 
multiprocessor system:

    # cpu_state -l
    Name    Cpu  Status     Location
    proc0   0    Enabled    00-0P-00-00
    proc1   -    Disabled   00-0P-00-01
    proc2   1    Enabled    00-0Q-00-00
    proc3   2    Enabled    00-0Q-00-01

Shows that the system the command was executed on has four processors,
three of which are active. The "Name" field is the ODM processor name,
which is in the form procx, where x is the physical processor number.
The "Cpu" field is the logical processor number. Logical numbers are
assigned to processors by numbering all currently enabled processors
starting with physical processor 0. In the example system above,
with 3 enabled processors, the logical numbers 0, 1, and 2 are used.
The possible values of the "CPU" resource ID element would then be
"cpu0", "cpu1" and "cpu2".

Example expression:

To be notified each time any processor on node 5 is in wait state at  
least 50% of the time for two consecutive observations of the resource
variable, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.cpu.wait
    Resource ID:       CPU=*;NodeNum=5
    Expression:        (X >= 50) && (X@P >= 50)

Resource ID wildcarding:

Both the "CPU" and "NodeNum" resource ID elements may be wildcarded. If
the "CPU" resource ID element is wildcarded, the event registration or
query will be applied to all processors on the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

The IBM.PSSP.aixos.cpu.* resource variables can be used to monitor
specific processor utilization: 
  
  IBM.PSSP.aixos.cpu.kern    Time CPU executing in kernel 
                             mode (percent).
                            
  IBM.PSSP.aixos.cpu.user    Time CPU executing in user mode 
                             (percent).
                            
  IBM.PSSP.aixos.cpu.wait    Time CPU waiting for I/O (percent).
                            
  IBM.PSSP.aixos.cpu.idle    Time CPU is idle (percent).

The IBM.PSSP.aixos.CPU.* resource variables can be used for monitoring 
system-wide CPU utilization. Their values represent the average 
time spent in each state for all active processors. Note that on a 
uniprocessor system, the value for an IBM.PSSP.aixos.cpu.* variable
(resource ID element name and value pair "CPU=cpu0"), will be the same as
the equivalent system-wide CPU utilization variable. 
  
  IBM.PSSP.aixos.CPU.glkern  System-wide time executing in 
                             kernel mode (percent).
  
  IBM.PSSP.aixos.CPU.gluser  System-wide time executing in 
                             user mode (percent).
  
  IBM.PSSP.aixos.CPU.glwait  System-wide time waiting for 
                             I/O (percent).
  
  IBM.PSSP.aixos.CPU.glidle  System-wide time CPU is idle 
                             (percent). Time disk is busy (percent).

IBM.PSSP.aixos.Disk.busy represents the percent of time a disk is
busy. The resource variable's resource ID specifies disk name (Name),
and the number of the node (NodeNum) controlling the disk.

This variable is supplied by the "aixos" resource monitor.

After a disk is added to the system, it must first be designated as a 
physical volume before it can be added to a volume group and used for
file system or paging space. 

A physical volume has certain configuration and identification 
information written on it. When a disk becomes a physical volume, it 
is divided into 512-byte physical blocks. Physical volumes have a unique
name (typically hdiskx where x is a unique number on the system), which 
is permanently associated with the disk until it is undefined. 

The physical volume name of a disk is used as the value of the "Name"
resource ID element for identifying a specific disk in a query or event 
registration.

The command lspv can be used to list the physical volumes in a 
system:

  # lspv
  hdisk0         00002369f3ae4cf9    rootvg         
  hdisk1         00002369f3ae5029    rootvg         

The example output shows that the system the command was executed on
has two physical volumes (disks), both are in the rootvg volume group. 

The value type of the IBM.PSSP.aixos.Disk.busy resource variable 
is Counter. The value of the variable therefore represents the
average percent of time the disk is busy from one observation
of the variable to the next. The observation interval is defined 
in the EM_Resource_Class SDR class for the variable 
(IBM.PSSP.aixos.Disk). 

Example expression:

To be notified each time disk, hdisk1, on node 5 has been busy at
least 90% of the time for two consecutive observations of the
resource variable, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.Disk.busy
    Resource ID:       Name=hdisk1;NodeNum=5
    Expression:        (X >= 90) && (X@P >= 90)

Resource ID wildcarding:

Both the "Name" and "NodeNum" resource ID elements may be wildcarded. If
the "Name" resource ID element is wildcarded, the event registration or
query will be applied to all disks controlled by the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

There are three additional resource variables in the IBM.PSSP.aixos.Disk
resource class for monitoring attributes of physical disks:

  IBM.PSSP.aixos.Disk.rblk   512 byte blocks read from disk.
  IBM.PSSP.aixos.Disk.wblk   512 byte blocks written to disk.
  IBM.PSSP.aixos.Disk.xfer   Transfers to or from disk. The number of 512 byte blocks read from a disk.

IBM.PSSP.aixos.Disk.rblk represents the number of 512 blocks read
from a disk. The resource variable's resource ID specifies the disk
name (Name), and the number of the node (NodeNum) controlling
the disk.

This variable is supplied by the "aixos" resource monitor.

After a disk is added to the system, it must first be designated as a 
physical volume before it can be added to a volume group and used for
file system or paging space. 

A physical volume has certain configuration and identification 
information written on it. When a disk becomes a physical volume, it 
is divided into 512-byte physical blocks. Physical volumes have a unique
name (typically hdiskx where x is a unique number on the system), which 
is permanently associated with the disk until it is undefined. 

The physical volume name of a disk is used as the value of the "Name"
resource ID element for identifying a specific disk in a query or event 
registration.

The command lspv can be used to list the physical volumes in a 
system:

  # lspv
  hdisk0         00002369f3ae4cf9    rootvg         
  hdisk1         00002369f3ae5029    rootvg         

The example output shows that the system the command was executed on
has two physical volumes (disks), both are in the rootvg volume group. 

The value type of the IBM.PSSP.aixos.Disk.rblk resource variable 
is Counter. The value of the variable therefore represents the rate
at which blocks are read from the disk. The rate is calculated as
the difference in total blocks read from the disk from one observation 
of the variable to the next, divided by the time between observations.
The observation interval is defined in the EM_Resource_Class SDR class 
for the variable (IBM.PSSP.aixos.Disk).

Example expression:

To be notified each time the rate per second of 512 byte blocks  
read from disk hdisk1 on node 5 is less than 50, one could 
register for the event that follows:

    Resource variable: IBM.PSSP.aixos.Disk.rblk
    Resource ID:       Name=hdisk1;NodeNum=5
    Expression:        X < 50

Resource ID wildcarding:

Both the "Name" and "NodeNum" resource ID elements may be wildcarded. If
the "Name" resource ID element is wildcarded, the event registration or
query will be applied to all disks controlled by the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

There are three additional resource variables in the IBM.PSSP.aixos.Disk
resource class for monitoring attributes of physical disks:

  IBM.PSSP.aixos.Disk.busy   Time disk is busy (percent).
  IBM.PSSP.aixos.Disk.wblk   512 byte blocks written to disk.
  IBM.PSSP.aixos.Disk.xfer   Transfers to or from disk. The number of 512 byte blocks written to a disk.

IBM.PSSP.aixos.Disk.wblk represents the number of 512 blocks written
to a disk. The resource variable's resource ID specifies the disk
name (Name), and the number of the node (NodeNum) controlling
the disk.

This variable is supplied by the "aixos" resource monitor.

After a disk is added to the system, it must first be designated as a 
physical volume before it can be added to a volume group and used for
file system or paging space. 

A physical volume has certain configuration and identification 
information written on it. When a disk becomes a physical volume, it 
is divided into 512-byte physical blocks. Physical volumes have a unique
name (typically hdiskx where x is a unique number on the system), which 
is permanently associated with the disk until it is undefined. 

The physical volume name of a disk is used as the value of the "Name"
resource ID element for identifying a specific disk in a query or event 
registration.

The command lspv can be used to list the physical volumes in a 
system:

  # lspv
  hdisk0         00002369f3ae4cf9    rootvg         
  hdisk1         00002369f3ae5029    rootvg         

The example output shows that the system the command was executed on
has two physical volumes (disks), both are in the rootvg volume group. 

The value type of the IBM.PSSP.aixos.Disk.wblk resource variable 
is Counter. The value of the variable therefore represents the rate 
at which blocks are written to the disk. The rate is calculated as
the difference in total blocks written to the disk from one observation 
of the variable to the next, divided by the time between observations.
The observation interval is defined in the EM_Resource_Class SDR class 
for the variable (IBM.PSSP.aixos.Disk).

Example expression:

To be notified each time the rate per second of 512 byte blocks  
written to disk hdisk1 on node 5 is less than 50, one could 
register for the event that follows:

    Resource variable: IBM.PSSP.aixos.Disk.wblk
    Resource ID:       Name=hdisk1;NodeNum=5
    Expression:        X < 50

Resource ID wildcarding:

Both the "Name" and "NodeNum" resource ID elements may be wildcarded. If
the "Name" resource ID element is wildcarded, the event registration or
query will be applied to all disks controlled by the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

There are three additional resource variables in the IBM.PSSP.aixos.Disk
resource class for monitoring attributes of physical disks:

  IBM.PSSP.aixos.Disk.busy   Time disk is busy (percent).
  IBM.PSSP.aixos.Disk.rblk   512 byte blocks read from disk.
  IBM.PSSP.aixos.Disk.xfer   Transfers to or from disk. The number of transfers to or from a disk.

IBM.PSSP.aixos.Disk.xfer represents the number of transfers performed
by a disk. The resource variable's resource ID specifies the disk
name (Name), and the number of the node (NodeNum) controlling the
disk.

This variable is supplied by the "aixos" resource monitor.

After a disk is added to the system, it must first be designated as a 
physical volume before it can be added to a volume group and used for
file system or paging space. 

A physical volume has certain configuration and identification 
information written on it. When a disk becomes a physical volume, it 
is divided into 512-byte physical blocks. Physical volumes have a unique
name (typically hdiskx where x is a unique number on the system), which 
is permanently associated with the disk until it is undefined. 

The physical volume name of a disk is used as the value of the "Name"
resource ID element for identifying a specific disk in a query or event 
registration.

The command lspv can be used to list the physical volumes in a 
system:

  # lspv
  hdisk0         00002369f3ae4cf9    rootvg         
  hdisk1         00002369f3ae5029    rootvg         

The example output shows that the system the command was executed on
has two physical volumes (disks), both are in the rootvg volume group. 

The value type of the IBM.PSSP.aixos.Disk.xfer resource variable 
is Counter. The value of the variable therefore represents the
average rate of transfers per second that were issued to the physical
disk. A transfer is an I/O request to the physical disk. Multiple
logical requests can be combined into a single I/O request to the
disk. A transfer is of indeterminate size.

The transfer rate is calculated as the difference in total
transfers from one observation of the variable to the next, 
divided by the time in seconds between observations. The observation
interval is defined in the EM_Resource_Class SDR class for the
variable (IBM.PSSP.aixos.Disk).

Example expression:

To be notified each time the rate of transfers to disk hdisk1
on node 5 has increased by 50%, one could register for the
event that follows:

    Resource variable: IBM.PSSP.aixos.Disk.xfer
    Resource ID:       Name=hdisk1;NodeNum=5
    Expression:        (X > X@P) && ((X - X@P) > (X@P * .5))

Note: This example may cause an event to be generated at the first
observation of the variable. This is because the X@P value may not be
valid as it could contain the initial value as defined for the resource
variable. To avoid a false event in this circumstance, the HA_EM_SCMD_REVAL
subcommand could be used to request an immediate evaluation of the
expression. The subcommand causes an event response to be returned
regardless of the result of the evaluation. Since an initial event response
is guaranteed, the first event response could then be ignored.

Resource ID wildcarding:

Both the "Name" and "NodeNum" resource ID elements may be wildcarded. If
the "Name" resource ID element is wildcarded, the event registration or
query will be applied to all disks controlled by the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variables:

There are three additional resource variables in the IBM.PSSP.aixos.Disk
resource class for monitoring attributes of physical disks:

  IBM.PSSP.aixos.Disk.busy   Time disk is busy (percent).
  IBM.PSSP.aixos.Disk.rblk   512 byte blocks read from disk.
  IBM.PSSP.aixos.Disk.wblk   512 byte blocks written to disk. The percentage of the file nodes that are used.

IBM.PSSP.aixos.FS.%nodesused represents the percent of used file nodes
in a file system. The resource variable's resource ID specifies the names
of the logical volume (LV) and volume group (VG) of the file system, and
the number of the node (NodeNum) on which the file system resides.

This variable is supplied by the "aixos" resource monitor.

A file system is a hierarchical structure (file tree) of files and 
directories. This type of structure resembles an inverted tree with 
the roots at the top and branches at the bottom. This file tree uses 
directories to organize data and programs into groups, allowing the 
management of several directories and files at one time.

A file system resides on a single logical volume. The mkfs (make file
system) command creates a file system. Every file and directory
belongs to a file system within a logical volume.

To be accessible, a file system must be mounted onto a directory mount 
point. When multiple file systems are mounted, a directory structure is 
created that presents the image of a single file system. It is a 
hierarchical structure with a single root. This structure includes the 
base file systems and any additional file systems created.

The lsvg command can be used to list, and display information about 
the volume groups defined on a node. For example:

  # lsvg | lsvg -i -l
  spdata: 
  LV NAME     TYPE     LPs   PPs   PVs  LV STATE      MOUNT POINT
  spdatalv    jfs      450   450   1    open/syncd    /spdata
  loglv00     jfslog   1     1     1    open/syncd    N/A
  rootvg:
  LV NAME     TYPE     LPs   PPs   PVs  LV STATE      MOUNT POINT
  hd6         paging   64    64    1    open/syncd    N/A
  hd5         boot     1     1     1    closed/syncd  N/A
  hd8         jfslog   1     1     1    open/syncd    N/A
  hd4         jfs      18    18    1    open/syncd    /
  hd2         jfs      148   148   1    open/syncd    /usr
  hd9var      jfs      13    13    1    open/syncd    /var
  hd3         jfs      32    32    1    open/syncd    /tmp
  hd1         jfs      1     1     1    open/syncd    /home

Shows the logical volume names and mount points for the volume
groups spdata and rootvg.
 
When a file system is created, its size is specified. The
"%totused" resource variable enables monitoring of the percent
of space in use on a file system. If a file system fills to 
capacity, applications attempting to write to the file system may 
be unsuccessful, and data could be lost. A file system could be monitored
to generate a notification before it is exhausted of free space,
or to detect a condition that denotes under utilization.

When a file system is created, file node (i-node) structures
are created to represent the files. These structures exist 
in static form on disk and contain access information for the file
as well as pointers to the real disk addresses of the file's data 
blocks. The number of nodes available to a file system is
dependent on the size of the file system.

When enough files have been created to use all the available 
i-nodes, no more files can be created, even if the file system 
has free space. The "%nodesused" resource variable can be used 
to monitor the percent of file nodes which are in use. 

Example expression:

To receive a notification that the percent of file nodes in the /tmp
file system on node 3 have exceeded 90%, and also receive a notfication
when the percentage has subsequently dropped below 80%, one could register
for the event that follows using the HA_EM_CMD_REG2 command:

    Resource variable:   IBM.PSSP.aixos.FS.%nodesused
    Resource ID:         VG=rootvg;LV=hd3;NodeNum=3
    Expression:          X > 90
    Re-arm expression:   X < 80

(The rootvg and hd3 resource ID values are from the example 
lsvg output.)

An event notification will be generated when more than 90% of the
file nodes in the /tmp file system are used. Once that condition occurs,
/tmp will be monitored using the re-arm expression. When the amount of
available nodes is greater than 20%, an event notification will be
generated from the re-arm expression, and the file system will once
again be monitored for the "more than 90% used" condition.

Resource ID wildcarding:

The "VG", "LV", and "NodeNum" resource ID elements may all be
wildcarded. 

Related resource variables:

  IBM.PSSP.aixos.FS.%totused     Percent of used space in a file
                                 system.

  IBM.PSSP.aixos.VG.free         Resource variable for monitoring the
                                 amount of free space in a volume group. The percentage of used space.

IBM.PSSP.aixos.FS.%totused represents the percent of space in a file
system that is in use. The resource variable's resource ID specifies
the names of the logical volume (LV) and volume group (VG) of the file
system, and the number of the node (NodeNum) on which the file system
resides.

This variable is supplied by the "aixos" resource monitor.

A file system is a hierarchical structure (file tree) of files and 
directories. This type of structure resembles an inverted tree with 
the roots at the top and branches at the bottom. This file tree uses 
directories to organize data and programs into groups, allowing the 
management of several directories and files at one time.

A file system resides on a single logical volume. The mkfs (make file 
system) command creates a file system. Every file and directory 
belongs to a file system within a logical volume.

To be accessible, a file system must be mounted onto a directory mount 
point. When multiple file systems are mounted, a directory structure is 
created that presents the image of a single file system. It is a 
hierarchical structure with a single root. This structure includes the 
base file systems and any additional file systems created.

The lsvg command can be used to list, and display information about 
the volume groups defined on a node. For example:

  # lsvg | lsvg -i -l
  spdata: 
  LV NAME     TYPE     LPs   PPs   PVs  LV STATE      MOUNT POINT
  spdatalv    jfs      450   450   1    open/syncd    /spdata
  loglv00     jfslog   1     1     1    open/syncd    N/A
  rootvg:
  LV NAME     TYPE     LPs   PPs   PVs  LV STATE      MOUNT POINT
  hd6         paging   64    64    1    open/syncd    N/A
  hd5         boot     1     1     1    closed/syncd  N/A
  hd8         jfslog   1     1     1    open/syncd    N/A
  hd4         jfs      18    18    1    open/syncd    /
  hd2         jfs      148   148   1    open/syncd    /usr
  hd9var      jfs      13    13    1    open/syncd    /var
  hd3         jfs      32    32    1    open/syncd    /tmp
  hd1         jfs      1     1     1    open/syncd    /home

Shows the logical volume names and mount points for the volume
groups spdata and rootvg.
 
When a file system is created, its size is specified. The
"%totused" resource variable enables monitoring of the percent
of space in use on a file system. If a file system fills to 
capacity, applications attempting to write to the file system may 
be unsuccessful, and data could be lost. A file system could be monitored
to generate a notification before it is exhausted of free space,
or to detect a condition that denotes under utilization.

When a file system is created, file node (i-node) structures
are created to represent the files. These structures exist 
in static form on disk and contain access information for the file
as well as pointers to the real disk addresses of the file's data 
blocks. The number of nodes available to a file system is
dependent on the size of the file system.

When enough files have been created to use all the available 
i-nodes, no more files can be created, even if the file system 
has free space. The "%nodesused" resource variable can be used 
to monitor the percent of file nodes which are in use. 

Example expression:

To receive a notification that the file system mounted on /tmp on any
node is more than 90% full, and also receive a notfication when the
percentage has subsequently dropped below 80%, one could register
for the event that follows using the HA_EM_CMD_REG2 command:

    Resource variable:   IBM.PSSP.aixos.FS.%totused
    Resource ID:         VG=rootvg;LV=hd3;NodeNum=*
    Expression:          X > 90
    Re-arm expression:   X < 80

(The rootvg and hd3 resource ID values are from the example 
lsvg output.)

An event notification will be generated when more than 90% of the
space in a /tmp file system is used. Once that condition occurs,
/tmp will be monitored using the re-arm expression. When the amount of
free space is greater than 20%, an event notification will be
generated from the re-arm expression, and the file system will once
again be monitored for the "more than 90% used" condition.

Resource ID wildcarding:

The "VG", "LV", and "NodeNum" resource ID elements may all be
wildcarded. 

Related resource variables:

  IBM.PSSP.aixos.FS.%nodesused   Percent of file nodes that are used
                                 in a file system.
  
  IBM.PSSP.aixos.VG.free         Resource variable for monitoring the
                                 amount of free space in a volume group. The amount of free space in a volume group, in megabytes.

IBM.PSSP.aixos.VG.free represents the amount (in megabytes) of free
space available in a volume group. The resource variable's resource ID
specifies the name of the volume group (VG), and the number of the
node (NodeNum) on which the volume group resides.

This variable is supplied by the "aixos" resource monitor.

A hierarchy of structures is used to manage fixed-disk storage. Each
individual fixed-disk drive, called a physical volume (PV) has a name,
such as /dev/hdisk0. A volume group is a collection of one or more 
physical volumes. When a physical volume is added to a volume group, it
is divided into contiguous equal-sized units of space called physical 
partitions (PPs). 

The lsvg command can be used to display characteristics of a 
volume group:

  # lsvg rootvg
  VOLUME GROUP:   rootvg         VG IDENTIFIER:  00002369efc43b73
  VG STATE:       active         PP SIZE:        4 megabyte(s)
  VG PERMISSION:  read/write     TOTAL PPs:      408 (1632 megabytes)
  MAX LVs:        256            FREE PPs:       44 (176 megabytes)
  LVs:            11             USED PPs:       364 (1456 megabytes)
  OPEN LVs:       10             QUORUM:         2
  TOTAL PVs:      2              VG DESCRIPTORS: 3
  STALE PVs:      0              STALE PPs       0
  ACTIVE PVs:     2              AUTO ON:        yes

The example output shows a rootvg volume group comprised of 408 physical
partitions (TOTAL PPs). Each partition is 4 megabytes (PP SIZE), 
yielding a volume group size of 1632 megabytes. The volume group
contains two physical volumes (TOTAL PVs). 

One or more logical volumes (LVs) are defined within each volume group.
Logical volumes can serve a number of purposes, such as paging space, or
holding system or user data within a file system. When a logical volume 
is created, a number of logical partitions is specified. Each logical
partition maps to one, two, or three physical partitions in the volume
group. The number of physical partitions denotes the number of copies
of the logical volume. 

As logical volumes are created (or extended) the volume group and number
of logical paritions to be allocated is specified. The amount of free
space in the volume group is decremented by the total size of the
physical partitions needed for the number of logical partitions 
requested.

Example expression:

To receive a notification that there is less than 40MB of free space
in the rootvg volume group on node 5, and also receive a notfication
once there is at least 40MB of free space again, one could register
for the event that follows using the HA_EM_CMD_REG2 command:

    Resource Variable:   IBM.PSSP.aixos.VG.free
    Resource ID:         VG=rootvg;NodeNum=5 
    Expression:          X < 40
    Re-arm Expression:   X >= 40

An event notification will be generated when there is less than 40 MB of
free space in the rootvg volume group. Once that condition occurs, the
volume group will be monitored using the re-arm expression. When the
amount of free space is greater or equal to 40 MB, an event notification
will be generated from the re-arm expression, and the volume group will
once again be monitored for the "less than 40 MB free" condition.

Resource ID wildcarding:

Both the "VG" and "NodeNum" resource ID elements may be wildcarded.
If the "VG" resource ID element is wildcarded, the event registration
or query will be applied to all volume groups on the target nodes. Wildcarding
"NodeNum" will apply the action to all nodes in the domain.

Related resource variable(s):

  IBM.PSSP.aixos.FS.*    Variables for monitoring attributes 
                         of file systems.
  
  IBM.PSSP.aixos.Disk.*  Variables for monitoring attributes 
                         of physical volumes. The number of frame receive errors at the adapter level.

IBM.PSSP.aixos.LAN.rcverrors represents the number of receive 
errors which occurred at the adapter level. The resource variable's
resource ID specifies the name of the adapter (Adapter), and the
number of the node (NodeNum) the adapter is installed on.

This variable is supplied by the "aixos" resource monitor.

A network adapter card is the hardware that is physically 
attached to the network cabling. It is responsible for 
receiving and transmitting data at the physical level. The 
network adapter card is controlled by the network adapter 
device driver.

A machine must have one network adapter card (or connection) 
for each network (not network type) to which it connects. For 
instance, if a host attaches to two Token-Ring networks, it 
must have two network adapter cards.

When a new network adapter is physically installed in the system, 
the operating system assigns it a logical name. Some examples
are: tok0 for a Token-Ring adapter, ent0 for a Ethernet adapter or
atm0 for an ATM adapter. The trailing number assigned, creates a
unique logical number. For example, a second Token-ring adapter 
would have the logical name, tok1. The lsdev command can be used
to display information about network adapters: 

  # lsdev -C -k ent -H
  name status    location description
  ent0 Available 00-01 Ethernet High-Performance LAN Adapter (8ef5)
  ent1 Available 00-02 Ethernet High-Performance LAN Adapter (8ef5)

  #lsdev -C -k atm -H
  name status    location description
  atm0 Available 00-06    155 Mbps ATM Fiber Adapter (8f67)

Shows that the system the command was executed on has two
Ethernet and one ATM adapters installed and available. The 
adapter logical device names, "ent0", "ent1", and "atm0" 
could be used as the value of the resource ID element, "Adapter",
in specifying an adapter in a query or event registration.

Messages received by a LAN adapter, referred to as frames,
are encapsulated within destination, header and trailer
information added by the various network protocol layers.

A counter, maintained for each adapter, tracks the number
of frame receive errors at the adapter device level which 
caused unsuccessful reception due to hardware or network 
errors. That counter provides the raw value for the LAN
"rcverrors" variable.

When frames are received by an adapter, they are transferred
from the adapter into a device-managed receive queue. 
The number of packets accepted, but dropped by the device
driver level for any reason (for example, queue buffer 
shortage), is tracked by a counter which provides the raw 
value of the "recvdrops" resource variable. 

Messages and data sent by an application to a LAN adapter 
for transmission are broken up into packets and appended 
with address, header, and trailer information by the various 
network protocol layers.

At the adapter device driver level, packets are placed in
buffers on a transmit queue. The packets are appended with 
a network interface header then transmitted as frames by 
the adapter device. 

Counters are maintained for each adapter to track the number
of transmission errors at the device level (due to hardware or
network errors), number of transmission queue overflows at 
the device driver level (due to buffer shortage), and the number
of packets dropped (packets not passed to the device by the 
driver for any reason). These counters provide the raw 
values for the LAN "xmiterrors", "xmitovfl" and "xmitdrops"
resource variables.

The value type of the IBM.PSSP.aixos.LAN.rcverrors resource
variable is Counter. The value of the variable therefore
represents the average number of receive errors at the adapter
per second. The average is calculated as the number of errors
detected between observations of the variable, divided by
the time in seconds between observations. The observation
interval is defined in the EM_Resource_Class SDR class for
the variable (IBM.PSSP.aixos.LAN).

Example expression:

To be notified each time the rate of receive errors detected on
ethernet adapter "ent0" on node 5 exceeds 1 per second, one
could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.LAN.rcverrors
    Resource ID:       Adapter=ent0;NodeNum=5
    Expression:        X > 1

Resource ID wildcarding:

Both the "Adapter" and "NodeNum" resource ID elements may be wildcarded.
If the "Adapter" resource ID element is wildcarded, the event registration
or query will be applied to all LAN adapters on the target node or nodes. 
Wildcarding "NodeNum" will apply the action to all nodes in the 
domain.

Related resource variables:

The IBM.PSSP.aixos.LAN class of resource variables can be used to
monitor attributes of LAN adapters: 
  
  IBM.PSSP.aixos.LAN.rcverrors   Count of frame receive errors 
                                 at adapter level.
  
  IBM.PSSP.aixos.LAN.recvdrops   Count of receive packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmitdrops   Count of transmit packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmiterrors  Count of frame transmit errors at 
                                 adapter level.
  
  IBM.PSSP.aixos.LAN.xmitovfl    Count of transmit queue overflows. The number of receive packets dropped at the device driver level.

IBM.PSSP.aixos.LAN.recvdrops represents the number of receive 
packets which were dropped by the adapter device driver. The resource
variables's resource ID specifies the name of the adapter (Adapter),
and the number of the node (NodeNum) the adapter is installed on.

This variable is supplied by the "aixos" resource monitor.

A network adapter card is the hardware that is physically 
attached to the network cabling. It is responsible for 
receiving and transmitting data at the physical level. The 
network adapter card is controlled by the network adapter 
device driver.

A machine must have one network adapter card (or connection) 
for each network (not network type) to which it connects. For 
instance, if a host attaches to two Token-Ring networks, it 
must have two network adapter cards.

When a new network adapter is physically installed in the system, 
the operating system assigns it a logical name. Some examples
are: tok0 for a Token-Ring adapter, ent0 for a Ethernet adapter or
atm0 for an ATM adapter. The trailing number assigned, creates a
unique logical number. For example, a second Token-ring adapter 
would have the logical name, tok1. The lsdev command can be used
to display information about network adapters: 

  # lsdev -C -k ent -H
  name status    location description
  ent0 Available 00-01 Ethernet High-Performance LAN Adapter (8ef5)
  ent1 Available 00-02 Ethernet High-Performance LAN Adapter (8ef5)

  #lsdev -C -k atm -H
  name status    location description
  atm0 Available 00-06    155 Mbps ATM Fiber Adapter (8f67)

Shows that the system the command was executed on has two
Ethernet and one ATM adapters installed and available. The 
adapter logical device names, "ent0", "ent1", and "atm0" 
could be used as the value of the resource ID element, "Adapter",
in specifying an adapter in a query or event registration.

Messages received by a LAN adapter, referred to as frames,
are encapsulated within destination, header and trailer
information added by the various network protocol layers.

A counter, maintained for each adapter, tracks the number
of frame receive errors at the adapter device level which 
caused unsuccessful reception due to hardware or network 
errors. That counter provides the raw value for the LAN
"rcverrors" variable.

When frames are received by an adapter, they are transferred
from the adapter into a device-managed receive queue. 
The number of packets accepted, but dropped by the device
driver level for any reason (for example, queue buffer 
shortage), is tracked by a counter which provides the raw 
value of the "recvdrops" resource variable. 

Messages and data sent by an application to a LAN adapter 
for transmission are broken up into packets and appended 
with address, header, and trailer information by the various 
network protocol layers.

At the adapter device driver level, packets are placed in
buffers on a transmit queue. The packets are appended with 
a network interface header then transmitted as frames by 
the adapter device. 

Counters are maintained for each adapter to track the number
transmission errors at the device level (due to hardware or
network errors), number of transmission queue overflows at 
the device driver level (due to buffer shortage), and the number
of packets dropped (packets not passed to the device by the 
driver for any reason). These counters provide the raw 
values for the LAN "xmiterrors", "xmitovfl" and "xmitdrops"
resource variables.

The value type of the IBM.PSSP.aixos.LAN.recvdrops resource
variable is Counter. The value of the variable therefore 
represents the average number of receive packets dropped by 
the adapter per second. The average is calculated as the number 
of drops occurring between observations of the variable, divided
by the time in seconds between observations. The observation
interval is defined in the EM_Resource_Class SDR class for
the variable (IBM.PSSP.aixos.LAN).

Example expression:

To be notified each time the rate of receive packets dropped by
ethernet adapter "ent0" on node 5 exceeds 10 per second, one
could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.LAN.recvdrops
    Resource ID:       Adapter=ent0;NodeNum=5
    Expression:        X > 10 

Resource ID wildcarding:

Both the "Adapter" and "NodeNum" resource ID elements may be wildcarded.
If the "Adapter" resource ID element is wildcarded, the event registration
or query will be applied to all LAN adapters on the target node or nodes. 
Wildcarding "NodeNum" will apply the action to all nodes in the 
domain.

Related resource variables:

The IBM.PSSP.aixos.LAN class of resource variables can be used to
monitor attributes of LAN adapters: 
  
  IBM.PSSP.aixos.LAN.rcverrors   Count of frame receive errors 
                                 at adapter level.
  
  IBM.PSSP.aixos.LAN.recvdrops   Count of receive packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmitdrops   Count of transmit packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmiterrors  Count of frame transmit errors at 
                                 adapter level.
  
  IBM.PSSP.aixos.LAN.xmitovfl    Count of transmit queue overflows. The number of transmit packets dropped at the device driver level.

IBM.PSSP.aixos.LAN.xmitdrops represents the number of outbound
packets which were dropped by the adapter device driver. The resource
variables's resource ID specifies the name of the adapter (Adapter),
and the number of the node (NodeNum) the adapter is installed on.

This variable is supplied by the "aixos" resource monitor.

A network adapter card is the hardware that is physically 
attached to the network cabling. It is responsible for 
receiving and transmitting data at the physical level. The 
network adapter card is controlled by the network adapter 
device driver.

A machine must have one network adapter card (or connection) 
for each network (not network type) to which it connects. For 
instance, if a host attaches to two Token-Ring networks, it 
must have two network adapter cards.

When a new network adapter is physically installed in the system, 
the operating system assigns it a logical name. Some examples
are: tok0 for a Token-Ring adapter, ent0 for a Ethernet adapter or
atm0 for an ATM adapter. The trailing number assigned, creates a
unique logical number. For example, a second Token-ring adapter 
would have the logical name, tok1. The lsdev command can be used
to display information about network adapters: 

  # lsdev -C -k ent -H
  name status    location description
  ent0 Available 00-01 Ethernet High-Performance LAN Adapter (8ef5)
  ent1 Available 00-02 Ethernet High-Performance LAN Adapter (8ef5)

  #lsdev -C -k atm -H
  name status    location description
  atm0 Available 00-06    155 Mbps ATM Fiber Adapter (8f67)

Shows that the system the command was executed on has two
Ethernet and one ATM adapters installed and available. The 
adapter logical device names, "ent0", "ent1", and "atm0" 
could be used as the value of the resource ID element, "Adapter", 
in specifying an adapter in a query or event registration.

Messages received by a LAN adapter, referred to as frames,
are encapsulated within destination, header and trailer
information added by the various network protocol layers.

A counter, maintained for each adapter, tracks the number
of frame receive errors at the adapter device level which 
caused unsuccessful reception due to hardware or network 
errors. That counter provides the raw value for the LAN
"rcverrors" variable.

When frames are received by an adapter, they are transferred
from the adapter into a device-managed receive queue. 
The number of packets accepted, but dropped by the device
driver level for any reason (for example, queue buffer 
shortage), is tracked by a counter which provides the raw 
value of the "recvdrops" resource variable. 

Messages and data sent by an application to a LAN adapter 
for transmission are broken up into packets and appended 
with address, header, and trailer information by the various 
network protocol layers.

At the adapter device driver level, packets are placed in
buffers on a transmit queue. The packets are appended with 
a network interface header then transmitted as frames by 
the adapter device. 

Counters are maintained for each adapter to track the number
transmission errors at the device level (due to hardware or
network errors), number of transmission queue overflows at 
the device driver level (due to buffer shortage), and the number
of packets dropped (packets not passed to the device by the 
driver for any reason). These counters provide the raw 
values for the LAN "xmiterrors", "xmitovfl" and "xmitdrops"
resource variables.

The value type of the IBM.PSSP.aixos.LAN.xmitdrops resource
variable is Counter. The value of the variable therefore 
represents the average number of transmit packets dropped by 
the adapter per second. The average is calculated as the number 
of drops occurring between observations of the variable, divided
by the time in seconds between observations. The observation
interval is defined in the EM_Resource_Class SDR class for
the variable (IBM.PSSP.aixos.LAN).

Example expression:

To be notified each time the rate of transmit packets dropped
by ethernet adapter "ent0" on node 5 exceeds 10 per second, one
could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.LAN.xmitdrops
    Resource ID:       Adapter=ent0;NodeNum=5
    Expression:        X > 10

Resource ID wildcarding:

Both the "Adapter" and "NodeNum" resource ID elements may be wildcarded.
If the "Adapter" resource ID element is wildcarded, the event registration
or query will be applied to all LAN adapters on the target node or nodes. 
Wildcarding "NodeNum" will apply the action to all nodes in the 
domain.

Related resource variables:

The IBM.PSSP.aixos.LAN class of resource variables can be used to
monitor attributes of LAN adapters: 
  
  IBM.PSSP.aixos.LAN.rcverrors   Count of frame receive errors 
                                 at adapter level.
  
  IBM.PSSP.aixos.LAN.recvdrops   Count of receive packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmitdrops   Count of transmit packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmiterrors  Count of frame transmit errors at 
                                 adapter level.
  
  IBM.PSSP.aixos.LAN.xmitovfl    Count of transmit queue overflows. The number of frame transmit errors at the adapter level.

IBM.PSSP.aixos.LAN.xmiterrors represents the number of transmit
errors which occurred at the adapter level. The resource variable's
resource ID specifies the name of the adapter (Adapter), and the
number of the node (NodeNum) the adapter is installed on.

This variable is supplied by the "aixos" resource monitor.

A network adapter card is the hardware that is physically 
attached to the network cabling. It is responsible for 
receiving and transmitting data at the physical level. The 
network adapter card is controlled by the network adapter 
device driver.

A machine must have one network adapter card (or connection) 
for each network (not network type) to which it connects. For 
instance, if a host attaches to two Token-Ring networks, it 
must have two network adapter cards.

When a new network adapter is physically installed in the system, 
the operating system assigns it a logical name. Some examples
are: tok0 for a Token-Ring adapter, ent0 for a Ethernet adapter or
atm0 for an ATM adapter. The trailing number assigned, creates a
unique logical number. For example, a second Token-ring adapter 
would have the logical name, tok1. The lsdev command can be used
to display information about network adapters: 

  # lsdev -C -k ent -H
  name status    location description
  ent0 Available 00-01 Ethernet High-Performance LAN Adapter (8ef5)
  ent1 Available 00-02 Ethernet High-Performance LAN Adapter (8ef5)

  #lsdev -C -k atm -H
  name status    location description
  atm0 Available 00-06    155 Mbps ATM Fiber Adapter (8f67)

Shows that the system the command was executed on has two
Ethernet and one ATM adapters installed and available. The 
adapter logical device names, "ent0", "ent1", and "atm0" 
could be used as the value of the resource ID element, "Adapter",
in specifying an adapter in a query or event registration.

Messages received by a LAN adapter, referred to as frames,
are encapsulated within destination, header and trailer
information added by the various network protocol layers.

A counter, maintained for each adapter, tracks the number
of frame receive errors at the adapter device level which 
caused unsuccessful reception due to hardware or network 
errors. That counter provides the raw value for the LAN
"rcverrors" variable.

When frames are received by an adapter, they are transferred
from the adapter into a device-managed receive queue. 
The number of packets accepted, but dropped by the device
driver level for any reason (for example, queue buffer 
shortage), is tracked by a counter which provides the raw 
value of the "recvdrops" resource variable. 

Messages and data sent by an application to a LAN adapter 
for transmission are broken up into packets and appended 
with address, header, and trailer information by the various 
network protocol layers.

At the adapter device driver level, packets are placed in
buffers on a transmit queue. The packets are appended with 
a network interface header then transmitted as frames by 
the adapter device. 

Counters are maintained for each adapter to track the number
transmission errors at the device level (due to hardware or
network errors), number of transmission queue overflows at 
the device driver level (due to buffer shortage), and the number
of packets dropped (packets not passed to the device by the 
driver for any reason). These counters provide the raw 
values for the LAN "xmiterrors", "xmitovfl" and "xmitdrops"
resource variables.

The value type of the IBM.PSSP.aixos.LAN.xmiterrors resource
variable is Counter. The value of the variable therefore 
represents the average number of transmit errors at the adapter 
per second. The average is calculated as the number of errors
detected between observations of the variable, divided by
the time in seconds between observations. The observation
interval is defined in the EM_Resource_Class SDR class for
the variable (IBM.PSSP.aixos.LAN).

Example expression:

To be notified each time the rate of transmit errors detected
on ethernet adapter "ent0" on node 5 exceeds 1 per second, one
could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.LAN.xmiterrors
    Resource ID:       Adapter=ent0;NodeNum=5
    Expression:        X > 1

Resource ID wildcarding:

Both the "Adapter" and "NodeNum" resource ID elements may be wildcarded.
If the "Adapter" resource ID element is wildcarded, the event registration
or query will be applied to all LAN adapters on the target node or nodes. 
Wildcarding "NodeNum" will apply the action to all nodes in the 
domain.

Related resource variables:

The IBM.PSSP.aixos.LAN class of resource variables can be used to
monitor attributes of LAN adapters: 
  
  IBM.PSSP.aixos.LAN.rcverrors   Count of frame receive errors 
                                 at adapter level.
  
  IBM.PSSP.aixos.LAN.recvdrops   Count of receive packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmitdrops   Count of transmit packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmiterrors  Count of frame transmit errors at 
                                 adapter level.
  
  IBM.PSSP.aixos.LAN.xmitovfl    Count of transmit queue overflows. The number of transmit queue overflows.

IBM.PSSP.aixos.LAN.xmitovfl represents the number of transmit
queue overflows at the adapter device driver level. The resource
variable's resource ID specifies the name of the adapter (Adapter),
and the number of the node (NodeNum) the adapter is installed on.

This variable is supplied by the "aixos" resource monitor.

A network adapter card is the hardware that is physically 
attached to the network cabling. It is responsible for 
receiving and transmitting data at the physical level. The 
network adapter card is controlled by the network adapter 
device driver.

A machine must have one network adapter card (or connection) 
for each network (not network type) to which it connects. For 
instance, if a host attaches to two Token-Ring networks, it 
must have two network adapter cards.

When a new network adapter is physically installed in the system, 
the operating system assigns it a logical name. Some examples
are: tok0 for a Token-Ring adapter, ent0 for a Ethernet adapter or
atm0 for an ATM adapter. The trailing number assigned, creates a
unique logical number. For example, a second Token-ring adapter 
would have the logical name, tok1. The lsdev command can be used
to display information about network adapters: 

  # lsdev -C -k ent -H
  name status    location description
  ent0 Available 00-01 Ethernet High-Performance LAN Adapter (8ef5)
  ent1 Available 00-02 Ethernet High-Performance LAN Adapter (8ef5)

  #lsdev -C -k atm -H
  name status    location description
  atm0 Available 00-06    155 Mbps ATM Fiber Adapter (8f67)

Shows that the system the command was executed on has two
Ethernet and one ATM adapters installed and available. The 
adapter logical device names, "ent0", "ent1", and "atm0" 
could be used as the value of the resource ID element, "Adapter",
in specifying an adapter in a query or event registration.

Messages received by a LAN adapter, referred to as frames,
are encapsulated within destination, header and trailer
information added by the various network protocol layers.

A counter, maintained for each adapter, tracks the number
of frame receive errors at the adapter device level which 
caused unsuccessful reception due to hardware or network 
errors. That counter provides the raw value for the LAN
"rcverrors" variable.

When frames are received by an adapter, they are transferred
from the adapter into a device-managed receive queue. 
The number of packets accepted, but dropped by the device
driver level for any reason (for example, queue buffer 
shortage), is tracked by a counter which provides the raw 
value of the "recvdrops" resource variable. 

Messages and data sent by an application to a LAN adapter 
for transmission are broken up into packets and appended 
with address, header, and trailer information by the various 
network protocol layers.

At the adapter device driver level, packets are placed in
buffers on a transmit queue. The packets are appended with 
a network interface header then transmitted as frames by 
the adapter device. 

Counters are maintained for each adapter to track the number
transmission errors at the device level (due to hardware or
network errors), number of transmission queue overflows at 
the device driver level (due to buffer shortage), and the number
of packets dropped (packets not passed to the device by the 
driver for any reason). These counters provide the raw 
values for the LAN "xmiterrors", "xmitovfl" and "xmitdrops"
resource variables.

The value type of the IBM.PSSP.aixos.LAN.xmitovfl resource
variable is Counter. The value of the variable therefore 
represents the average number of transmit queue overflows
per second. The average is calculated as the number of errors
detected between observations of the variable, divided by
the time in seconds between observations. The observation
interval is defined in the EM_Resource_Class SDR class for
the variable (IBM.PSSP.aixos.LAN).

Example expression:

To be notified each time the rate of transmit queue overflows on
ethernet adapter "ent0" on node 5 exceeds 10 per second, one 
could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.LAN.xmitovfl
    Resource ID:       Adapter=ent0;NodeNum=5
    Expression:        X > 10

Resource ID wildcarding:

Both the "Adapter" and "NodeNum" resource ID elements may be wildcarded.
If the "Adapter" resource ID element is wildcarded, the event registration
or query will be applied to all LAN adapters on the target node or nodes. 
Wildcarding "NodeNum" will apply the action to all nodes in the 
domain.

Related resource variables:

The IBM.PSSP.aixos.LAN class of resource variables can be used to
monitor attributes of LAN adapters: 
  
  IBM.PSSP.aixos.LAN.rcverrors   Count of frame receive errors 
                                 at adapter level.
  
  IBM.PSSP.aixos.LAN.recvdrops   Count of receive packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmitdrops   Count of transmit packets dropped 
                                 at device driver level.
  
  IBM.PSSP.aixos.LAN.xmiterrors  Count of frame transmit errors at 
                                 adapter level.
  
  IBM.PSSP.aixos.LAN.xmitovfl    Count of transmit queue overflows. The number of requests for a kernel memory buffer.

The IBM.PSSP.aixos.Mem.Kmem.calls resource variable represents the
rate of requests per second for a kernel memory buffer. The resource
ID element, "NodeNum" is used to specify the number of the node to
be monitored. The resource ID element "Type" is used to specify the
type of kernel memory to be monitored.

Valid values for the "Type" resource ID element are:

    mbuf     - Network data buffer.
    socket   - Kernel socket structure.
    protcb   - Protocol control block.
    otherip  - Other IP.
    mblk     - Stream header and data.
    streams  - Other stream related memory.
    other    - Other kernel memory.

This variable is supplied by the "aixos" resource monitor.

There are two protection modes that processes execute in, kernel
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services
(such as system calls and device drivers).

AIX provides routines used by the kernel and by services executing at
system level for allocating memory in kernel space. Counters are
maintained in the kernel to track the requests and use of kernel
memory, based on the type of data structure or service. The
IBM.PSSP.Mem.Kmem.* resource variables can be used to monitor the
number, size and state of requests for buffers allocated in kernel
memory.

Example expression:

To be notified when the rate of mbuf requests on node 10 exceeds
100 per second, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.Mem.Kmem.calls
    Resource ID:       NodeNum=10;Type=mbuf
    Expression:        X > 100

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.
Wildcarding the Type resource ID element results in the query or
event registration being applied to all kernel memory buffer types.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The number of unsuccessful requests for a kernel memory buffer.

The IBM.PSSP.aixos.Mem.Kmem.failures resource variable represents
the rate of requests per second for a kernel memory buffer that
were unsuccessful. The resource ID element, "NodeNum" is used to specify
the number of the node to be monitored. The resource ID element "Type"
is used to specify the type of kernel memory to be monitored.

Valid values for the "Type" resource ID element are:

    mbuf     - Network data buffer.
    socket   - Kernel socket structure.
    protcb   - Protocol control block.
    otherip  - Other IP.
    mblk     - Stream header and data.
    streams  - Other stream related memory.
    other    - Other kernel memory.

This variable is supplied by the "aixos" resource monitor.

There are two protection modes that processes execute in, kernel
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services
(such as system calls and device drivers).

AIX provides routines used by the kernel and by services executing at
system level for allocating memory in kernel space. Counters are
maintained in the kernel to track the requests and use of kernel
memory, based on the type of data structure or service. The
IBM.PSSP.Mem.Kmem.* resource variables can be used to monitor the
number, size and state of requests for buffers allocated in kernel
memory.

Example expression:

To be notified when the rate of unsuccessful allocations of kernel protocol
control blocks on node 8 is at least 1 per second, one could register
for the event that follows:

    Resource variable: IBM.PSSP.aixos.Mem.Kmem.failures
    Resource ID:       NodeNum=8;Type=protcb
    Expression:        X >= 1

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.
Wildcarding the Type resource ID element results in the query or
event registration being applied to all kernel memory buffer types.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The number of kernel memory buffers in use.

The IBM.PSSP.aixos.Mem.Kmem.inuse resource variable represents the
number of kernel memory buffers that are currently in use. The
resource ID element, "NodeNum" is used to specify the number of
the node to be monitored. The resource ID element "Type" is used
to specify the type of kernel memory to be monitored.

Valid values for the "Type" resource ID element are:

    mbuf     - Network data buffer.
    socket   - Kernel socket structure.
    protcb   - Protocol control block.
    otherip  - Other IP.
    mblk     - Stream header and data.
    streams  - Other stream related memory.
    other    - Other kernel memory.

This variable is supplied by the "aixos" resource monitor.

There are two protection modes that processes execute in, kernel
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services
(such as system calls and device drivers).

AIX provides routines used by the kernel and by services executing at
system level for allocating memory in kernel space. Counters are
maintained in the kernel to track the requests and use of kernel
memory, based on the type of data structure or service. The
IBM.PSSP.Mem.Kmem.* resource variables can be used to monitor the
number, size and state of requests for buffers allocated in kernel
memory.

Example expression:

To receive a notification that the number of kernel memory buffers
used for sockets on node 3 has exceeded 500, one could register
for the event that follows:

    Resource variable: IBM.PSSP.aixos.Mem.Kmem.inuse
    Resource ID:       NodeNum=3;Type=socket
    Expression:        X > 500

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.
Wildcarding the Type resource ID element results in the query or
event registration being applied to all kernel memory buffer types.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The ammount of memory that is currently in use (bytes).

The IBM.PSSP.aixos.Mem.Kmem.memuse resource variable represents the
amount, in bytes, of kernel memory buffers that are currently in use.
The resource ID element, "NodeNum" is used to specify the number of
the node to be monitored. The resource ID element "Type" is used to
specify the type of kernel memory to be monitored.

Valid values for the "Type" resource ID element are:

    mbuf     - Network data buffer.
    socket   - Kernel socket structure.
    protcb   - Protocol control block.
    otherip  - Other IP.
    mblk     - Stream header and data.
    streams  - Other stream related memory.
    other    - Other kernel memory.

This variable is supplied by the "aixos" resource monitor.

There are two protection modes that processes execute in, kernel
(or system) level and user level. Processes executing in kernel
mode run with kernel privileges and have access to kernel data.
These processes include kernel processes (kprocs), and services
(such as system calls and device drivers).

AIX provides routines used by the kernel and by services executing at
system level for allocating memory in kernel space. Counters are
maintained in the kernel to track the requests and use of kernel
memory, based on the type of data structure or service. The
IBM.PSSP.Mem.Kmem.* resource variables can be used to monitor the
number, size and state of requests for buffers allocated in kernel
memory.

Example expression:

To obtain a snapshot of kernel memory usage in bytes on all nodes,
one could query using the information that follows:

    Resource variable: IBM.PSSP.aixos.Mem.Kmem.memuse
    Resource ID:       NodeNum=*;Type=*

The wildcarding the NodeNum and Type resource ID elements will
result in querying all kernel memory buffer types on all nodes
in the domain.

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.
Wildcarding the Type resource ID element results in the query or
event registration being applied to all kernel memory buffer types.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The percentage of memory which is free.

The IBM.PSSP.aixos.Mem.Real.%free resource variable represents the
percent of real page frames that are currently available on the VMM
free list. The resource ID element, "NodeNum" is used to specify
the number of the node to be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may be shared between processes or private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and the reading and writing of pages to disk storage.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. A page fault occurs when a page that is not in real memory
is referenced. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage faults
in the segment, and user-tunable thresholds. The number of frames reassigned
to the free list is also determined by VMM thresholds.

Memory regions defined in either system or user space may be pinned.
Pinning a memory region prohibits the pager from stealing pages from the
pages backing the pinned memory region. Once a memory region is pinned,
accessing that region does not result in a page fault until the region
is subsequently unpinned. While a portion of the AIX kernel remains
pinned, many regions are pagable and are only pinned while being accessed.

Thresholds used by the VMM include the minimum and maximum number of
pages to be maintained on the free list (used to determine when the VMM
should start or stop stealing pages to replenish the free list), and the
maximum percentage of real memory which may be pinned. The values of these
thresholds may be queried or altered using the system command vmtune.

Example expression:

To be notified each time the percentage of free page frames drops below
5 on node 7, one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Real.%free
    Resource ID:        NodeNum=7
    Expression:         X < 5

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The percentage of memory which is pinned.

The IBM.PSSP.aixos.Mem.Real.%pinned resource variable represents the
percentage of real page frames that are currently pinned and cannot be
paged out. The resource ID element, "NodeNum" is used to specify
the number of the node to be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may be shared between processes or private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and the reading and writing of pages to disk storage.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. A page fault occurs when a page that is not in real memory
is referenced. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage faults
in the segment, and user-tunable thresholds. The number of frames reassigned
to the free list is also determined by VMM thresholds.

Memory regions defined in either system or user space may be pinned.
Pinning a memory region prohibits the pager from stealing pages from the
pages backing the pinned memory region. Once a memory region is pinned,
accessing that region does not result in a page fault until the region
is subsequently unpinned. While a portion of the AIX kernel remains
pinned, many regions are pagable and are only pinned while being accessed.

Thresholds used by the VMM include the minimum and maximum number of
pages to be maintained on the free list (used to determine when the VMM
should start or stop stealing pages to replenish the free list), and the
maximum percentage of real memory which may be pinned. The values of these
thresholds may be queried or altered using the system command vmtune.

Example expression:

To be notified each time the percentage of pinned pages exceeds 75 on
node 7, one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Real.%pinned
    Resource ID:        NodeNum=7
    Expression:         X > 75

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The number of pages on the free list.

The IBM.PSSP.aixos.Mem.Real.numfrb resource variable represents the
number of real page frames that are currently available on the VMM
free list. The resource ID element, "NodeNum" is used to specify
the number of the node to be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may be shared between processes or private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and the reading and writing of pages to disk storage.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. A page fault occurs when a page that is not in real memory
is referenced. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage faults
in the segment, and user-tunable thresholds. The number of frames reassigned
to the free list is also determined by VMM thresholds.

Memory regions defined in either system or user space may be pinned.
Pinning a memory region prohibits the pager from stealing pages from the
pages backing the pinned memory region. Once a memory region is pinned,
accessing that region does not result in a page fault until the region
is subsequently unpinned. While a portion of the AIX kernel remains
pinned, many regions are pagable and are only pinned while being accessed.

Thresholds used by the VMM include the minimum and maximum number of
pages to be maintained on the free list (used to determine when the VMM
should start or stop stealing pages to replenish the free list), and the
maximum percentage of real memory which may be pinned. The values of these
thresholds may be queried or altered using the system command vmtune.

Example expression:

To be notified each time the number of free page frames drops below
120 on node 7, one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Real.numfrb
    Resource ID:        NodeNum=7
    Expression:         X < 120

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The size of the physical memory (4K pages).

The IBM.PSSP.aixos.Mem.Real.size resource variable represents the
actual size of the real system memory (RAM) as the number of real
page frames. The resource ID element, "NodeNum" is used to specify
the number of the node to be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may be shared between processes or private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and the reading and writing of pages to disk storage.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. A page fault occurs when a page that is not in real memory
is referenced. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage faults
in the segment, and user-tunable thresholds. The number of frames reassigned
to the free list is also determined by VMM thresholds.

Memory regions defined in either system or user space may be pinned.
Pinning a memory region prohibits the pager from stealing pages from the
pages backing the pinned memory region. Once a memory region is pinned,
accessing that region does not result in a page fault until the region
is subsequently unpinned. While a portion of the AIX kernel remains
pinned, many regions are pagable and are only pinned while being accessed.

Thresholds used by the VMM include the minimum and maximum number of
pages to be maintained on the free list (used to determine when the VMM
should start or stop stealing pages to replenish the free list), and the
maximum percentage of real memory which may be pinned. The values of these
thresholds may be queried or altered using the system command vmtune.

Example expression:

To obtain the size of real memory (RAM) on all nodes, one could query
the Event Management subsystem using the information that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Real.size
    Resource ID:        NodeNum=*

The wildcarded NodeNum resource ID element value will result in the
query being applied to all nodes in the domain. The size returned
from each node is reported in number of page frames.

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The rate of 4K pages read by VMM.

The IBM.PSSP.aixos.Mem.Virt.pagein resource variable represents the
rate, in pages per second, that the VMM is reading pages for both
persistent and working segments from disk storage. The resource ID
element, "NodeNum", is used to specify the number of the node to
be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may either be shared between processes or be
private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, and referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and reading and writing of pages to disk storage. A page fault
occurs when a page that is not in real memory is referenced.

Segments managed by the VMM are considered to be persistent or working.
The pages of a persistent segment have permanent storage locations
on disk. Data files or executable programs are mapped to persistent
segments. Since the pages of a persistent segment have a permanent
storage location, if the VMM needs to move such a page from real
memory, it can write a changed page back to its permanent location,
or simply free the page frame if it was not altered and re-read
the page page on a subsequent request.

Working segments are transitory and exist only during their use by
a process. Examples are process stack and data regions, kernel and
kernel-extension text segments, and shared-library text and data
segments. Pages of working segments also require disk storage
locations when they cannot be kept in real memory. Disk paging space
is used for this purpose.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage
faults in the segment, and user-tunable thresholds. The number of frames
reassigned to the free list is also determined by VMM thresholds.

Example expression:

To be notified each time the rate of pages read by the VMM for
both persistent and working segments exceeds 500 per second
on node 5, one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Virt.pagein
    Resource ID:        NodeNum=5
    Expression:         X > 500

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* and IBM.PSSP.aixos.pgsp.* resource variables
may be used to monitor attributes of paging space.

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The rate of 4K pages written by VMM.

The IBM.PSSP.aixos.Mem.Virt.pageout resource variable represents the
rate, in pages per second, that the VMM is writing pages for both
persistent and working segments to disk storage. The resource ID
element, "NodeNum", is used to specify the number of the node to
be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may either be shared between processes or be
private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, and referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and reading and writing of pages to disk storage. A page fault
occurs when a page that is not in real memory is referenced.

Segments managed by the VMM are considered to be persistent or working.
The pages of a persistent segment have permanent storage locations
on disk. Data files or executable programs are mapped to persistent
segments. Since the pages of a persistent segment have a permanent
storage location, if the VMM needs to move such a page from real
memory, it can write a changed page back to its permanent location,
or simply free the page frame if it was not altered and re-read
the page page on a subsequent request.

Working segments are transitory and exist only during their use by
a process. Examples are process stack and data regions, kernel and
kernel-extension text segments, and shared-library text and data
segments. Pages of working segments also require disk storage
locations when they cannot be kept in real memory. Disk paging space
is used for this purpose.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage
faults in the segment, and user-tunable thresholds. The number of frames
reassigned to the free list is also determined by VMM thresholds.

Example expression:

To be notified each time the rate of pages written by the VMM for
both persistent and working segments exceeds 500 pages per second
on node 5, one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Virt.pageout
    Resource ID:        NodeNum=5
    Expression:         X > 500

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* and IBM.PSSP.aixos.pgsp.* resource variables
may be used to monitor attributes of paging space.

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The rate of page faults.

The IBM.PSSP.aixos.Mem.Virt.pagexct resource variable represents the
average rate of page faults that occur per second. The resource ID
element, "NodeNum", is used to specify the number of the node to
be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may either be shared between processes or be
private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, and referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and reading and writing of pages to disk storage. A page fault
occurs when a page that is not in real memory is referenced.

Segments managed by the VMM are considered to be persistent or working.
The pages of a persistent segment have permanent storage locations
on disk. Data files or executable programs are mapped to persistent
segments. Since the pages of a persistent segment have a permanent
storage location, if the VMM needs to move such a page from real
memory, it can write a changed page back to its permanent location,
or simply free the page frame if it was not altered and re-read
the page page on a subsequent request.

Working segments are transitory and exist only during their use by
a process. Examples are process stack and data regions, kernel and
kernel-extension text segments, and shared-library text and data
segments. Pages of working segments also require disk storage
locations when they cannot be kept in real memory. Disk paging space
is used for this purpose.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage
faults in the segment, and user-tunable thresholds. The number of frames
reassigned to the free list is also determined by VMM thresholds.

Example expression:

To be notified each time the number of page faults per second
on node 5 exceeds 500, one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Virt.pagexct
    Resource ID:        NodeNum=5
    Expression:         X > 500

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* and IBM.PSSP.aixos.pgsp.* resource variables
may be used to monitor attributes of paging space.

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The rate of 4K pages read from paging space by VMM.

The IBM.PSSP.aixos.Mem.Virt.pgspgin resource variable represents the
rate, in pages per second, that the VMM is reading pages of working
segments from paging space disk storage. The resource ID element,
"NodeNum", is used to specify the number of the node to be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may either be shared between processes or be
private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, and referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and reading and writing of pages to disk storage. A page fault
occurs when a page that is not in real memory is referenced.

Segments managed by the VMM are considered to be persistent or working.
The pages of a persistent segment have permanent storage locations
on disk. Data files or executable programs are mapped to persistent
segments. Since the pages of a persistent segment have a permanent
storage location, if the VMM needs to move such a page from real
memory, it can write a changed page back to its permanent location,
or simply free the page frame if it was not altered and re-read
the page page on a subsequent request.

Working segments are transitory and exist only during their use by
a process. Examples are process stack and data regions, kernel and
kernel-extension text segments, and shared-library text and data
segments. Pages of working segments also require disk storage
locations when they cannot be kept in real memory. Disk paging space
is used for this purpose.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage
faults in the segment, and user-tunable thresholds. The number of frames
reassigned to the free list is also determined by VMM thresholds.

Example expression:

To be notified each time more than 500 pages per second are read
by the VMM on node 5 from paging space devices only (working segments),
one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Virt.pgspgin
    Resource ID:        NodeNum=5
    Expression:         X > 500

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* and IBM.PSSP.aixos.pgsp.* resource variables
may be used to monitor attributes of paging space.

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 The rate of 4K pages written to paging space by VMM.

The IBM.PSSP.aixos.Mem.Virt.pgspgout resource variable represents the
rate, in pages per second, that the VMM is writing pages of working
segments from paging space disk storage. The resource ID element,
"NodeNum", is used to specify the number of the node to be monitored.

This variable is supplied by the "aixos" resource monitor.

The RS/6000 virtual address space is partitioned into segments. Segments
are fixed-size, contiguous portions of the virtual address space.
Process addressability to data is at the segment (or object) level
so that a segment may either be shared between processes or be
private.

Virtual memory segments are partitioned into fixed-size units called
pages. Each page in a segment may be in real memory (RAM), or stored
on disk until needed. Real memory is partitioned into units, equal in
size to virtual pages, and referred to as page frames. To accommodate a
large virtual memory space with a limited real memory space, the
system uses real memory for work space and maps inactive data and
programs to disk. The VMM (Virtual Memory Manager) manages the
allocation of real memory page frames, resolves references to virtual
memory pages that are not currently in real memory (or do not yet
exist), and reading and writing of pages to disk storage. A page fault
occurs when a page that is not in real memory is referenced.

Segments managed by the VMM are considered to be persistent or working.
The pages of a persistent segment have permanent storage locations
on disk. Data files or executable programs are mapped to persistent
segments. Since the pages of a persistent segment have a permanent
storage location, if the VMM needs to move such a page from real
memory, it can write a changed page back to its permanent location,
or simply free the page frame if it was not altered and re-read
the page page on a subsequent request.

Working segments are transitory and exist only during their use by
a process. Examples are process stack and data regions, kernel and
kernel-extension text segments, and shared-library text and data
segments. Pages of working segments also require disk storage
locations when they cannot be kept in real memory. Disk paging space
is used for this purpose.

The VMM maintains a list of free page frames that it uses to accommodate
page faults. In most environments, the VMM must occasionally add to
the free list by reassigning some page frames owned by running processes.
The virtual-memory pages whose page frames are to be reassigned are
selected by the VMM's page-replacement algorithm which takes into
consideration the segment type, statistics regarding rate of repage
faults in the segment, and user-tunable thresholds. The number of frames
reassigned to the free list is also determined by VMM thresholds.

Example expression:

To be notified each time more than 500 pages per second are written
by the VMM on node 5 to paging space devices only (working segments),
one could register for the event that follows:

    Resource variable:  IBM.PSSP.aixos.Mem.Virt.pgspgout
    Resource ID:        NodeNum=5
    Expression:         X > 500

Resource ID wildcarding:

The NodeNum resource ID element value may be wildcarded to
apply a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* and IBM.PSSP.aixos.pgsp.* resource variables
may be used to monitor attributes of paging space.

IBM.PSSP.aixos.Mem.Kmem.* variables may be used to monitor attributes
of kernel memory.

  IBM.PSSP.aixos.Mem.Kmem.calls     Number of requests for a kernel
                                    memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.failures  Number of unsuccessful requests for a
                                    kernel memory buffer.

  IBM.PSSP.aixos.Mem.Kmem.inuse     Count of kernel memory buffers in
                                    use.

  IBM.PSSP.aixos.Mem.Kmem.memuse    Current memory use (bytes).

IBM.PSSP.aixos.Mem.Real.* variables may be used to monitor attributes
of real (RAM) memory.

  IBM.PSSP.aixos.Mem.Real.%free     Percent memory which is free.

  IBM.PSSP.aixos.Mem.Real.%pinned   Percent memory which is pinned.

  IBM.PSSP.aixos.Mem.Real.numfrb    Number of pages on free list.

  IBM.PSSP.aixos.Mem.Real.size      Size of physical memory (4K pages).

IBM.PSSP.aixos.Mem.Virt.* variables may be used to monitor attributes
of virtual memory.

  IBM.PSSP.aixos.Mem.Virt.pagein    4K pages read by VMM.

  IBM.PSSP.aixos.Mem.Virt.pageout   4K pages written by VMM.

  IBM.PSSP.aixos.Mem.Virt.pagexct   Total page faults.

  IBM.PSSP.aixos.Mem.Virt.pgspgin   4K pages read from paging space
                                    by VMM.

  IBM.PSSP.aixos.Mem.Virt.pgspgout  4K pages written to paging space
                                    by VMM.
 Free portion of this paging space (percent).

IBM.PSSP.aixos.pagsp.%free represents the percentage of free paging
space available for a specific paging-space logical volume. The resource
variable's resource ID specifies the name of the paging-space (Name),
and the number of the node (NodeNum) on which the paging-space device
resides.

This variable is supplied by the "aixos" resource monitor.

A paging space is fixed disk storage for information that is resident
in virtual memory, but is not currently being accessed. A paging space,
or swap space, is a logical volume with the attribute type equal to
paging. When the amount of free real memory in the system is low,
programs or data that have not been used recently are moved from real
memory to paging space to release real memory for other activities.

The lsps command can be used to display information about paging space
defined on a system. lsps -a displays the characteristics of all
paging spaces defined on the system. For example:

  # lsps -a
  Page Space Physical Volume Volume Group Size  %Used Active Auto Type
  paging01   hdisk0          rootvg       256MB    20    yes  yes   lv
  paging00   hdisk0          rootvg       256MB    20    yes  yes   lv
  hd6        hdisk0          rootvg       256MB    25    yes  yes   lv

Shows that the system the command was executed on has three 256M
paging spaces defined and active. 

Limitations:

There is another type of paging space which is accessed through a device
that uses an NFS server for paging-space storage. The IBM.PSSP.aixos.pagsp.*
resource variables are available only for paging-space logical volumes, and are
not available for NFS mounted paging-space. However, the global paging-space
resource variables, IBM.PSSP.aixos.PagSp.*, do include NFS mounted paging-spaces
in their values.

Example expression:

The amount of paging space required depends upon the types of activities
performed on the system. If paging space runs low, processes may be 
lost, and if paging space runs out, the system may panic. Paging space 
shortage may cause memory performance degradation and thrashing can 
occur (if VMM memory load control is turned off).

The system monitors the number of free paging space blocks and detects
when a paging-space shortage exists. When the number of free paging
blocks falls below a threshold known as the paging-space warning level,
the system informs all processes (except kprocs) of this condition by
sending the SIGDANGER signal. If the shortage continues and falls
below a second threshold known as the paging-space terminate level, the 
system sends the SIGKILL signal to processes that are the major users of
paging space and that do not have a signal handler for the SIGDANGER 
signal.

The warning and terminate level thresholds can be obtained and altered using the
command vmtune (npswarn and npskill parameters respectively).

Processes executing in the early allocation environment avoid receiving
the SIGKILL signal if a low paging space condition occurs. If the PSALLOC
environment variable is set to "early" when a program starts, paging
space is reserved at the time the process makes a memory request. If
there is insufficient paging space, the early allocation alogrithm used
by the operating system will cause the memory request to be unsuccessful. If
the PSALLOC environment is not set, or is set to any value other than "early",
the operating system uses a late allocation algorithm for memory and
paging space allocation. Late allocation does not reserve paging space
at the time the memory is requested, but defers the reservation until the
pages are touched.

Note: The VMM is a complex system and paging space requirements depend
on a number of factors including the paging space allocation policy 
used, amount of real memory, and type of activities performed on the 
system. A thorough understanding of system paging requirements and AIX 
memory management is recommended before attempting to alter VMM operating
operating parameters or selecting a system paging space allocation policy.

To be notified when less than 20% of paging space "paging01" on node
5 is free, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.pagsp.%free
    Resource ID:       Name=paging01;NodeNum=5
    Expression:        X < 256

Resource ID wildcarding:

Both the "Name" and "NodeNum" resource ID elements may be wildcarded
to apply a query or event registration to all paging-spaces on
the target node or nodes (Name=*), or all nodes in the domain (NodeNum=*),
or both.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* variables represent the global state
of all active (including NFS mounted) paging spaces, defined in
the system. 

  IBM.PSSP.aixos.PagSp.%totalfree  Total free disk space (percent).
  
  IBM.PSSP.aixos.PagSp.%totalused  Total used disk paging space 
                                   (percent).
  
  IBM.PSSP.aixos.PagSp.totalfree   Total free disk paging space
                                   (4K pages).
  
  IBM.PSSP.aixos.PagSp.totalsize   Total active paging space 
                                   size (4K pages).

IBM.PSSP.aixos.pagsp.* variables may be used to monitor attributes
of specific paging-space logical volumes.

  IBM.PSSP.aixos.pagsp.%free       Free portion of this paging 
                                   space (percent).

  IBM.PSSP.aixos.pagsp.size        Size of paging space (4K pages). Total free disk space (percent).

IBM.PSSP.aixos.PagSp.%totalfree represents the percentage of free 
paging space available for all active paging-space logical volumes
on a node. The resource variable's resource ID specifies the number
of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

A paging space is fixed disk storage for information that is resident
in virtual memory, but is not currently being accessed. A paging space,
or swap space, is a logical volume with the attribute type equal to
paging. When the amount of free real memory in the system is low,
programs or data that have not been used recently are moved from real
memory to paging space to release real memory for other activities.

There is another type of paging-space available which can be accessed
through a device that uses an NFS server for paging-space storage. The
IBM.PSSP.aixos.PagSp.* resource variables include in their total values
both paging-space logical volumes and NFS mounted paging-space.

The lsps command can be used to display information about paging space
defined on a system. lsps -a displays the characteristics of all
paging spaces defined on the system. For example:

  # lsps -a
  Page Space Physical Volume Volume Group Size  %Used Active Auto Type
  paging01   hdisk0          rootvg       256MB    20    yes  yes   lv
  paging00   hdisk0          rootvg       256MB    20    yes  yes   lv
  hd6        hdisk0          rootvg       256MB    25    yes  yes   lv

Shows that the system the command was executed on has three 256M
paging spaces defined and active. 

Example expression:

The amount of paging space required depends upon the types of activities
performed on the system. If paging space runs low, processes may be
lost, and if paging space runs out, the system may panic. Paging space
shortage may cause memory performance degradation and thrashing can 
occur (if VMM memory load control is turned off).

To be notified when more than 90% of the total paging space on node 5
is in use, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.PagSp.%totalfree
    Resource ID:       NodeNum=5 
    Expression:        X < 10

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* variables represent the global state
of all active (including NFS mounted) paging spaces, defined in
the system. 

  IBM.PSSP.aixos.PagSp.%totalfree  Total free disk space (percent).
  
  IBM.PSSP.aixos.PagSp.%totalused  Total used disk paging 
                                   space (percent).
  
  IBM.PSSP.aixos.PagSp.totalfree   Total free disk paging space 
                                   (4K pages).
  
  IBM.PSSP.aixos.PagSp.totalsize   Total active paging space 
                                   size (4K pages).

IBM.PSSP.aixos.pagsp.* variables may be used to monitor attributes
of specific paging-space logical volumes.

  IBM.PSSP.aixos.pagsp.%free       Free portion of this paging 
                                   space (percent).
  
  IBM.PSSP.aixos.pagsp.size        Size of paging space (4K pages). Total used disk paging space (percent).

IBM.PSSP.aixos.PagSp.%totalused represents the percentage paging space
in use for all active paging-space logical volumes on a node.  The resource
variable's resource ID specifies the number of the node (NodeNum) to be
monitored.

This variable is supplied by the "aixos" resource monitor.

A paging space is fixed disk storage for information that is resident
in virtual memory, but is not currently being accessed. A paging space,
or swap space, is a logical volume with the attribute type equal to
paging. When the amount of free real memory in the system is low,
programs or data that have not been used recently are moved from real
memory to paging space to release real memory for other activities.

There is another type of paging-space available which can be accessed
through a device that uses an NFS server for paging-space storage. The
IBM.PSSP.aixos.PagSp.* resource variables include in their total values
both paging-space logical volumes and NFS mounted paging-space.

The lsps command can be used to display information about paging space
defined on a system. lsps -a displays the characteristics of all
paging spaces defined on the system. For example:

  # lsps -a
  Page Space Physical Volume Volume Group Size  %Used Active Auto Type
  paging01   hdisk0          rootvg       256MB    20    yes  yes   lv
  paging00   hdisk0          rootvg       256MB    20    yes  yes   lv
  hd6        hdisk0          rootvg       256MB    25    yes  yes   lv

Shows that the system the command was executed on has three 256M
paging spaces defined and active. 

Example expression:

The amount of paging space required depends upon the types of activities
performed on the system. If paging space runs low, processes may be 
lost, and if paging space runs out, the system may panic. Paging space
shortage may cause memory performance degradation and thrashing can
occur (if VMM memory load control is turned off).

To be notified when more than 90% of the total paging space on node 5
is in use, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.PagSp.%totalused
    Resource ID:       NodeNum=5
    Expression:        X > 90

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* variables represent the global state
of all active (including NFS mounted) paging spaces, defined in
the system. 

  IBM.PSSP.aixos.PagSp.%totalfree  Total free disk space (percent).
  
  IBM.PSSP.aixos.PagSp.%totalused  Total used disk paging space 
                                   (percent).
  
  IBM.PSSP.aixos.PagSp.totalfree   Total free disk paging space 
                                   (4K pages).
  
  IBM.PSSP.aixos.PagSp.totalsize   Total active paging space 
                                   size (4K pages).

IBM.PSSP.aixos.pagsp.* variables may be used to monitor attributes
of specific paging-space logical volumes.

  IBM.PSSP.aixos.pagsp.%free       Free portion of this paging 
                                   space (percent).
  
  IBM.PSSP.aixos.pagsp.size        Size of paging space (4K pages). The size of the paging space (4K pages).

IBM.PSSP.aixos.pagsp.size represents the size of a specific paging space
logical volume. The resource variable's resource ID specifies the name of
the paging-space (Name), and the number of the node (NodeNum) on which the
paging-space device resides.

This variable is supplied by the "aixos" resource monitor.

A paging space is fixed disk storage for information that is resident
in virtual memory, but is not currently being accessed. A paging space,
or swap space, is a logical volume with the attribute type equal to
paging. When the amount of free real memory in the system is low,
programs or data that have not been used recently are moved from real
memory to paging space to release real memory for other activities.

The lsps command can be used to display information about paging space
defined on a system. lsps -a displays the characteristics of all
paging spaces defined on the system. For example:

  # lsps -a
  Page Space Physical Volume Volume Group Size  %Used Active Auto Type
  paging01   hdisk0          rootvg       256MB    20    yes  yes   lv
  paging00   hdisk0          rootvg       256MB    20    yes  yes   lv
  hd6        hdisk0          rootvg       256MB    25    yes  yes   lv

Shows that the system the command was executed on has three 256M
paging spaces defined and active. 

Limitations:

There is another type of paging space which is accessed through a device
that uses an NFS server for paging-space storage. The IBM.PSSP.aixos.pagsp.*
resource variables are available only for paging-space logical volumes, and are
not available for NFS mounted paging-space. However, the global paging-space
resource variables, IBM.PSSP.aixos.PagSp.*, do include NFS mounted paging-spaces
in their values.

Example expression:

The size of an active paging space will remain constant unless altered
using the chps command. Using the example lsps output, the size of
paging space "paging01" could be queried on node 5, by specifying 
the information that follows:n
    Resource variable: IBM.PSSP.aixos.pagsp.size
    Resource ID:       Name=paging01;NodeNum=5

To be notified that the size of paging space "paging01" has been changed
on node 5, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.pagsp.size
    Resource ID:       Name=paging01;NodeNum=5
    Expression:        X != X@P

Resource ID wildcarding:

Both the "Name" and "NodeNum" resource ID elements may be wildcarded
to apply a query or event registration to all paging-spaces on
the target node(s) (Name=*), or all nodes in the domain (NodeNum=*),
or both.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* variables represent the global state
of all active (including NFS mounted) paging spaces, defined in
the system. 

  IBM.PSSP.aixos.PagSp.%totalfree  Total free disk space (percent).
  
  IBM.PSSP.aixos.PagSp.%totalused  Total used disk paging space 
                                   (percent).
  
  IBM.PSSP.aixos.PagSp.totalfree   Total free disk paging space 
                                   (4K pages).
  
  IBM.PSSP.aixos.PagSp.totalsize   Total active paging space 
                                   size (4K pages).

IBM.PSSP.aixos.pagsp.* variables may be used to monitor attributes
of specific paging-space logical volumes.

  IBM.PSSP.aixos.pagsp.%free       Free portion of this paging 
                                   space (percent).
  
  IBM.PSSP.aixos.pagsp.size        Size of paging space (4K pages). Total free disk paging space (4K pages).

IBM.PSSP.aixos.PagSp.totalfree represents the size, in 4k pages, of
available paging space for all active paging-space logical volumes
on a node. The resource variable's resource ID specifies the number 
of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

A paging space is fixed disk storage for information that is resident
in virtual memory, but is not currently being accessed. A paging space,
or swap space, is a logical volume with the attribute type equal to
paging. When the amount of free real memory in the system is low,
programs or data that have not been used recently are moved from real
memory to paging space to release real memory for other activities.

There is another type of paging-space available which can be accessed
through a device that uses an NFS server for paging-space storage. The
IBM.PSSP.aixos.PagSp.* resource variables include in their total values
both paging-space logical volumes and NFS mounted paging-space.

The lsps command can be used to display information about paging space
defined on a system. lsps -a displays the characteristics of all
paging spaces defined on the system. For example:

  # lsps -a
  Page Space Physical Volume Volume Group Size  %Used Active Auto Type
  paging01   hdisk0          rootvg       256MB    20    yes  yes   lv
  paging00   hdisk0          rootvg       256MB    20    yes  yes   lv
  hd6        hdisk0          rootvg       256MB    25    yes  yes   lv

Shows that the system the command was executed on has three 256M
paging spaces defined and active. 

Example expression:

The amount of paging space required depends upon the types of activities
performed on the system. If paging space runs low, processes may be 
lost, and if paging space runs out, the system may panic. Paging space
shortage may cause memory performance degradation and thrashing can
occur (if VMM memory load control is turned off).

The system monitors the number of free paging space blocks and detects
when a paging-space shortage exists. When the number of free paging 
blocks falls below a threshold known as the paging-space warning level,
the system informs all processes (except kprocs) of this condition by
sending the SIGDANGER signal. If the shortage continues and falls
below a second threshold known as the paging-space terminate level, the 
system sends the SIGKILL signal to processes that are the major users 
of paging space and that do not have a signal handler for the SIGDANGER
signal.

The warning and terminate level thresholds can be obtained and altered by
the command vmtune (npswarn and npskill parameters respectively).

Processes executing in the early allocation environment avoid receiving
the SIGKILL signal if a low paging space condition occurs. If the PSALLOC
environment variable is set the "early" when a program starts, paging
space is reserved at the time the process makes a memory request. If
there is insufficient paging space, the early allocation alogrithm used
by the operating system will cause the memory request to be unsuccessful. If the
PSALLOC environment is not set, or is set to any value other than "early",
the operating system uses a late allocation algorithm for memory and
paging space allocation. Late allocation does not reserve paging space
at the time the memory is requested, but defers the reservation until the
pages are touched.

Note: The VMM is a complex system and paging space requirements depend 
on a number of factors including the paging space allocation policy
used, amount of real memory, and type of activities performed on the 
system. A thorough understanding of system paging requirements and AIX 
memory management is recommended before attempting to alter VMM 
operating parameters.

The event registration examples that follows could be used to generate a
notification when the system is nearing the paging-space warning and 
terminate level thresholds. The examples assume a warning level of 2048 4k
pages (8 megabytes), and a terminate level of 512 4k pages (2 megabytes). 

To be notified that the VMM is within 2 megabytes (512 4k pages) of 
reaching the paging-space warning level, one could register for the 
event that follows: 

    Resource variable: IBM.PSSP.aixos.PagSp.totalfree
    Resource ID:       NodeNum=* 
    Expression:        X <= 2560
    Re-arm expression: X > 2560

The wildcarded NodeNum resource ID element will result in the event being
registered on all nodes in the domain. The re-arm expression could be
optionally included to cause a notification to be sent when the 
expression condition is no longer true (if the HA_EM_CMD_REG2 command
is used).

To receive a further notification that the npswarn threshold was 
exceeded, and the system is nearing the paging-space terminate level, one 
could register for the event that follows: 

    Resource variable: IBM.PSSP.aixos.PagSp.totalfree
    Resource ID:       NodeNum=* 
    Expression:        X <= 1024

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* variables represent the global state
of all active (including NFS mounted) paging spaces, defined in
the system. 

  IBM.PSSP.aixos.PagSp.%totalfree  Total free disk space (percent).
  
  IBM.PSSP.aixos.PagSp.%totalused  Total used disk paging space 
                                   (percent).
  
  IBM.PSSP.aixos.PagSp.totalfree   Total free disk paging space 
                                   (4K pages).
  
  IBM.PSSP.aixos.PagSp.totalsize   Total active paging space 
                                   size (4K pages).

IBM.PSSP.aixos.pagsp.* variables may be used to monitor attributes
of specific paging-space logical volumes.

  IBM.PSSP.aixos.pagsp.%free       Free portion of this paging 
                                   space (percent).
  
  IBM.PSSP.aixos.pagsp.size        Size of paging space (4K pages). Total active paging space size (4K pages).

IBM.PSSP.aixos.PagSp.totalsize represents the total size of all active
active paging-space logical volumes. The resource variable's resource 
ID specifies the number of the node (NodeNum) to be monitored.

This variable is supplied by the "aixos" resource monitor.

A paging space is fixed disk storage for information that is resident
in virtual memory, but is not currently being accessed. A paging space,
or swap space, is a logical volume with the attribute type equal to
paging. When the amount of free real memory in the system is low,
programs or data that have not been used recently are moved from real
memory to paging space to release real memory for other activities.

There is another type of paging-space available which can be accessed
through a device that uses an NFS server for paging-space storage. The
IBM.PSSP.aixos.PagSp.* resource variables include in their total values
both paging-space logical volumes and NFS mounted paging-space.

The lsps command can be used to display information about paging space
defined on a system. lsps -a displays the characteristics of all
paging spaces defined on the system. For example:

  # lsps -a
  Page Space Physical Volume Volume Group Size  %Used Active Auto Type
  paging01   hdisk0          rootvg       256MB    20    yes  yes   lv
  paging00   hdisk0          rootvg       256MB    20    yes  yes   lv
  hd6        hdisk0          rootvg       256MB    25    yes  yes   lv

Shows that the system the command was executed on has three 256M
paging spaces defined and active. 

Example expression:

The size of the active paging space on a system remains constant
until it is changed, a new paging-space is added or a paging-space is
removed. The "totalsize" resource variable may be used to query the
total active sizes on each node in the domain, by specifying the
information in the query that follows:

    Resource variable: IBM.PSSP.aixos.PagSp.totalsize
    Resource ID:       NodeNum=* 
 
To be notified that the total size of paging space on any node in the
domain has changed, one could register for the event that follows:

    Resource variable: IBM.PSSP.aixos.PagSp.totalsize
    Resource ID:       NodeNum=* 
    Expression:        X != X@P 

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply
a query or event registration to all nodes within the domain.

Related Resource Variables:

The IBM.PSSP.aixos.PagSp.* variables represent the global state
of all active (including NFS mounted) paging spaces, defined in
the system. 

  IBM.PSSP.aixos.PagSp.%totalfree  Total free disk space (percent).
  
  IBM.PSSP.aixos.PagSp.%totalused  Total used disk paging 
                                   space (percent).
  
  IBM.PSSP.aixos.PagSp.totalfree   Total free disk paging space 
                                   (4K pages).
  
  IBM.PSSP.aixos.PagSp.totalsize   Total active paging space 
                                   size (4K pages).

IBM.PSSP.aixos.pagsp.* variables may be used to monitor attributes
of specific paging-space logical volumes.

  IBM.PSSP.aixos.pagsp.%free       Free portion of this paging 
                                   space (percent).
  
  IBM.PSSP.aixos.pagsp.size        Size of paging space (4K pages). The average number of processes that are waiting for the cpu.

IBM.PSSP.aixos.Proc.runque represents the average number of processes
on the run queue, waiting for the CPU. The resource variable's resource
ID specifies the number of the node (NodeNum) on which to monitor the
run queue.

This variable is supplied by the "aixos" resource monitor.

The AIX scheduler maintains a run queue of all of the processes 
that are ready to be dispatched. Each second, the process table  
is scanned to determine which processes are ready to run. If one
or more processes are ready, they are placed on the run queue
and a counter is incremented. The counter is used to compute the
value of the IBM.PSSP.aixos.Proc.runque variable as the average 
number of ready to run processes.

The scheduler also scans the process table for processes which
are inactive because they are waiting to be paged in. A swapped
process may (or may not) have some or all of its pages moved to
the swap (page) device. As with the the "runque" variable, the system
maintains a number and update counter for swapped processes,
which are used to compute the value of IBM.PSSP.aixos.Proc.swpque
as the average number of processes swapped out. A process must be
paged in and marked nonswapped before it can be placed on the run 
queue for execution. 

Example expression:

To be notified each time the average number of of processes on the 
run queue on node 7 has increased by 50% or more between observations,
one could register for the event that follows: 

    Resource varible: IBM.PSSP.aixos.Proc.runque
    Resource ID:      NodeNum=7
    Expression:       (X - X@P) >= (X@P * .5)

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply a
query or event registration to all nodes within the domain.

Related resource variables:

  IBM.PSSP.aixos.Proc.swpque  Average count of processes waiting 
                              to be paged in. The average number of processes waiting to be paged in.

IBM.PSSP.aixos.Proc.swpque represents the average number of processes
on the swap queue, waiting to be paged in. The resource variable's resource
ID specifies the number of the node (NodeNum) on which to monitor the
run queue.

This variable is supplied by the "aixos" resource monitor.

The AIX scheduler maintains a run queue of all of the processes 
that are ready to be dispatched. Each second, the process table  
is scanned to determine which processes are ready to run. If one
or more processes are ready, they are placed on the run queue
and a counter is incremented. The counter is used to compute the
value of the IBM.PSSP.aixos.Proc.runque variable as the average 
number of ready to run processes.

The scheduler also scans the process table for processes which
are inactive because they are waiting to be paged in. A swapped
process may (or may not) have some or all of its pages moved to
the swap (page) device. As with the the "runque" variable, the system
maintains a number and update counter for swapped processes.
which are used to compute the value of IBM.PSSP.aixos.Proc.swpque
as the average number of processes swapped out. A process must be
paged in and marked nonswapped before it can be placed on the run 
queue for execution. 

Example expression:

To be notified each time the average number of of processes swapped
out on node 7 has increased by 10 processes or more, one could
register for the event that follows: 

    Resource varible: IBM.PSSP.aixos.Proc.runque
    Resource ID:      NodeNum=7
    Expression:       (X - X@P) >= 10

Resource ID wildcarding:

The NodeNum resource ID element may be wildcarded to apply a
query or event registration to all nodes within the domain.

Related resource variables:

IBM.PSSP.aixos.Proc.runque    Average count of processes that are 
                              waiting for the cpu. NodeNum: The number of the node for which the information applies. NodeNum: The number of the node for which the information applies. CPU: The name of the CPU; for example, cpu0. NodeNum: The number of the node controlling the disk. Name: The name of the disk. NodeNum: The number of the node on which the filesystem resides. VG: The name of the volume group on which the filesystem resides. LV: The name of the logical volume on which the filesystem resides. NodeNum: The number of the node on which the volume group resides. VG: The name of the volume group. NodeNum: The number of the node containing the LAN adapter. Adapter: The name of the LAN adapter. NodeNum: The number of the node for which the information applies. Type: The type of kernel memory buffer.  Valid values are "mbuf", "socket", 
  "protcb" (protocol control block), "otherip" (other IP), "mblk" 
  (stream header and data), "streams" (other stream related memory), and 
  "other" (other kernel memory). NodeNum: The number of the node for which the information applies. NodeNum: The number of the node for which the information applies. NodeNum: The number of the node for which the information applies. Name: The name of the paging space device for which the information applies. NodeNum: The number of the node for which the information applies. NodeNum: The number of the node for which the information applies. SBS variable updated each time an SDR class is modified. The SDR class corresponding to the Class resource ID element has been modified. Instances of the SDR modification resource variable are distinguished by SDR class name. 