[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:	DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:	Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:	NETCAD::COLELLADT

Created:	Wed Nov 13 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4455
Total number of notes:	16761

2496.0. "DS900TM session number mismatch in HUBwatch" by DECPRG::PAVLUP () Mon Jul 10 1995 12:46

Can anyone comment the following behaviour of HUBwatch when managing
DECserver 900TM?

The configuration is as follows:
HUBwatch V3.1 on OpenVMS
DS900TM running NAQS V1.3 BL80-27

The problem reported by customer (and seen on-site) is a mismatch in numbers
of sessions presented in various HUBwatch windows. Particularly, the 
Terminal Server Summary window shows more session than an appropriate
Terminal Server Session Detail window. A typical situation is for
example as follows (note that the maximum number of sessions allowed is 4):

Window "Terminal Server Summary"

port 12		Total Sessions: 4 (LAT:4)

Then when clicking on the Session button, it shows:

Window "Terminal Server Session Detail"

1	LAT	Local		counters, timers
2	LAT	Local		counters, timers
4	LAT	Local		counters, timers

When cross-checking from the server console, i.e. by

Local> sho port 12 session all char

it shows:

Port 12, Session 1, Protocol LAT
Transparency Mode:

Port 12, Session 2, Protocol LAT
Transparency Mode: Interactive

Port 12, Session 3, Protocol LAT
Transparency Mode:

Port 12, Session 4, Protocol LAT
Transparency Mode: Interactive


The customer only uses LAT for communications.

Can anyone suggest where the problem can be (i.e. in HUBwatch, in server...?)

I agree that it is not highest priority. It does not hurt very much the 
operation, but the customer is annoyed a little, and you can imagine how
kind an annoyed customer can be...

Thanks for any info, experience or suggestions.

Regards Petr.

T.R	Title	User	Personal Name	Date	Lines
2496.1	My wild guess	ZPOVC::HWCHOY	On a foul day, you can complain forever.	`Tue Jul 11 1995 23:25`	10
	It is interesting to note that the sessions used are session 2, 3 and 4. Perhaps in HUBwatch they kind of infers the sessions from the highest session number in use, instead of actually counting them. Probably when you click on the session window, the counting actually gets done which you are seeing 3 sessions. Just a wild guess. ps: you really should upgrade to NAS v1.5, I've experienced some performance problems with v1.3 using SSU (set multisession enable).
2496.2	Interesting idea - some experiments necessary.	DECPRG::PAVLUP		`Wed Jul 12 1995 04:05`	9
	It's worth trying - I'll do some experiments... The upgrade to V1.5 is considered, too, but I'd like to know, if this behaviour may be related to HUBwatch, in which case the upgrade would not help... Thanks by now! I'll try to get more info. Regards Petr.
2496.3	Not as easy...	DECPRG::PAVLUP		`Wed Jul 12 1995 12:10`	18
	I have made some experiments trying to re-produce the situation. I must say that I did not succeed. First - the problem is not as suggested in .1. HUBwatch in normal operation correctly reads the number of sessions and updates information in both windows mentioned in .0 regardless the session IDs. Though I did not succeed to re-produce the situation, I realized that there might be some more information about the configuration on-site - the customer is using Virtual Terminals to support ACT's Quasar application. Might this not be some way a clue?? Just curious, whether anyone has seen something like that. I have no idea now how the situation can happen, however - I have seen it on-site... Thanks for any comments. Regards Petr.
2496.4		SLINK::HOOD	Maine state bird: The black fly	`Wed Jul 12 1995 17:16`	7
	To isolate the problem, have your customer enable SNMP_TRACE in HUBwatch, then bring up the DECserver summary window, then the sessions window. If you have questions about this, give me a call, Tom Hood HUBwatch dtn226-6776