Subject: (usr-tc) TCS 4.0 - anyone brave enough???

From: Scot Desort <[email-masked]>
Date: Fri, 02 Jun 2000 03:24:44 +0000

Anyone using the release version of TCS4.0, in particular, the new DSP code?
I see there are some improvements in v42 and Rockwell compatibility. Weird
though -- there are no links to the code in the LATEST CODE section of
totalservice -- you have to go to the compatibility matrix and then click on
the release.

--
Scot

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Richard Lorbieski <[email-masked]>
Date: Fri, 02 Jun 2000 03:30:25 +0000

I plan to do one tonight. The good news is the ARC card is 128M DRAM and
16M Flash :-)...

-- 

Richard Lorbieski - [email-masked]
Chief Technical Officer - Senior System Administrator
Alpha1 Internet  http://www.alpha1.net
409.731.8236  - 877.4.alpha1 (877.425.7421)

-

---

From: Scot Desort <[email-masked]>
Date: Fri, 02 Jun 2000 04:12:08 +0000

Keep us posted on how you do. What versions of HARC and DSP code are you
currently running?

--
Scot

----- Original Message -----
From: Richard Lorbieski <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 01, 2000 9:28 PM
Subject: Re: (usr-tc) TCS 4.0 - anyone brave enough???

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 02 Jun 2000 04:12:12 +0000

Also sprach Richard Lorbieski
>I plan to do one tonight. The good news is the ARC card is 128M DRAM
>and 16M Flash :-)...

Heh...keep in mind that you can get the 5.0.x code in 64/8...its just
tricky.  :)

As we've both said...Mike Andrews and I were both on the beta for this
(still running the most recent beta code, though I don't think there are
any differences from the released code).  I haven't had any
complaints...but then I must admit that IgLou isn't the best at tracking
connectivity differences between different versions of code.  Just need
more tuits.

I will say, I'm pretty happy with the Arc code...at least from a
management point of view.  I played with the DHCP capabilities
in...ah...5.0.8 I believe it was, and there were still problems with it.
Unfortunately, I didn't get a chance to check it out in 5.0.9 yet.  I
may see if I can get a chance to play with it tomorrow and see if they
fixed it.  If I remember correctly, it didn't handle renewing leases
very well at all...I believe (and looking back through my email
correspondence seems to confirm this) renewal requests are sent in for
the IP address "0.0.0.0" rather than for the actual IP address in use.
Obviously a problem there.  Like I said...I'll try to check out the DHCP
setup again tomorrow and see if they got that corrected in 5.0.9.  I
truly hope they did...'cause being able to manage all your Arc IP pools
from a central DHCP server will be *seriously* cool.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Charles Sprickman <[email-masked]>
Date: Fri, 02 Jun 2000 04:12:14 +0000

Also, since I'm really only looking for DSP fixes, is there any problem
with just upgrading the NMC and DSP and leaving the Arc as-is?

(crosses fingers and hopes for an iMac fix that's better than segregating 
some quads into a hunt)

Thanks,

Charles

-

---

From: Richard Lorbieski <[email-masked]>
Date: Fri, 02 Jun 2000 04:19:16 +0000

DSP - 2.0.60
ARC - 4.2.32
NMC - 6.1.17

I'm currently dloading the NMC and ARC managment software. The new 7.07
NMC is large (17 Megs).
You think they were releasing browser software :-). 

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 02 Jun 2000 04:38:08 +0000

>You think they were releasing browser software :-). 

Ooh...another FYI that at least Mike and I ran across.  The new NMC code
is completely different...pretty much rewritten from scratch is what I
understand.  This is good and bad.  The good is that its written to not
be so classful in its IP addressing (though I didn't ever get to check
it to make sure it worked correctly, at least if it doesn't, we
apparently stand some chance of getting that fixed now).  The bad is
that they have changed the way they do retrieval of SNMP values
apparently.  The older code apparently "cached" (maybe pre-fetched?
don't know details) values from the cards across the management bus.
This new code doesn't do that...meaning snmpwalks are going to be a tad
bit slower overall.  For values that it doesn't have to grab across the
management bus, its *much* faster (values about the NMC itself, and
index values basically), but when it has to get data over the management
bus, it does bog down a bit more.  Supposedly the HiPer NMCs are much
better about this, but with the 486 based cards, this can get to be a
fairly big problem if you're throwing a lot of SNMP traffic at it.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 02 Jun 2000 04:44:24 +0000

Also sprach Charles Sprickman

>(crosses fingers and hopes for an iMac fix that's better than
>segregating some quads into a hunt)

I believe I have heard the statement that TCS releases are "compatible"
between consecutive releases, though certainly not supported in that
configuration.  So, you can use (at least in theory) TCS 3.5/3.6 DSP
code (the DSP code didn't change between these releases I don't believe)
with TCS 4.0.  I haven't tested this at all, so don't take that as
gospel, but I've been told that 3Com at least puts some effort into
making that be the case.

FWIW, the Arc code really is pretty solid at this point as long as you
don't try to take advantage of new features.  I'd say you'd be fine
upgrading to new Arc code as long as you test out any new functionality
that you take advantage of.

For those of you that are as frustrated as I am maintaining 4.2.x Arc
code because of the idiosyncracies of command-line tab-completion, that
is *much* improved in 5.0.x...it even has partial-completion (ie, it
will complete the command out as far as is unambigous, ala Cisco's IOS
and many other CLIs...no more typing out a 20 character keyword because
the last character is different from another. :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Fri, 02 Jun 2000 07:21:36 +0000

> understand.  This is good and bad.  The good is that its written to not
[munch]
> fairly big problem if you're throwing a lot of SNMP traffic at it.

This brings up something I meant to mention in the beta... but was holding
out hoping they'd actually come up with a speed improvement or reimplement
the cache or something.

When it became obvious that the NETserver was running out of gas, 3Com did
a trade-in program for people to trade their NETservers in for HiPer ARCs.

Would they consider doing the same for 486 NMC's to P5 NMC's?

The only difficult part about an NMC tradein program would be x2 feature
enable keys for Quads.  (We still have two NMC's that manage Quads.)  Of
course they could just say the hell with it and permanently enable it on
P5 NMC's so you don't need one, but, well, we've been through that
discussion here before...

Given the costs of manufacturing a P5 NMC are probably far lower than a
HiPer ARC, I would think this would be even easier for them to stomach
than the NETserver->ARC tradein...

The performance difference is going to be an issue for us because we
almost continuously hammer on the NMC pulling connect stats off of it, and
with more than about 5 PRI's in a box it *really* starts to get sluggish.
On a box with only a couple of PRI's, it's not a problem, in fact it's
usually faster than the old code.  But load a box up with 9 PRI's and
watch all your software griiiiind to a halt...
I suppose we could reimplement a cache of our own using, say, a SQL
database, but I don't have time this month...  been busy rolling out ADSL,
installing a new core router (mmmmm, 7206vxr) and upgrading our email
system (read: finding/patching bugs in procmail) and really haven't
touched anything 3Com related for a while.

Anyway, despite the NMC being a bit slower, we've been running what is now
TCS 4.0 on one production box for a few weeks now and I don't think we've
had a Rockwell related complaint since.  On the other hand, I'm a bit more
removed from tech support than I used to be, so maybe it's just that
nobody's telling me. :)

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville
www.fark.com: If it's not news, it's Fark.  (Or something like that.)

-

---

From: Richard Lorbieski <[email-masked]>
Date: Fri, 02 Jun 2000 12:13:56 +0000

I just finished upgrading our code.

It went without a hitch... well we had to restart an aborted upgrade on
one of the DSP cards.

Didn't have a problem upgrading the ARC from 4.2.32 to 5.0.9 (we have a
128M DRAM - 16M flash ARC).

As for performance? Had some glitches with customers trying to login but
it may have been a radius problem. Yet, most users are getting v.90
connect :-)... So far, I think its safe to upgrade.
Currently the DSP cards are on CT1s (planning to change to PRI in the
next week).

Will post some more info later. 

-- 

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 02 Jun 2000 17:53:18 +0000

Also sprach Jeff Mcadams
>I played with the DHCP capabilities in...ah...5.0.8 I believe it was,
>and there were still problems with it.  Unfortunately, I didn't get a
>chance to check it out in 5.0.9 yet.  I may see if I can get a chance
>to play with it tomorrow and see if they fixed it.  If I remember
>correctly, it didn't handle renewing leases very well at all...I
>believe (and looking back through my email correspondence seems to
>confirm this) renewal requests are sent in for the IP address "0.0.0.0"
>rather than for the actual IP address in use.  Obviously a problem
>there.  Like I said...I'll try to check out the DHCP setup again
>tomorrow and see if they got that corrected in 5.0.9.  I truly hope
>they did...'cause being able to manage all your Arc IP pools from a
>central DHCP server will be *seriously* cool.  :)

Well...its *better*...but still not quite right.  My apologies to 3Com
for not getting around to checking this actually during the beta...just
didn't have enough hours in the day.  This isn't really a critical
feature at this point, but I certainly do see the advantages of it so I
want to try to help you all get it working.  :)

Jun  2 11:28:04 quiz dhcpd: DHCPREQUEST for 204.255.236.215 from 00:c0:49:10:e3:16 via hme0
Jun  2 11:28:04 quiz dhcpd: DHCPACK on 204.255.236.215 to 00:c0:49:10:e3:16 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPREQUEST for 204.255.236.215 from 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPACK on 204.255.236.215 to 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPREQUEST for 204.255.236.215 from 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPACK on 204.255.236.215 to 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPREQUEST for 204.255.236.215 from 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPACK on 204.255.236.215 to 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPREQUEST for 204.255.236.215 from 00:00:00:00:00:00 via hme0
Jun  2 11:28:07 quiz dhcpd: DHCPACK on 204.255.236.215 to 00:00:00:00:00:00 via hme0
Jun  2 11:28:10 quiz dhcpd: DHCPRELEASE of 204.255.236.215 from 00:c0:49:10:e3:16 via hme0 (found)

As you can see...it tries several times to get the lease renewed, and
gets the correct IP address added this time, and for the first renewal
request, it has the correct MAC address.  Subsequent requests have a
bogus MAC address from what I can tell.  I'm not sure why the original
renewal request fails, but since it retries it several times, it
apparently isn't seeing something correctly.  Again, as I mentioned
during the beta...I'm not extremely well versed in DHCP at this point,
so there may be more information that I can get out of the dhcp server
that might help...let me know and I'll see what I can do.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Charles Sprickman <[email-masked]>
Date: Fri, 02 Jun 2000 23:09:05 +0000

> gospel, but I've been told that 3Com at least puts some effort into

I was actually looking at doing the opposite; staying with my ARC code for
now and trying the new DSP code on a few racks for a few days...  I was
going to try the NMC as well, but it looks like that might not be
advisable if it will actually make snmp slower (how is that possible?).

You'd think they could do everything the NMC needs to do in a 486 without
much optimization.  I mean, it's not running a GUI or anything...
 
> that you take advantage of.

I'm just about to read the release notes, I'm curious about this "interim
release" I have to do between 4.2x and 5.0.x...

Thanks,

Charles

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 03 Jun 2000 15:14:26 +0000

>> I believe I have heard the statement that TCS releases are
>> "compatible" between consecutive releases, though certainly not
>> supported in that configuration.  So, you can use (at least in
>> theory) TCS 3.5/3.6 DSP code (the DSP code didn't change between
>> these releases I don't believe) with TCS 4.0.  I haven't tested this
>> at all, so don't take that as gospel, but I've been told that 3Com at
>> least puts some effort into making that be the case.

>I was actually looking at doing the opposite; staying with my ARC code
>for now and trying the new DSP code on a few racks for a few days...  

I think it goes both ways, so you'd be fine.  Again though, this
certainly isn't anything that's tested.

>I was going to try the NMC as well, but it looks like that might not be

>You'd think they could do everything the NMC needs to do in a 486
>without much optimization.  I mean, it's not running a GUI or
>anything...
 
Well...the slowdown is a result of getting the data over the management
"bus" from the cards.  If its getting data from the NMC itself, it
screams...orders of magnitude faster than the old code.  The management
bus is basically a individual set of serial lines for each card though,
so its not like you've got ethernet bandwidth there or anything to work
with.  I think I remember seeing that the management lines to the NACs
are 512kbps, which is pretty quick, but its certainly going to be slower
than the NMC grabbing the data internally (ie, not over the management
lines).

>> FWIW, the Arc code really is pretty solid at this point as long as
>> you don't try to take advantage of new features.  I'd say you'd be
>> fine upgrading to new Arc code as long as you test out any new
>> functionality that you take advantage of.

>I'm just about to read the release notes, I'm curious about this
>"interim release" I have to do between 4.2x and 5.0.x...

I don't remember having done that, but I might have.  Does make the
upgrade process a bit more disruptive, but this is the only time you'll
have to do that.  Ok...found in the release notes where its talking
about it.  The older code can't download a file that big into flash ROM,
once you get on the newer code though, you're back to normal upgrades
(assuming you don't run out of flash, which is getting to be a concern
with these bigger images...older Arcs only had 8megs of flash ram)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: [email-masked]
Date: Sat, 03 Jun 2000 19:01:16 +0000

OK,

  With all the talk of the new code, has anyone put the code on a HiperArc
with just 64 of memory?   I have 4 HiperArcs  Two with 128 and two with
64.   Three of the 4 are in production (live).  Can the memory from the
4th one be used to up grade the other HiperArc?

  Also, any problems with the FLASH 4 vice 8?

  We are not doing anything fancy, just ip.. No IPX, OSPF, etc

  Thanks!

==============================================================================
Phillip Ferraro				WorldNet Access, Inc
[email-masked]	Onslow County's PREMIER InterNet Service 
Voice (910) 346-0835		    824 Gumbranch Square, Suite Q
FAX   (910) 455-1933		     Jacksonville, Nc  28540-6269
==============================================================================

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 03 Jun 2000 23:07:46 +0000

Also sprach [email-masked]
>  With all the talk of the new code, has anyone put the code on a
>HiperArc with just 64 of memory?   I have 4 HiperArcs  Two with 128 and
>two with 64.   Three of the 4 are in production (live).  Can the memory
>from the 4th one be used to up grade the other HiperArc?

I had it running in 64megs of RAM briefly during the beta...worked fine.
Though it was slightly tricky to get it on there with only 8 megs of
flash to work with.

>  Also, any problems with the FLASH 4 vice 8?

4?!  Didn't know such a beast existed...at least as shipped.  I'd say
all bets are off on being able to get the code on there in 4 megs.
*Maybe* if you had the boot menu pull it down, but even that is gonna be
really iffy (the 5.0.x code is almost 3 1/2 megs, and it has to go
through some uncompress and reclaim cycles during the actual upgrade
process - once you actually reboot to activate the new code - I'd say
its unlikely to be able to pull that off)

>  We are not doing anything fancy, just ip.. No IPX, OSPF, etc

If you could get the code on, you shouldn't have any problems running in
64 megs of ram...the flash issue is really iffy though.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Sun, 04 Jun 2000 04:27:12 +0000

64 meg works fine here.

As far as getting the code onto a 4 meg flash...  you don't *have* to use
the "interim release" approach.  The documentation describes a few others.
The one I used was...

- put the .dmf file on a TFTP server with the name 'netserve.dmf'
- connect a terminal to the console port of the ARC
- reboot it
- as it reboots, a menu will come up.
  Quickly feed it its own IP/netmask and the IP of your TFTP server

and it will TFTP the file down and update it right away.  Pretty fast,
doesn't need two reboots.  I'd practice on a non-production card if you
can first, to get the procedure down though. :)

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sun, 04 Jun 2000 14:06:54 +0000

Also sprach Mike Andrews

>As far as getting the code onto a 4 meg flash...  

I think you're thinking 8 meg flash, not 4.  64meg Arcs usually
(always?) have 8 megs of flash, compared to the 16 in the 128 meg Arcs.
:)

>you don't *have* to use the "interim release" approach.  The
>documentation describes a few others.  The one I used was...

True...I think I may have ended up using the boot menu like you
described.

>and it will TFTP the file down and update it right away.  Pretty fast,

Well, as fast as TFTP ever is...not exactly a highly efficient protocol
there.  :)  Does the job though.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Sun, 04 Jun 2000 18:31:20 +0000

> (always?) have 8 megs of flash, compared to the 16 in the 128 meg Arcs.

Yeah, I meant 8 vs 16 meg.

> there.  :)  Does the job though.  :)

Well yeah, but it was only about 10 seconds...  not slow like TFTPing to
an NMC is. :)

-

---

From: [email-masked]
Date: Mon, 05 Jun 2000 17:21:45 +0000

U>Also sprach [email-masked]
U>>  With all the talk of the new code, has anyone put the code on a
U>>HiperArc with just 64 of memory?   I have 4 HiperArcs  Two with 128
U>and >two with 64.   Three of the 4 are in production (live).  Can the
U>memory >from the 4th one be used to up grade the other HiperArc?

U>I had it running in 64megs of RAM briefly during the beta...worked
U>fine. Though it was slightly tricky to get it on there with only 8
U>megs of flash to work with.

U>>  Also, any problems with the FLASH 4 vice 8?

U>4?!  Didn't know such a beast existed...at least as shipped.  I'd say
U>all bets are off on being able to get the code on there in 4 megs.
U>*Maybe* if you had the boot menu pull it down, but even that is gonna
U>be really iffy (the 5.0.x code is almost 3 1/2 megs, and it has to go
U>through some uncompress and reclaim cycles during the actual upgrade
U>process - once you actually reboot to activate the new code - I'd say
U>its unlikely to be able to pull that off)

U>>  We are not doing anything fancy, just ip.. No IPX, OSPF, etc

U>If you could get the code on, you shouldn't have any problems running
U>in 64 megs of ram...the flash issue is really iffy though.

Can the HiPerArcs flash be upgraded from 8 to 16 megs ?

Jeff Binkley
ASA Network COmputing

CMPQwk 1.42 9999

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 05 Jun 2000 17:59:38 +0000

Also sprach Jeff Binkley
>Can the HiPerArcs flash be upgraded from 8 to 16 megs ?

Doesn't look like it.  If you look at one of the Arc boards, with the
faceplate to the left, towards the bottom of the board, just to the
right of the DIMM SOCKET (labelled as such), you'll see the "FLASH ROM"
chips (2 rows of 4 chips...also labelled as such).  These are soldered
on, so it doesn't look upgradeable...at least without a soldering iron,
and that's something that I certainly don't want to get into.  :)

At least, this is what I'm seeing on my board...though I *think* this is
a 128/16 board, not a 64/8.  I would assume the 64/8's would be
similar...perhaps only half the chips though.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Greg Coffey <[email-masked]>
Date: Mon, 05 Jun 2000 18:00:42 +0000

From the for what's worth dept:

I upgraded the code in one chassis over the weekend without any 
problems.  It has 8 DSP's an Arc with 128/16 and a 486 NMC card.  So far, 
it seems stable and I haven't had any calls about failing to connect or 
other recent issues.  Actually, has been very quiet since the upgrade.

Thanks, Greg Coffey                               <[email-masked]>
Visionary Communications  V 307-234-5443    F 307-234-5446
100 N. Center Suite #100, Casper, WY  82601    www.vcn.com
_________________________________________________________

-

---

From: Russ Miescke <[email-masked]>
Date: Tue, 06 Jun 2000 08:24:43 +0000

Is a service contract required to download TCS 4.0?  I have purchased a new
Total Control bundle among several other things in the last couple of months
and have registered it with 3Com.  When I go to the download site,
everything appears to be available to me, but none of the links work.
Anyone else have this problem?
Russ Miescke
Power Web Connect

-

---

From: Denis Newkirk <[email-masked]>
Date: Tue, 06 Jun 2000 13:48:38 +0000

If you're like me, you'll have to fight to get the access you've paid for. 
After you download what you need, they cut you off again, so you have to 
fight/beg again. I think it must be a power thing with Michelle, who has 
ALWAYS been rude to us. I've never heard anyone say they've had a good 
experience with her.

I would consider her the Nurse Ratchet (?Spelling) of 3Com :)

-

---

From: Rick <[email-masked]>
Date: Sat, 10 Jun 2000 02:41:39 +0000

The only problem I see with a centralized DHCP would be the issue of having
a much larger internal routing table due to /32 announcements. We now
aggregate all our TC hub pools in /25 or /24 announcements and  implementing
a DHCP solution would strongly impact our OSPF.

--
Rick Allan
Chief Technical Officer
Vice President of Engineering
Monmouth Internet Corporation
http://www.monmouth.com
1-877-MONMOUTH option 6 (1-877-6666688)

-

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 10 Jun 2000 05:10:22 +0000

Also sprach Rick
>The only problem I see with a centralized DHCP would be the issue of
>having a much larger internal routing table due to /32 announcements.
>We now aggregate all our TC hub pools in /25 or /24 announcements and
>implementing a DHCP solution would strongly impact our OSPF.

You just need to get a better DHCP server is all...one that gives you
more control.  :)  Keep in mind that when you get a DHCP request, you
get the MAC address of the originating system, the IP address of the
relaying system (if any), and potentially other identifying information.
This set of information can be used to make your IP assignments more
efficient, ie by grouping your leases together in a way that can be
aggregated in your routers.  Although, if you're running OSPF on your
Arcs, you'll have to put your Arcs in a different area, and aggregate on
the area boundary like on a Cisco.  If your Arcs are still running RIP
and your redistributing into OSPF (which is what I'm doing), then you
can aggregate/summarize at the redistribution (nice little bonus there).

Admittedly, configuration your DHCP server with this type of detail
removes some of the benefit of centralizing control, but there are other
management wins with this...
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: [email-masked]
Date: Wed, 14 Jun 2000 22:35:02 +0000

Mike,

 Does the netserve.dmf file go in the ROOT dir of the server?   How will
it know where to find the file?

-

---

From: [email-masked]
Date: Sat, 11 Nov 2000 23:50:23 +0000

Is there a way to save the configuration settings from HiperArc
and NMC card to a file?   I am thinking about disaster recovery and would
like to know what other do to preserve the current configuration in the
event that a new card might need to be configured...

 Thanks in advance!

-

---

From: Dayton Internet <[email-masked]>
Date: Sun, 12 Nov 2000 05:11:17 +0000

One way if you have TCM is from File, Save configuration. That will save
it on that computer. Make sure you write down the name of the file you
save it to.

-- 
       --Rich Adams, President, Array Technologies Dayton, Ohio--
[email-masked]

-