When I shut down one network (NETCONTROL SHUT;NET=TRLAN), all the VT-MGR
connections on another network also shutdown. Why? Can I fix it?

Context:

We have two networks configured:
Old Token Ring = "TRLAN"
New Ethernet = "LANPUB"

Most PC's pick up the new DNS entry and go to the new Ethernet "LANPUB". A
few PC's may have old hosts files not being refreshed and may still be using
old TRLAN. We wish to find them so we can fix them to use DNS. We intend to
permanently shut down old TRLAN soon.

Using NETTOOL CONNTABLE, I confirm this. A few remote IP's are still listed
as connected to the local IP configured for TRLAN. Most remote IP's show as
only connected to IP for new LANPUB.

I confirm this specifically with my own REFLECTION session. I know I have
configured it to use new DNS entry. CONNTABLE shows my PC's IP address
connected to new LANPUB and does NOT show any connection to TRLAN.

We choose to do the "shut down and die" method for finding the few items
still using old TRLAN. I do the command "NETCONTROL SHUT;NET=TRLAN".

Low and behold every VT-MGR session is blown off the HP3000. Instead of 5 or
6 connections going down, about 100 people are suddenly terminated with
message "Your 'VT-MGR' connection has terminated". This includes my own PC
sessions for which I had fully confirmed as much as possible. I now have
100+ people pissed off at me. Plus I did not learn a damn thing about the
real 5 or 6 connected through old TRLAN.

My Reflection session reconnects fine while TRLAN is shut down and only
LANPUB is started. But as soon as I restart TRLAN and shut it down again, my
session terminates on the shutdown. Even though the VT-MGR session
connection was initiated when TRLAN was not even started.

Any idea what the *!@!& is going on?

MPE/iX 6.0 PP2.
Yes I know we are on obsolete OS. Reiterating this fact won't change the
last five years of bad management decisions, delayed SAP and other
replacement implementations. Nor change the fact this division is up for
sale and there is no way they are going to pay for upgrading right now.
However, something along the lines of "this was a known problem in 6.0 and
fixed in #.#" might at least take some of the heat off me.
Of course an answer which will actually prevent this from happening next
time would be even better.

Timothy "just a lowly contractor with no decision authority" Atwood
for Domtar Vancouver Mill
Holtenwood Computing
http://www.holtenwood.bc.ca/computing/

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *