- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: TCPIP$METRIC usage
Operating System - OpenVMS
1748028
Members
5052
Online
108757
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2005 03:38 AM
тАО01-11-2005 03:38 AM
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
Thanks
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2005 11:50 AM
тАО01-11-2005 11:50 AM
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2005 07:18 PM
тАО01-11-2005 07:18 PM
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 :)
$ 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 :)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP