HP3000-L Archives

November 2013, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Maclerran <[log in to unmask]>
Reply To:
John Maclerran <[log in to unmask]>
Date:
Wed, 13 Nov 2013 09:29:05 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (274 lines)
Wow! Thanks to everyone for the great discussion.

Regarding the netcontrol command, MPE's help states that the update option
can only be used after the network it refers to has been started, so in
this:

NETCONTROL NET=lan1;UPDATE=INTERNET

I take that to mean that 'lan1' should have already been started.  By a
matching NETCONTROL command, right?

So, our current command file to bring the network up looks like this:

1  openq lp
2  spooler lp;start
3  spooler 501;start
4  outfence 7
5  NETCONTROL START;NET=LAN1
6  NETCONTROL START;NET=LOOP
7  NSCONTROL START
8  NSCONTROL SERVER=VTSERVER,0,500


So would I put the new netcontrol command after line 5 or afer line 7, or
does it matter?  Would it make sense to put it in the command file so that
the network tables get updated every time, or should I just be able to
issue it from the console after the new network gateway hardware is in
place?  If I want to try it out on a live system, will it drop connections?

Also, Thanks Jeff, for your info on the switch configs. I don't have access
to be able to do any of that, so I'll have to stick with the MPE end of the
problem.




On Wed, Nov 13, 2013 at 2:01 AM, Gary Stephens
<[log in to unmask]>wrote:

> Thanks Craig,
> that was the one: Getting old is not fun, all the 1's and 0's start
> getting in the wrong order ;-)
>
> Jeff: Good call, on a cisco device you can do a clear mac address-table
> dynamic
> that would clear the aforesaid table, if its a busy switch you would
> potentially see some degradation of traffic I guess, for a second or to
> whilst arp sorts things out but not something that should cause concern,
> would be interesting to see if that worked, have never tried it myself,
> its always been the internet;update command.
> interesting...
>
> On 13 Nov 2013, at 02:44, Craig Lalley <[log in to unmask]> wrote:
>
> > NETCONTROL NET=lan1;UPDATE=INTERNET
> >
> > from my aging memory, I will try it out tomorrow.
> >
> > -Craig
> >
> > Sent from my iPad
> >
> >> 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 *
>
> * 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 *

ATOM RSS1 RSS2