|
Just to add some more info after more activity last night and today.....
The scenario described in -1 was still there after we had checked the
startups for LAT, which was set to work over the ethernet only.
After discussion with the customer he undertook to start LAT over the
FDDI links AS WELL as ethernet on the cluster nodes. This cured the
"unseen" LAT services problem as described previously, and remote
terminals could connect to all offered LAT services - quite essential for
correct cluster/network operations really !
However, I was/am not altogether happy that this dual-circuit LAT
operation (on the same extended/bridged LAN) is supported and a "clean"
solution - I am attempting to check this out - and in due course today
the customer has since reset LAT to use only the FDDI links.
It appears that the cluster nodes' LAT services can be seen and used by
terminal servers - so far so good !
I might add that DECnet is running over the FDDI only, the ethernet
circuit being switched off.
Now another "funny" has occured with LAT - this time with PCs running
PCSA. (I may need to gather more info here, but this is the scenario as I
currently understand it from a phone call taken earlier...)
A PC connects via Thinwire (behind a DESPR) to a cluster lobe's thickwire
segment.
This system boots/loads PCSA and can see its server which resides on
another separate thinwire behind another repeater off the thick segment.
Ethernet only nodes can be seen/connected to via DECnet SETHOST and LAT
Terminal Emulation software. However, the MDF Cluster nodes offering LAT
and DECnet via the FDDI links cannot be seen/conneted to, even though
there is the DECbridge 510 in place linking the ethernet segment to the
FDDI. Both LAT and DECnet don't work. Wierd !?
Any takers for this set of "features" ?
Hoping for a speedy response - my customer has been very patient so
far.....
Thanks
Rog
|
|
Simple Questions for Features...
Have you checked to make sure that the nodes on the FDDI offering
LAT services have the LAT$DEVICE or SET LINK command pointing to the
right hardware controller? do a SHOW DEV xxx /Full (xxx = mnemonic
FDDI device) and see if there is a LATCP process associated with it.
As far as the Herky Jerky DECnet stuff you need a Logical Topology
Map of all Network Hardware and then pull lots of various bridge
counters to check for errors. Also ask yourself some questions
like is this related to a particular Cluster , Segment or time of
day. Maybe you should consider renting an Ethernet or FDDI analyzer
to see what's going on or try to track a pattern.
I hope someone can spend a couple of days on this. This is not always
easy data to collect.
Good Luck,
Rene'
|