1748028 Members
5052 Online
108757 Solutions
New Discussion юеВ

Re: TCPIP$METRIC usage

 
Sergey Akimov
Occasional Contributor

TCPIP$METRIC usage

Has anybody experience with TCPIP$METRIC API usage? I need to obtain workload statistics in my application (C-writed) for my internal purposes. ╨Рny samples of TCPIP$METRIC API calling very needed.
Thanks
2 REPLIES 2
John Gillings
Honored Contributor

Re: TCPIP$METRIC usage

Sergey,
I'm not sure if TCPIP$METRIC does what you think it does... but here's an article that might help (not sure how it will wrap...):

[TCP/IP] TCPIP$METRICVIEW & METRIC Debugging / Troubleshooting Info.


COPYRIGHT (c) 1988, 1993 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.

(c) 2003 Hewlett-Packard Development Company, L.P.

PRODUCT: TCP/IP Services for OpenVMS, Versions 5.1 and Above

COMPONENT: TCPIP$METRICVIEW and METRIC

OP/SYS: OpenVMS VAX, Versions 7.1, 7.2 and 7.3
OpenVMS Alpha, Versions 7.1, 7.2 and 7.3

SOURCE: Hewlett-Packard Company


OVERVIEW:

This article contains example debugging information for the
TCPIP$METRICVIEW executable image, and the METRIC service. Example steps
for observing and initiating the network message exchange, along with basic
trace analysis are included.


INFORMATION:

The METRIC service is used in conjunction with the LBROKER service to
obtain the service rating for nodes that are participating in the OpenVMS
cluster alias. The image TCPIP$METRICVIEW.EXE can be used to obtain the
rating value of these nodes via the METRIC service.

The example commands listed below start a TCPTRACE debugging session on
NODE_A, and logs responses from the nodes that are connected to a single
subnet, and to multiple subnets.


EXAMPLE NUMBER 1:

The message exchange is initiated and trace information obtained. There is
only one Ethernet controller defined with the address 172.16.1.1 on the
OpenVMS host. The IP multicast message is sent to the 172.16.1.255 address.

IP Addressing scheme:
node_a.some.company.com 172.16.1.1
node_b.some.company.com 172.16.1.2
node_c.some.company.com 172.16.1.3
node_d.some.company.com 172.16.1.4

NODE_A $ TCPIP SHOW SERVICE METRIC ! Verify that the
! metric service is
! enabled
Service Port Proto Process Address State

METRIC 570 UDP TCPIP$METRIC 0.0.0.0 Enabled

NODE_A $ CREATE TEST.COM ! Create command
$ PIPE TCPTRACE/FULL/PORT=REMOTE=570/PACKET=15 - ! procedure to start
| SEARCH/NUMBER SYS$PIPE ADDRESS ! tcptrace utility
^Z

NODE_A $ SPAWN/NOWAIT/NOTIFY @TEST.COM ! Spawn subprocess
%DCL-S-SPAWNED, process TEAM_70 spawned

NODE_A $ MCR TCPIP$METRICVIEW.EXE ! Invoke image
13 IP Source Address = 172.16.1.1
14 IP Destination Address = 172.16.1.255

32 IP Source Address = 172.16.1.2
33 IP Destination Address = 172.16.1.1

51 IP Source Address = 172.16.1.3
52 IP Destination Address = 172.16.1.1

70 IP Source Address = 172.16.1.4
71 IP Destination Address = 172.16.1.1

89 IP Source Address = 172.16.1.1
90 IP Destination Address = 172.16.1.1

Subprocess TEAM_70 has completed
Host Rating
---- ------
172.16.1.2 node_b.some.company.com 51
172.16.1.3 node_c.some.company.com 18
172.16.1.4 node_d.some.company.com 12
172.16.1.1 node_a.some.company.com 23

Trace Analysis:

Line 13: Source IP address of node_a running the TCPIP$METRICVIEW image
Line 14: Destination IP Multicast address sent to the 172.16.1.0 subnet

Line 32: Source IP address of node_b running the METRIC service
Line 33: Destination IP address of node_a running the TCPIP$METRICVIEW image

Line 51: Source IP address of node_c running the METRIC service
Line 52: Destination IP address of node_a running the TCPIP$METRICVIEW image

Line 70: Source IP address of node_d running the METRIC service
Line 71: Destination IP address of node_a running the TCPIP$METRICVIEW image

Line 89: Source IP address of node_a running the METRIC service
Line 90: Destination IP address of node_a running the TCPIP$METRICVIEW image


EXAMPLE NUMBER 2:

The message exchange is initiated and trace information obtained. There
two Ethernet controller defined with the addresses 172.16.1.1 and 10.1.1.1
on the OpenVMS host. The IP multicast message is sent out the first
controller to the 172.16.1.255 address. The only node output displayed is
the local node.

IP Addressing scheme:
node_e.some.company.com 10.1.1.1
node_f.some.company.com 10.1.1.2

NODE_E $ SPAWN/NOWAIT/NOTIFY @TEST.COM ! Spawn subprocess
%DCL-S-SPAWNED, process TEAM_70 spawned

NODE_E $ MCR TCPIP$METRICVIEW.EXE ! Invoke image
13 IP Source Address = 172.16.1.1
14 IP Destination Address = 172.16.1.255

32 IP Source Address = 10.1.1.1
33 IP Destination Address = 10.1.1.1

51 IP Source Address = 10.1.1.2
52 IP Destination Address = 10.1.1.1

---- ------
10.1.1.1 node_e.some.company.com 134

Line 13: Source IP address of node_e running the TCPIP$METRICVIEW image
Line 14: Destination IP Multicast address sent to the 172.16.1.0 subnet
TCPIP$METRICVIEW sends the multicast to the first controller

Line 32: Source IP address of node_e running the METRIC service
Line 33: Destination IP address of node_e running the TCPIP$METRICVIEW image

Line 51: Source IP address of node_f running the METRIC service
Line 52: Destination IP address of node_f running the TCPIP$METRICVIEW
image A detailed trace indicates that a different port number
was used


WORKAROUND:

Use the "/HOST" switch and specify each node individually:

NODE_D $ MCR TCPIP$METRICVIEW.EXE/HOST=10.1.1.2

---- ------
10.1.1.2 node_f.some.company.com 132

NODE_D $ MCR TCPIP$METRICVIEW.EXE/HOST=10.1.1.1

---- ------
10.1.1.1 node_e.some.company.com 134

A crucible of informative mistakes
Sergey Akimov
Occasional Contributor

Re: TCPIP$METRIC usage

funnily, but at my hosts (two-host cluster, HP TCP/IP Services for OpenVMS Alpha Version V5.4 on OpenVMS V7.3-2) call to
$ MCR TCPIP$METRICVIEW.EXE/HOST=aaa.aaa.aaa.1
or
$ MCR TCPIP$METRICVIEW.EXE/HOST=aaa.aaa.aaa.2
or
$ MCR TCPIP$METRICVIEW.EXE
are equal and always display:
Host Rating
---- ------
aaa.aaa.aaa.1 node1 n1 aaa.aaa.aaa.2 node2 n2

BTW, usage of METRICVIEW is one of ways considered me before, but: external process executing, output redirect, string analyze... :(
Are ports/datagrams sended in listed example is known/documented?

PS. sorry my english :)