MONITOR PROCESSGROUP command

The output of MONITOR PROCESSGROUP is a display with two lines of headings and multiple lines of values. The upper line of headings is a summary line. Its headings, which depend on the intersystem facility monitored, are a subset of the headings in the table below.

MONITOR PROCESSGROUP summary line

Display heading	Meaning
LINKNAME	Name of associated link
REMOTE I.D.	One of the following: Remote LU name (blank, for CRAM SQL and IUCV SQL) Remote node address specified on DEFINE PROCESSGROUP
BNDSES	Number of bound sessions
CONNEC	Number of established connections
INCONVS	Number of active inbound conversations
OTCONVS	Number of active outbound conversations
FLGS	Processgroup status flags; possible values are: A (active) S (stopped) X (obsolete) * (remote address is masked)

The lower line of MONITOR PROCESSGROUP headings are for details of each active conversation. Detail line headings, which depend on the intersystem facility monitored, are a subset of the headings in the table below.

MONITOR PROCESSGROUP detail line

Display heading	Meaning
USER	External user number
PROCESS	Process name
SENDS	Number of physical sends
RECVS	Number of physical receives
FLGS	Session (or connection) status flags; possible values are: B (bound) F (first speaker) I (inbound) O (outbound)
REMOTE ADDRESS	Internet address of client user
PORT#	Port number of client user

Obsolete processgroups

When a processgroup with an active conversation is stopped and redefined, and the new version of the processgroup is allocated to another conversation before the first one ends, there can temporarily be more than one processgroup having the same name. The following scenario results in this condition:

1. A processgroup has an active conversation.

2. The processgroup is stopped (STOP PROCESSGROUP command), and the conversation has not ended.

3. The processgroup definition is changed (DEFINE PROCESSGROUP command).

4. The processgroup is started (START PROCESSGROUP command).

Now the processgroup with the active conversation is obsolete, since it no longer reflects the current definition. Any new conversations that are started with that processgroup result in the creation of another processgroup having the same name but the more current set of attributes.

Until the conversation with the obsolete processgroup ends, the MONITOR PROCESSGROUP command produces separate reports for each processgroup. Obsolete processgroups can be identified by an X flag in their summary line.

Example of Horizon for VTAM processgroup

The following is an example of MONITOR PROCESSGROUP output for a Horizon for VTAM processgroup:

MONITOR PROCESSGROUP DENVER LINKNAME REMOTE I.D. BNDSES INCONVS OTCONVS FLGS -------- ----------- ------ ------- ------- ---- HEADQTRS DENVM204 2 1 0 A USER PROCESS SENDS RECVS FLGS ----- -------- ----- ----- ---- 4 PROCESS1 7 3 BI MONITOR PROCESSGROUP DENVER LINKNAME REMOTE I.D. BNDSES INCONVS OTCONVS FLGS -------- ----------- ------ ------- ------- ---- HEADQTRS DENVM204 2 1 0 AX USER PROCESS SENDS RECVS FLGS ----- -------- ----- ----- ---- 3 PROCESS1 5 4 BI

In the previous example:

• Two PROCESSGROUP reports were produced; the second report is for an obsolete processgroup with which a conversation is still active (FLAGS=AX).

• Both processgroups currently have two bound sessions (BNDSES); one of these currently has an active, inbound conversation (INCONVS=1). No outbound conversations are active (OTCONVS=0).

• The conversation in the first report is inbound (FLGS=BI) and it is being held with a program running as User 4.

• The process name is PROCESS1. In the course of the conversation, the process has issued a number of physical SNA Communications Server sends and receives (SENDS, RECVS) with its remote partner DENVM204 (REMOTE I.D.).

Example of Horizon for TCP/IP processgroup

The following is an example of MONITOR PROCESSGROUP output for a Horizon for TCP/IP processgroup, using IPv6 network addresses. (IPv6 addresses are supported on IBM z/OS systems only.)

MONITOR PROCESSGROUP ANY10 REMOTE I.D. --------------------------------------------- 10.0.0.0 LINKNAME INCNLI OTCNLI CONNEC INCONVS OTCONVS FLGS -------- ------ ------ ------ ------- ------- ---- TCPSQL 4 2 1 1 0 A* USER PROCESS SENDS RECVS FLGS REMOTE ADDRESS PORT# ----- -------- ----- ----- ---- -------------- ----- 41 CCARCL 6 7 BI 16163 REMOTE ID: ::FFFF:10.204.204.116 MONITOR PROCESSGROUP ANY10 REMOTE I.D. --------------------------------------------- 10.0.0.0 LINKNAME INCNLI OTCNLI CONNEC INCONVS OTCONVS FLGS -------- ------ ------ ------ ------- ------- ---- TCPSQL 4 2 1 1 0 A* USER PROCESS SENDS RECVS FLGS REMOTE ADDRESS PORT# ----- -------- ----- ----- ---- -------------- ----- 9 CCARSQL 5 5 BI 10.204.204.116 16136 > (with LOCALID=ANY on DEFINE LINK)

In the previous example:

• The Remote ID is placed on a separate line because, if it is an IPv6 address, its length can be up to 45 characters. Its place on the detail line has been taken by INCNLI and OTCNLI.

  • INCNLI is the current inbound conversation limit, as set on the INLIMIT parameter of DEFINE PROCESSGROUP.

  • OTCNLI is the current outbound conversation limit, set on the OUTLIMIT parameter of DEFINE PROCESSGROUP.

  Both values may have been altered from the original INLIMIT/OUTLIMIT values by MODIFY PROCESSGROUP commands.

• Processgroup ANY10 currently has one bound connection (CONNEC).

• The connection currently has an active, inbound conversation (INCONVS=1).

• A mask is used on the REMOTEID value of DEFINE PROCESSGROUP (see asterisk in upper line FLGS field). The mask value is 255.255.255.0.

• CCARSQL is the required Model 204 SQL process. In the course of the conversation, CCARSQL has issued a number of physical sends and receives (SENDS, RECVS) for user 9.

Example of TPROCESS processgroup

The following is an example of MONITOR PROCESSGROUP output for a CICS TPROCESS processgroup:

MONITOR PROCESSGROUP PGP4CICS LINKNAME REMOTE I.D. BNDSES INCONVS OTCONVS FLGS -------- ----------- ------ ------- ------- ---- LK4CICS 1 0 1 A USER PROCESS SENDS RECVS FLGS ----- -------- ----- ----- ---- 5 PS4CICS 0 0 BFO

In the previous example:

• The processgroup PGP4CICS has an established connection (BNDSES=1) over which there is an active conversation (FLAGS=A). The conversation was initiated by the User Language request and is considered outbound (OTCONVS=1, FLGS=BFO).

• The user thread number of the conversation is 5 (USER=5).

• The process name is PS4CICS. Conversation physical sends and receives (SENDS, RECVS) are not counted.