Operating System - OpenVMS
1748176 Members
4199 Online
108758 Solutions
New Discussion юеВ

Re: Analyzing OPCOM messages from Operator log.

 
SOLVED
Go to solution
Anjan Ganguly
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

John,

I am attaching the OSI Transport Port Details and Round Trip Delay Estimate details as attached.

Anjan
Anjan Ganguly
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

Round Trip Delay Estimation
JohnDite
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

Anjan,

you still don't seemed to have resolved your connectivity problems, assuming you're still get the events that you quoted.

With regard to your "Round Trip Delay Estimate", all the data you provided seems reasonable, although you do not mention which of these connections go via WAN (if any?).

John
Anjan Ganguly
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

John,
Sorry for late reply.I somehow skipped your reply.
You are telling about how many ports are directly connected to WAN out of 9.But How can I identify, which port is for whhich link or Remote NSAP.I mean to say that is there any way to find out nhich NSAP is meat for which port if I am right.

But to give a brief over view, I have one Decnet over OSI server which is connected with 6 other remote NSAP nodes and they all are having WAN connections.Each WAN link consists of 6 X 64 KBps links.

Can you clarify one doubt of mine?

You said that ""Transport Selector" equivalent to a well known port # in TCP speak) addressed in the CR-TPDU is not available on the system, ie. the application/process or the NCL definition is not present on the system."

What actually can this impact for having a
stable communication.
How to check which are the CR TPDU address (equvaled to port address) is not defined on the system?

Anjan
JohnDite
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

Anjan,

if you are still getting your OSI Transport Events with Reason=Address Unknown and nobody has complained after all this time then maybe this connections aren't that important(?).

I have already mentioned that in this version of OpenVMS you can use the CTF Trace or tcpdump (in the case of RFC1006 connections) to analyse the OSI Transport Connect Request TPDU to determine the TSEL (Transport Selector) that is being addressed. You should know or should have been told which applications register which TSEL.

The output of the "NCL SHOW OSI TRANSPORT PORT * ALL" command gives you a wealth of information (equivalent to a 'netstat -an' in Unix speak). If you take time to study the different attributes shown you will be able to determine the partner System of the connection (Remote NSAP or Remote IP Address etc.), the exact Transport connection(Local Reference, remote Reference), the Network Service used (CLNS, RFC1006 etc.), the direction, the local Process PID, creation date and so on.

With all this wealth of information you should be able to draw yourself a diagram of all the systems involved, the type of Network connections that exist between these systems and the applications involved. With the events and traces you can add the connections that aren't being established and ask someone who should know what this implies for your business.

John


Anjan Ganguly
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

I have identified the application (from PID) that is responsible for using the port.
I have also the following attached statistics.
Today at around 10:55 AM we have a breakedown in communication links and it appears in the port details.
But in anyway, can we relate this
---Creation Time--- with the breakage in physical link? or there may be other reason too for this.
Also I am able to see the Local and Remote transport selector address.But I am quite unsure about how can I relate this with Physical communication line breakage!!!!!!!!!!!!!!!!!!!!!!!

JohnDite
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

Anjan,

the output of the OSI TRANSPORT PORT * will only ever show you the 'existing' connections. From the 'Creation Time' you can deduce when these connections were last established. Physical Link breakages should appear as Events in your Event and/or OPERATOR.LOG file. However, from what I could deduce from your configuration the OpenVMS connectivity was all LAN based, the WAN links being managed by another system/router (Cisco?), hence you would not see these events in your OpenVMS log files.

John
Anjan Ganguly
Frequent Advisor

Re: Analyzing OPCOM messages from Operator log.

Thanks John for all your valuable inputs.