I think the command you're thinking about would be:
Netcontrol net=netname; update=all
Where netname is probably LAN or LAN1
Gilles Schipper
Sent via mobile
416-702-7900
> On Nov 12, 2013, at 2:02 PM, John Maclerran <[log in to unmask]> wrote:
>
> 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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
