ONLINE monitoring: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (restoring Alex's correction which I inadvertently overwrote)
 
(30 intermediate revisions by 5 users not shown)
Line 88: Line 88:
<li>CPU is CPU time.</li>
<li>CPU is CPU time.</li>
<li>SEQIO is the sequential I/O operations performed.</li>
<li>SEQIO is the sequential I/O operations performed.</li>
<li>QUE is the [[#QUE values|current scheduler queue]]</li>
<li>QUE is the [[#QUE values|current scheduler queue]].</li>
<li>WT is the [[#Wait type values|user wait type]].</li>
<li>WT is the [[#Wait state values|user wait state]].</li>
<li>FLGS is the sum of the [[#Status flag values|status flag values]]</li>
<li>FLGS is the sum of the [[#Status flag values|status flag values]].</li>
</ul>
</ul>


Line 124: Line 124:
<td>
<td>
<p>
<p>
Blocked in server.</p>
Blocked in server, visible to the scheduler.</p>
</td>
</tr>
<tr>
<td>
<p>
OFFI </p>
</td>
<td>
<p>
Blocked in server, invisible to the scheduler.</p>
  </td>
  </td>
</tr>
</tr>
Line 135: Line 146:
<td>
<td>
<p>
<p>
Blocked out of server.</p>
Blocked out of server, visible to the scheduler.</p>
</td>
</tr>
<tr>
<td>
<p>
OFFO </p>
</td>
<td>
<p>
Blocked out of server, invisible to the scheduler.</p>
  </td>
  </td>
</tr>
</tr>
Line 146: Line 168:
<td>
<td>
<p>
<p>
Waiting for server.</p>
Waiting for a server.</p>
  </td>
  </td>
</tr>
</tr>
Line 175: Line 197:
<td>
<td>
<p>
<p>
OFFQ </p>
WTUS </p>
  </td>
  </td>
<td>
<td>
<p>
<p>
Invisible to the scheduler, off all scheduler queues. </p>
Server waiting for user.</p>
<p>This typically occurs when the user is at command level.</p>
  </td>
  </td>
</tr>
</tr>
 
 
<tr>
<tr>
<td>
<td>
<p>
<p>
WTUS </p>
MOVE</p>
  </td>
  </td>
<td>
<td>
<p>
<p>
Inactive.</p>
Moving between queues.</p>
  </td>
  </td>
</tr>
</tr>
</table>
</table>
<p class="note"><b>Tip:</b> As of version 7.7, by summing RUNG, BLKI, BLKO, WTSV, REDY, and SWPG, you can approximate USRS (average active users).</p>
<p class="note"><b>Note:</b> Prior to version 7.7, OFFQ was used instead of OFFI and OFFO.</p>


====Wait type values====
====Wait type values====
Line 201: Line 227:
<th>
<th>
<p>
<p>
Flag</p>
Wait</p>
  </th>
  </th>
<th>
<th>
Line 665: Line 691:
<td>
<td>
<p>Checkpoint PST waiting on users to complete subtransactions.</p>
<p>Checkpoint PST waiting on users to complete subtransactions.</p>
</td></tr>
<tr>
<td>
<p>57</p>
</td>
<td>
<p>Means a daemon thread waiting for its master thread.</p>
<p>This change is enabled in V7.8 or V7.7 with the application of zap 77z410.</p>
</td></tr>
<tr>
<td>
<p>58</p>
</td>
<td>
<p>Means a master thread waiting for one of its daemon threads.</p>
<p>This change is enabled in V7.8 or V7.7 with the application of zap 77z410.</p>
</td></tr>
</td></tr>


Line 720: Line 764:
<td>
<td>
<p>
<p>
User's wait is swappable. If another user needs this user's server area, the waiter may be written out.</p>
User's wait is swappable. If another user needs this user's server area, the waiter may be written out.</p></td>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<td>
<td><p>20</p></td>
<p>
<td><p>User is waiting for an internal ECB (that is, the ECB is posted only by <var class="product">Model&nbsp;204</var>, not by the operating system). This can happen, for example, if the waiting user is waiting to access a record to which someone else is preventing access. </p></td>
20</p>
</tr>
</td>
 
<td>
<tr>
<p>
<td><p>10</p></td>
User is waiting for an internal ECB (that is, the ECB is posted only by <var class="product">Model&nbsp;204</var>, not by the operating system). </p>
<td><p>ECB to be posted is of the short form (1 byte in length) and is an internal ECB (posted by M204). </p></td>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<td>
<td><p>8</p></td>
<p>
<td><p>More than one user is allowed to wait for the ECB that this user is waiting for. </p></td>
8</p>
</td>
<td>
<p>
More than one user is allowed to wait for the ECB that this user is waiting for. </p>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<td>
<td><p>4</p></td>
<p>
<td><p>User can be bumped.</p></td>
4</p>
</td>
<td>
<p>
User can be bumped.</p>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<td>
<td><p>2</p></td>
<p>
<td><p>User can be interrupted with an urgent message.</p></td>
2</p>
</td>
<td>
<p>
User can be interrupted with an urgent message.</p>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<td>
<td><p>1</p></td>
<p>
<td><p>A time limit was specified for the user's wait. For example, if a waiting user is in a record locking conflict situation, it is a timed wait until the request ends and a record locking conflict message is issued, or an <var>ON</var> unit in the code takes control.</p></td>
1</p>
</tr>
</td>
</table>
<td>
 
<p>
====V7.7 layout change====
A time limit was specified for the user's wait.</p>
From V7.7 onwards (with zaps 77Z478 or 78Z023, 78Z026) the AGE column in the basic display output has been replaced with a column, headed LOG, which shows the logon type of each user, as in the following example:
  </td>
<p class="code">
20.149  MAY 28  13.02.36        PAGE 8                                         
USER SVR        FLS  PCPU SMPLS  RUNG    REDY    BLKI    WTSV    BLKO  SWPG   
                  6 0.290                                                       
                                                                                 
USER SVR USERID    P CUR  SLICE LOG FUNC  CNCT        CPU  SEQIO QUE  WT FLGS 
  0    SUPERKLUGE H 252  0.030 CCA DISP    0      0.001    596 OFFO  4  60   
  7  4 JIMV      S  62  0.030 SUB EVAL    10      0.001      9 OFFI  3  66   
  8  2 ZORRO      S  4  0.030 PDG EVAL    93      0.003    36 OFFI  3 66   
  9  5 TSJRD      H 104  0.030 ESM        123      0.001    74 RUNG         
  10  1 CCAD01    H 110  0.030 CCA        13      0.001    52 OFFI  3  66   
  31    VT75DIED          0.000              0      0.000      0      2  20   
  32    VT75READ          0.000        253954      0.013      0      3  00   
  33    VT75ERRS          0.000              0      0.000      0      2  20   
  34    CHKPPST            0.000              0      0.001      0      12  20   
  35    CHKPAWW            0.000          5509      0.000      0      12  20   
  36    MQDELDTP          0.000              0      0.000      0      12  00   
>                                                                             
</p>
Possible values that are shown in the LOG column (logon type) are as follows
<table>
<tr class="head">
<th><p>Value</p></th>
<th><p>Meaning</p></th>
</tr>
</tr>
<tr><td><p>CCA</p></td><td><p>CCASTAT userid</p></td></tr>
<tr><td><p>ESM</p></td><td><p>userid validated by an External Security Manager - ACF2, RACF, or TopSecret</p></td></tr>
<tr><td><p>SUB</p></td><td><p>Subsystem controlled logon</p></td></tr>
<tr><td><p>GST</p></td><td><p>Guest - neither logged on via CCASTAT nor by an ESM</p></td></tr>
<tr><td><p>PDG</p></td><td><p>Logon pending due to errors (e.g. invalid password)</p></td></tr>
</table>
</table>


Line 817: Line 870:
</p>
</p>
<p>
<p>
The following MONITOR ACTIVE command specifies a single nonrepeating formatted display of basic information for the system and active users, excepting OFFQ users. OFFQ is a state-of-queue status meaning that the Scheduler does not have to evaluate those users not in the queue. This command is used to reduce the amount of terminal output.</p>
The following command, MONITOR ACTIVE, specifies a single nonrepeating formatted display of basic information for the system and active users, excepting OFFO and OFFI users. (OFFO and OFFI are state-of-queue statuses meaning that the Scheduler does not have to evaluate those users not in the queue. Prior to version 7.7, OFFQ was used instead of OFFO and OFFI.)</p>
<p>The MONITOR ACTIVE command is used to reduce the amount of terminal output.</p>
   
   
<p class="code">MONITOR ACTIVE
<p class="code">MONITOR ACTIVE
Line 878: Line 932:
<p class="code">MONITOR VTAM
<p class="code">MONITOR VTAM
</p>
</p>
 
==MONITOR LINK example==
==MONITOR LINK example==
   
   
Line 896: Line 950:
  BOSTACB      4      2    0    0    2 A    VTAM/LU62
  BOSTACB      4      2    0    0    2 A    VTAM/LU62
   
   
  USER PROCESS  SENDS RECVS FLGS PROCESSGRP
  USER   PROCESS  SENDS RECVS FLGS PROCESSGRP
  ----- -------- ----- ----- ---- ----------
  ----- -------- ----- ----- ---- ----------
     3 PROCESS1    5    4 BI  DENVER    OBSOLETE
     3 PROCESS1    5    4 BI  DENVER    OBSOLETE
     4 PROCESS1    5    4 BI  DENVER
     4 PROCESS1    5    4 BI  DENVER
</p>
</p>
   
   
Line 998: Line 1,052:
<li> PROCESSGRP provides the process group name (DENVER). In this example, user 3 is running with an OBSOLETE process group: the process group was stopped and a DEFINE PROCESSGROUP command was issued to change the process group definition for subsequent usage. User 4 is running with the most recent version of the process group definition. </li>
<li> PROCESSGRP provides the process group name (DENVER). In this example, user 3 is running with an OBSOLETE process group: the process group was stopped and a DEFINE PROCESSGROUP command was issued to change the process group definition for subsequent usage. User 4 is running with the most recent version of the process group definition. </li>
</ul>
</ul>
 
==MONITOR PROCESSGROUP example==
==MONITOR PROCESSGROUP example==
<p>
<p>
Line 1,014: Line 1,068:
  HEADQTRS DENVACB      2      1      0 A
  HEADQTRS DENVACB      2      1      0 A
   
   
  USER PROCESS  SENDS RECVS FLGS
  USER   PROCESS  SENDS RECVS FLGS
  ----- -------- ----- ----- ----
  ----- -------- ----- ----- ----
     4 PROCESS1    5    4 BI
     4 PROCESS1    5    4 BI
   
   
   
   
Line 1,025: Line 1,079:
  HEADQTRS DENVACB      2      1      0 AX
  HEADQTRS DENVACB      2      1      0 AX
   
   
  USER PROCESS  SENDS RECVS FLGS
  USER   PROCESS  SENDS RECVS FLGS
  ----- -------- ----- ----- ----
  ----- -------- ----- ----- ----
     3 PROCESS1    5    4 BI
     3 PROCESS1    5    4 BI
</p>
</p>
   
   
Line 1,109: Line 1,163:
<p class="code">MONITOR PROCESS PROCESS1
<p class="code">MONITOR PROCESS PROCESS1
   
   
USER CID      PROCESSGRP STARTED    SENDS RECVS FLGS STATE
USER   CID      PROCESSGRP STARTED    SENDS RECVS FLGS STATE
<b></b>----- -------- ---------- ----------- ----- ----- ---- ------
<b></b>----- -------- ---------- ----------- ----- ----- ---- ------
     3 PROGRAM1 DENVER    88349135723    5    4 BI  RECV
     3 PROGRAM1 DENVER    88349135723    5    4 BI  RECV
     4 PROGRAM1 DENVER    88349135803    5    4 BI  RECV
     4 PROGRAM1 DENVER    88349135803    5    4 BI  RECV
</p>
</p>
<ul>
<ul>
Line 1,130: Line 1,184:
<table class="thJustBold">
<table class="thJustBold">
<tr>
<tr>
<th>
<th><p>B</p> </th>
<p>
<td><p>Bound</p> </td>
B</p>
</th>
<td>
<p>
Bound</p>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<th>
<th><p>F</p> </th>
<p>
<td><p>First speaker</p> </td>
F</p>
</th>
<td>
<p>
First speaker</p>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<th>
<th><p>I</p> </th>
<p>
<td><p>Inbound</p> </td>
I</p>
</th>
<td>
<p>
Inbound</p>
</td>
</tr>
</tr>
   
   
<tr>
<tr>
<th>
<th><p>O</p> </th>
<p>
<td><p>Outbound </p> </td>
O</p>
</th>
<td>
<p>
Outbound </p>
</td>
</tr>
</tr>
</table></li>
</table></li>
Line 1,218: Line 1,248:


[[Category:System management]]
[[Category:System management]]
[[Category:Model 204 operational issues]]

Latest revision as of 04:30, 10 November 2021

You can monitor the status and performance of an ONLINE system, including SNA Communications Server interfaces, with the MONITOR command. See MONITOR command for complete command syntax.

MONITOR provides a series of formatted or unformatted displays of system and user statistics about all or a selected set of active users. You can update the displays on a periodic basis, but do not update them more frequently than every five seconds.

Unformatted displays

Unformatted displays show all the nonzero cumulative system or user statistics in a format similar to that provided in the journal:

  • Series of terms appears in name=value format.
  • Journal header is not displayed.
  • Each user is identified by user number.
  • Account name appears at the beginning of the user's display.

Formatted displays

Formatted displays show basic system information, followed by specified user information in labelled columns.

Basic system information includes the number of:

  • Active users (USR)
  • Active servers (SVR)
  • Open buffers (BUF)
  • Open files (FLS)
  • A file open as part of one or more permanent groups is followed by an asterisk (*).
  • Two pound signs (##) indicate that the user has more files open than can fit into the internal buffer used to hold open file names.
  • System percentage of CPU time (PCPU).
  • Statistics from the last system performance line written to the journal. If performance monitoring is active and performance lines are being written to the journal, all statistics are shown. Otherwise, only open buffers, open files, and system PCPU are shown.

Specified user information is described in the next section.

User information in formatted displays

User information is viewable in the following types of formatted displays:

  • Basic display (default)
  • User since-last statistics
  • User performance data
  • Open files

The following sections describe these types of formatted displays.

Basic display

USER SVR USERID P CUR SLICE AGE FUNC CNCT CPU SEQIO QUE WT FLGS 0 SAM S 48 0.075 0 0.041 3 BLKO 04 40 1 1 MARY S 49 0.075 EVAL 266 0.152 36 REDY

Where:

  • USER is the user number.
  • SVR is the server number.
  • USERID is the user ID.
  • P is user priority (P).
  • CUR is current priority.
  • SLICE is current CPU time slice.
  • AGE is user pre-aged priority.
  • FUNC is the last function to set the since-last parameter.
  • CNCT is connect time.
  • CPU is CPU time.
  • SEQIO is the sequential I/O operations performed.
  • QUE is the current scheduler queue.
  • WT is the user wait state.
  • FLGS is the sum of the status flag values.

QUE values

QUE value

Means user is...

RUNG

Running.

BLKI

Blocked in server, visible to the scheduler.

OFFI

Blocked in server, invisible to the scheduler.

BLKO

Blocked out of server, visible to the scheduler.

OFFO

Blocked out of server, invisible to the scheduler.

WTSV

Waiting for a server.

REDY

Ready or running.

SWPG

Being swapped in or out.

WTUS

Server waiting for user.

MOVE

Moving between queues.

Tip: As of version 7.7, by summing RUNG, BLKI, BLKO, WTSV, REDY, and SWPG, you can approximate USRS (average active users).

Note: Prior to version 7.7, OFFQ was used instead of OFFI and OFFO.

Wait type values

Wait

Description

00

Unspecified.

01

Disk I/O.

02

Sequential user I/O — output.

03

Sequential user I/O — input.

04

Operator's console input (WTOR).

05

Restore reads (BSAM).

06

Dump writes (BSAM).

07

Enqueue waits (record or noncritical resource).

08

Buffer waits.

09

Wait almost forever (deactivated user).

10

Waits for a pseudo subtask, or waits for reactivation (hung terminal).

11

Waits for an IFAM2 or IFAM4 call.

12

Waits for a wakeup.

13

Server I/O.

15

Writes to the journal data set, CCAJRNL.

16

Checkpoint writes to CHKPOINT data set.

17

Waits for check on previous write.

18

Waits for a checkpoint DECB to free up or waiting for multiuser output arbitration.

19

Waits for a checkpoint request.

20

Waits for a checkpoint completion.

21

Wait forever (dead user).

22

VSAM or sequential file input.

23

User waiting due to excessive login failures.

24

Waits for exclusive control of critical file resource.

25

Waits for share control of critical file resource.

26

Waits for SNA Communications Server buffer, input or output.

27

Waits for interprocess input.

28

Waits for interprocess output.

29

User waiting for the security interface.

30

User(s) waiting, with $Wait(nn,'SWAP'), for a user-defined ECB to be posted by a $Post function from a different user.

31

User(s) waiting, with $Wait(nn,'NOSWAP'), for a user-defined EDB to be posted by a $Post function from a different user.

32

User waiting for DB2 subtask.

33-36

Reserved for future development.

37

User waiting for recovery to complete.

38

Reserved for future development.

39

Reserved for future development.

40

Waiting for an MQSeries subtask to become available.

41

Waiting for a MQ subtask to run.

42

MQSeries MQGET operations with wait time specified.

43

ECF to load or delete a module.

44

External module to become free.

45

ECF subtask to become free.

46

External module to run.

47

User(s) waiting, with $Wait('CPQZ'), for the extended quiesce ECB to be posted by the successful completion of a Model 204, system-wide checkpoint.

48

User(s) waiting, with $Wait('QZSIG'), for the end of extended quiesce.

49

User(s) waiting, at end of extended quiesce, for count of $Wait('CPQZ') and $Wait('QZSIG') users to go to zero.

50

User is waiting for HSM to recall an archived data set.

51

User is waiting for a share lock on the internal constraints database.

The constraints database is used to ensure that there is sufficient space on table B pages and in table D to be able to back out active transactions as needed.

52

User is waiting for an exclusive lock on the internal constraints database.

The constraints database is used to ensure that there is sufficient space on table B pages and in table D to be able to back out active transactions as needed.

53

User is waiting for a subtransaction checkpoint to complete.

54

Checkpoint PST waiting on a blocking file update to complete to try to do a transaction checkpoint.

55

Checkpoint PST doing a timed wait to try to do a transaction checkpoint.

56

Checkpoint PST waiting on users to complete subtransactions.

57

Means a daemon thread waiting for its master thread.

This change is enabled in V7.8 or V7.7 with the application of zap 77z410.

58

Means a master thread waiting for one of its daemon threads.

This change is enabled in V7.8 or V7.7 with the application of zap 77z410.

80-89

Customer (site-specific) wait types.

97

Waiting for a Fast/Unload request running in a real subtask.

98

In a MAXAUSER wait.

99

Waiting for a SIRFACT QUIESCE to be completed (with a SIRFACT RESUME).

Status flag values

Flag

Description of wait...

40

User's wait is swappable. If another user needs this user's server area, the waiter may be written out.

20

User is waiting for an internal ECB (that is, the ECB is posted only by Model 204, not by the operating system). This can happen, for example, if the waiting user is waiting to access a record to which someone else is preventing access.

10

ECB to be posted is of the short form (1 byte in length) and is an internal ECB (posted by M204).

8

More than one user is allowed to wait for the ECB that this user is waiting for.

4

User can be bumped.

2

User can be interrupted with an urgent message.

1

A time limit was specified for the user's wait. For example, if a waiting user is in a record locking conflict situation, it is a timed wait until the request ends and a record locking conflict message is issued, or an ON unit in the code takes control.

V7.7 layout change

From V7.7 onwards (with zaps 77Z478 or 78Z023, 78Z026) the AGE column in the basic display output has been replaced with a column, headed LOG, which shows the logon type of each user, as in the following example:

20.149 MAY 28 13.02.36 PAGE 8 USER SVR FLS PCPU SMPLS RUNG REDY BLKI WTSV BLKO SWPG 6 0.290 USER SVR USERID P CUR SLICE LOG FUNC CNCT CPU SEQIO QUE WT FLGS 0 SUPERKLUGE H 252 0.030 CCA DISP 0 0.001 596 OFFO 4 60 7 4 JIMV S 62 0.030 SUB EVAL 10 0.001 9 OFFI 3 66 8 2 ZORRO S 4 0.030 PDG EVAL 93 0.003 36 OFFI 3 66 9 5 TSJRD H 104 0.030 ESM 123 0.001 74 RUNG 10 1 CCAD01 H 110 0.030 CCA 13 0.001 52 OFFI 3 66 31 VT75DIED 0.000 0 0.000 0 2 20 32 VT75READ 0.000 253954 0.013 0 3 00 33 VT75ERRS 0.000 0 0.000 0 2 20 34 CHKPPST 0.000 0 0.001 0 12 20 35 CHKPAWW 0.000 5509 0.000 0 12 20 36 MQDELDTP 0.000 0 0.000 0 12 00 >

Possible values that are shown in the LOG column (logon type) are as follows

Value

Meaning

CCA

CCASTAT userid

ESM

userid validated by an External Security Manager - ACF2, RACF, or TopSecret

SUB

Subsystem controlled logon

GST

Guest - neither logged on via CCASTAT nor by an ESM

PDG

Logon pending due to errors (e.g. invalid password)

User since-last statistics

User since-last statistics (SL option) show current activity.

If the user is between activities or performing an activity that does not initialize since-last statistics, the display is cumulative.

Statistics displayed are CPU, DKRD, DKWR, UDD, OUT, SLIC, FINDS, RECDS, PCPU, RQTM, SUBSYSTEM, PROC-FILE, PROC, and the pseudo subtask's user ID, account name, and user number. (Refer to the Statistics with descriptions table for statistic definitions, and to Pseudo subtasks.)

User performance data

The PERFORMANCE option shows data last written to the journal. The following information is included:

  • Number of samples used to compute percentages
  • percentage of time the user is in each of the scheduler queues

See Priority scheduling.

Open files

This display is a list of files a user has open.

MONITOR examples

These examples show several variations of the MONITOR command.

The following command specifies a single nonrepeating formatted display of basic information for the system and all active users:

MONITOR

The following command, MONITOR ACTIVE, specifies a single nonrepeating formatted display of basic information for the system and active users, excepting OFFO and OFFI users. (OFFO and OFFI are state-of-queue statuses meaning that the Scheduler does not have to evaluate those users not in the queue. Prior to version 7.7, OFFQ was used instead of OFFO and OFFI.)

The MONITOR ACTIVE command is used to reduce the amount of terminal output.

MONITOR ACTIVE

The following commands specify a display of the cumulative system statistics, which is updated every minute:

MONITOR STATISTICS 60 MONITOR STAT EVERY 60 MONITOR SYSTEM STATISTICS 60

The following command specifies a single display of the cumulative user statistics for users 1, 3, and 5, if they are active:

MONITOR (1,3,5) STATISTICS

The following commands specify a single formatted display of basic system information and basic, since-last, performance, and file information for each active user. Pseudo subtask's user ID, account name, and user number are displayed for SL (since-last) statistics:

MONITOR ALL MONITOR USERS ALL MONITOR BASIC SL PERFORMANCE FILE MONITOR SL FILE PERF

The following commands specify a display of basic formatted information for the system and users 1, 2, 5, and 7, if they are active. The display is repeated continually 75 seconds after it completes. The user must press Enter to display the refreshed version, or enter *CANCEL to terminate the display:

MONITOR (1,2,5,7) 75 MONITOR (1,2,5,7) BASIC EVERY 75

The following command specifies an unformatted display of the following information:

  • Number of active users
  • Number of compactions of the record locking table
  • Current number of bytes used in the record locking table
  • Current high-water mark for the number of bytes used in the record locking table
  • Current number of headers used in the record locking table
  • Current high-water mark for the number of headers used in the record locking table
  • Required LRETBL setting (high-water mark) for the current system load

MONITOR ENQ

The following command specifies a formatted display of the number of pages from tables of each file that are currently located in the disk buffers:

MONITOR DISKBUFF

The following command specifies information about SNA Communications Server's use of output buffers and waits for threads:

MONITOR VTAM

MONITOR LINK example

The following command specifies information about a network entity:

MONITOR LINK HEADQTRS

For more information about the MONITOR command for network monitoring, see Model 204 Horizon: Intersystem Processing.

In this example, HEADQTRS is the specified network entity for which the Online system operation is being monitored. The following statistics are provided:

LOCAL ID MAXSES BNDSES IBWTS OBWTS CONVS FLGS TRAN/PROTO -------- ------ ------ ----- ----- ----- ---- ---------- BOSTACB 4 2 0 0 2 A VTAM/LU62 USER PROCESS SENDS RECVS FLGS PROCESSGRP ----- -------- ----- ----- ---- ---------- 3 PROCESS1 5 4 BI DENVER OBSOLETE 4 PROCESS1 5 4 BI DENVER

Where:

  • LOCAL ID is the SNA Communications Server ACB name (BOSTACB).
  • MAXSES is the maximum number of sessions allowed on this link (4).

    The limit is established by the SESSIONS parameter of the DEFINE LINK command.

  • BNDSES indicates the number of currently bound sessions (2).
  • IBWTS indicates the number of input buffer waits (0) by inbound conversations.

    The input buffer availability is controlled by the actual number of input buffers established by the INBUFNO parameter of the DEFINE LINK command. An input buffer is used on the inbound side when a conversation is being established. If IBWTS is high, and you observe delays while opening inbound processes, then increase INBUFNO.

  • OBWTS indicates the number of output buffer waits (0).

    Note: OBWTS is always zero when the communication protocol is LU 6.2 (output buffers are not used).

  • CONVS indicates the number of active conversations (2).
  • FLGS indicates the status of the link status (A). Possible values for FLGS are:
    A Active
    S Stopped
    C Closed
  • TRAN indicates the transport mechanism: SNA Communications Server or terminal (TERM). In this case TRAN is SNA Communications Server.
  • PROTO indicates the communication protocol (LU 6.2). Possible values for PROTO are:
    MSTR Master (for TPROCESS)
    XFER Transfer (for TPROCESS)
    IMS61 IMS LU 6.1
    LU 6.2 LU 6.2

    The second line of statistics is a detail line for each bound session.

    • USER provides the external user number (3, 4). A blank occurs if a conversation is not active.
    • PROCESS indicates the process name (PROCESS1). If a conversation is not active, a blank appears.
    • SENDS indicates the number of physical sends for each conversation (5, 5).
    • RECVS indicates the number of physical receives for each conversation (4, 4).
    • FLGS indicates the status of the session (BI, BI). The session status flags are:

      B

      bound

      F

      first speaker

      I

      inbound

      O

      outbound

      L

      local bid in progress

      R

      remote bid accepted

  • PROCESSGRP provides the process group name (DENVER). In this example, user 3 is running with an OBSOLETE process group: the process group was stopped and a DEFINE PROCESSGROUP command was issued to change the process group definition for subsequent usage. User 4 is running with the most recent version of the process group definition.

MONITOR PROCESSGROUP example

The following command specifies reports concerning a specific process group:

MONITOR PROCESSGROUP

In this example, two PROCESSGROUP reports are produced. The first report is for an active conversation. The second report reflects the stopping and redefinition of the active conversation, which is allocated to another conversation (OBSOLETE with the same process name). Until the conversation with the obsolete process group ends, separate reports are produced for each process group to reflect the more current set of attributes.

MONITOR PROCESSGROUP DENVER LINKNAME REMOTEID BNDSES INCONVS OTCONVS FLGS -------- -------- ------ ------- ------- ---- HEADQTRS DENVACB 2 1 0 A USER PROCESS SENDS RECVS FLGS ----- -------- ----- ----- ---- 4 PROCESS1 5 4 BI MONITOR PROCESSGROUP DENVER LINKNAME REMOTEID BNDSES INCONVS OTCONVS FLGS -------- -------- ------ ------- ------- ---- HEADQTRS DENVACB 2 1 0 AX USER PROCESS SENDS RECVS FLGS ----- -------- ----- ----- ---- 3 PROCESS1 5 4 BI

Where:

  • LINKNAME names the associated link (HEADQTRS).
  • REMOTEID provides the Remote LU name (DENVACB).
  • BNDSES indicates the number of bound sessions (2).
  • INCONVS indicates the number of active inbound conversations (1).
  • OTCONVS indicates the number of active outbound conversations (0).
  • FLGS indicates the status of the processgroup (A). The processgroup status flags are:

    A

    Active

    S

    Stopped

    X

    Obsolete

The second line of statistics is a detail line for each active conversation.

  • USER indicates the external user number (4).
  • PROCESS provides the name of the program as it is known to network users (PROCESS1).
  • SENDS indicates the number of physical sends (5).
  • RECVS indicates the number of physical receives (4).
  • FLGS indicates the status of the session status (BI). Status flags are:

    B

    Bound

    F

    First speaker

    I

    Inbound

    O

    Outbound

MONITOR PROCESS example

The following command specifies information about a particular process:

MONITOR PROCESS PROCESS1

In this example, two inbound conversations invoked from PROCESSGROUP DENVER (users 3 and 4) are in progress with the process named PROCESS1. The conversation ID (CID) that was assigned in the SOUL OPEN PROCESS statement is PROGRAM1.

MONITOR PROCESS PROCESS1 USER CID PROCESSGRP STARTED SENDS RECVS FLGS STATE ----- -------- ---------- ----------- ----- ----- ---- ------ 3 PROGRAM1 DENVER 88349135723 5 4 BI RECV 4 PROGRAM1 DENVER 88349135803 5 4 BI RECV

  • USER indicates the external user number (3, 4).
  • CID provides the conversation ID (PROGRAM1).
  • PROCESSGRP indicates the name of the processgroup (DENVER).
  • STARTED provides the Julian date and time the conversation began (88349 and 13:57:23).
  • SENDS indicates the number of physical sends (5, 5).
  • RECVS indicates the number of physical receives (4, 4).
  • FLGS indicates the status of the session (BI). Status flags are:

    B

    Bound

    F

    First speaker

    I

    Inbound

    O

    Outbound

  • STATE indicates the state of the conversation (RECV). Conversation states can be:
    ACCEPT
    CLOSE
    CONFCLS
    CONFIRM
    CONFSND
    INITIAL
    RECV
    SEND

MONITOR DISKBUFF example

You can use the MONITOR DISKBUFF commands to analyze the buffer pool utilizations:

  • MONITOR DISKBUFF output shows buffer usage combining above and below the bar buffers.
  • MONITOR DISKBUFFG output shows buffer pool usage for only above the bar buffers.
  • MONITOR DISKBUFFL output shows buffer pool usage for only below the bar buffer usage.

Use these commands throughout the day across varied types of daily and event processing to evaluate your buffer allocations.

Using MONITOR DISKBUFF commands

You can see the types of pages that are in your buffer pools at any point in time using the MONITOR DISKBUFF command. The output of this command displays the types of pages that are in buffers and how many of each type.

MONITOR DISKBUFF FILENAME FCT TBLA TBLB TBLC TBLD TBLE TBLX *TOTAL* -------- --- ------ ------ ------ ------ ------ ------ ------- CCATEMP 0 40 0 0 0 0 0 40 PROC1 1 0 0 0 11 0 0 12 FILETBLX 1 1 10 0 2 0 2 16 TESTZ 1 1 11 0 3 185 0 201 *TOTAL* 3 42 21 0 16 185 2 269