CA OPS/MVS Event Management and Automation WebCenter UDP port usage
search cancel

CA OPS/MVS Event Management and Automation WebCenter UDP port usage

book

Article ID: 16086

calendar_today

Updated On:

Products

OPS/MVS Event Management & Automation

Issue/Introduction

We are trying to setup the CA OPS/MVS WebCenter product and when requesting a reserved port for the Web interface, we notice the product is using two ports:

Command      NETSTAT CONN          FORMAT LONG
-------------    --------------------       ------------------------
MVS TCP/IP   NETSTAT CS V2R2       TCPIP Name: TCPIP4

User Id          Conn             State
----------       -----------      -----
OPSWEB        0001740E      Listen
..  
Local Socket:   0.0.0.0..18080
Foreign Socket: 0.0.0.0..0
..
OPSWEB        0001740D       UDP
Local Socket:   0.0.0.0..33195
Foreign Socket: *..*



The 18080 port is the CA OPS/MVS "WebCenter Interface Port" defined in the startup parameters, but the 33195 UDP port is not defined anywhere. We can see no reference to a UDP port in the manual.

  • Please explain what WebCenter is using this port for and how it is selected.
  • Can you explain why the OPSWEB started task is listening on the UDP port?
  • Is there any way to customize the port number or even stop it from listening?

 

Environment

CA OPS/MVSCA NetMaster

Resolution

WebCenter is a CA NetMaster product too and it monitors network performance and diagnostics using the UDP port. CA OPS/MVS does not use the UDP port for OPSWEB.

The CA OPS/MVS WebCenter portion of the product is based upon the CA NetMaster WebCenter feature. NetMaster must open a sockets interface in order to create the OPSWEB server. As you have seen, there is the OPSWEB port that is in LISTEN state, and then you'll see that UDP ephemeral port. This port is required for the sockets Domain Name Resolution (DNR) support.

The UDP ephemeral port is required for the sockets DNR support. Sorry, but there's no way to disable that. And as seen, it is an ephemeral port that can and will change. We have no control over that.

Sorry, but in order for DNR protocol to work under the sockets interface, we must open that UDP port, of which the IBM sockets API we are using, doesn't allow for a hard specification.