Hmmm. I don't see anything in either NSCONTROL or LINKCONTROL that has an
INTERNET= type parameter.
NSCONTROL [ start, stop, abort, autologon, loadkeys, log=, server=, status,
mod ]
NSCONTROL STATUS shows info about people currently logged in via NS/VT, as
well as other ns service status items, but nothing about gateways or MAC
addresses.
LINKCONTROL has STATUS= and TRACE= options, and if I do a
LINKCONTROL @;STATUS=ALL, I get
Linkname: LANLINK Linktype: PCI 100BT Linkstate:
CONNECTED
Physical Path: 0/0/0/0
Current Station Address: 00-30-6E-0C-4C-49
Default Station Address: 00-30-6E-0C-4C-49
Current Multicast Addresses:
09-00-09-00-00-01 09-00-09-00-00-03 09-00-09-00-00-04
09-00-09-00-00-06
Transmit bytes 61628547519 Receive bytes
3867900143
Transmits 51716332 Receives unicast
27168338
Transmits no error 51716332 Receives broadcast
4241358
Transmits dropped 0 Receives multicast
68732
Transmits deferred 0 Receives no error
31426928
Transmits 1 retry 0 Recv CRC
error 0
Transmits >1 retry 0 Recv Maxsize
error 0
Trans 16 collisions 0 Recv dropped: addr
21426
Trans late collision 0 Recv dropped: buffer
30074
Trans underruns 0 Recv dropped:
descr 0
Carrier losses 0 Recv dropped:
other 0
Trans jabber timeout 0 Recv watchdg
timeout 0
Link disconnects 0 Recv
collisions 0
Link speed 100 Recv
overruns 0
Link duplex Full Link auto sensed
No
Link mode 100Base-TX Core Secs since clear
4317947
The section under 'Current Multicast Addresses:' look like MAC addresses,
but I can't see anything in LINKCONTROL to be able to refresh that list.
On Tue, Nov 12, 2013 at 11:46 AM, Howard Hoxsie <[log in to unmask]>wrote:
> I seem to recall (like Gary Stephens) that MPE caches the MAC for the
> gateway, and that there is a LINKCONTROL or NSCONTROL command that updates
> with an "INTERNET=@" or "INTERNET=ALL" clause. It's been a few years
> though...
>
> Good luck!
>
> Howard
>
>
> On Tue, Nov 12, 2013 at 10:36 AM, John Maclerran <[log in to unmask]> wrote:
>
>> Thanks Donna that clarifies a lot.
>>
>> We have a shutdown command file that basically stops all jobs, aborts all
>> sessions, ups the jobfence so nobody can log in, and brings down the
>> network interface. It doesn't do an MPE shutdown (i.e. no SHUT x
>> messages),
>> it leaves the system up, but with only operator.sys logged in on the
>> master
>> console. A corresponding startup command file restarts the network,
>> restreams the background jobs and returns the fence to normal for users to
>> log in.
>>
>> It sounds like we should do the shutdown just prior to the maintenance,
>> and
>> then a startup afterward. No need to physically restart the system though
>> (i.e. ctrl-a SHUTDOWN, ctrl-b RS)
>>
>>
>>
>> On Tue, Nov 12, 2013 at 11:06 AM, Donna Hofmeister <[log in to unmask]
>> >wrote:
>>
>> > On Tue, Nov 12, 2013 at 9:59 AM, Gary Stephens
>> > <[log in to unmask]>wrote:
>> >
>> > > wasnt there a gateway reset command, as I recall you could either do
>> an
>> > > nscontrol xxx internet;reset alternatively shut and restart the
>> network,
>> > or
>> > > something similar?
>> > > I am sure Donna will remember though!
>> > >
>> > >
>> > >
>> > > On 12 Nov 2013, at 17:17, Jack Connor <[log in to unmask]
>> >
>> > > wrote:
>> > >
>> > > > If you're taking it off the air for the network changes, John, I'd
>> go
>> > > ahead and close the network down until the work has completed and then
>> > > reopen it.
>> > > >
>> > > > MPE will be looking for the IPs as it opens up. I know you can see
>> the
>> > > MAC addresses in NETTOOL, but I don't think they're of any import
>> other
>> > > than informational and for DTC traffic.
>> > >
>> >
>> > I agree with what Jack said -- halt the network (even the system if
>> > possible -- because it's almost the same thing...) while the larger
>> network
>> > work is being done. When the new gear is in place and seems stable
>> "wake
>> > up" the 3000 and watch to what happens.
>> >
>> > When you halt the network (presuming you're not taking the box down) be
>> > sure to halt/quiesce network-dependent things (like jobs/listeners) just
>> > prior. I'd suggest doing an 'openq' on your network printers as well
>> (keep
>> > the input side of printing open, but not the output side). (And if
>> you're
>> > thinking "gee, it's almost like shutting down the system" see the
>> paragraph
>> > before this one :-) - d
>> >
>> > --
>> > Donna Hofmeister
>> > Allegro Consultants, Inc.
>> > 408-252-2330
>> >
>> > * To join/leave the list, search archives, change list settings, *
>> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>> >
>>
>>
>>
>> --
>> John MacLerran, IT Analyst, Senior ([log in to unmask])
>> Idaho State University <http://www.isu.edu> -- Leading in opportunity and
>> innovation
>> (208)282-2954
>> http://picasaweb.google.com/jmaclerran
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>
>
--
John MacLerran, IT Analyst, Senior ([log in to unmask])
Idaho State University <http://www.isu.edu> -- Leading in opportunity and
innovation
(208)282-2954
http://picasaweb.google.com/jmaclerran
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
