Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Handy Hints For Upgrading Maxen
I learned a few things that I thought I pass along to others
as a result of trying to upgrade a Max from 5.1.x to 6.1.7 with
my own hands (I gave my entire staff the month of December off
in gratitude for a year of record revenues and profits, so I once
again became everyone's worst nightmare - a PhD with a screwdriver
and an Ascend manual).
A Max that had sat on the "spares" shelf needed to be deployed
to support growth at an existing pop. It was behind rev, so
it needed to be upgraded. Fool that I was, I scheduled two
hours for the task. 24 hours later, I can at last hand the
Max to an installation tech for deployment.
The following problems became apparent:
1) Ascend Website Links Don't
Link, that is.
Ascend's web site gives one the choice
of the "current release" or the "archives".
Neither contains 6.1.7 code, so one must
wander up a few directory levels from either
of the ftp directories that have the above
mentioned links to stumble into the 6.1.7
directory. Once there, one can find the
various loadable modules.
Using traditional ftp would have been a better
idea, since the web site seems to do nothing
but confuse matters, and force one into a
"scavenger hunt". The ftp directory structure
is at least dendritic, and thus, orderly.
2) IP-Only Loads Don't
Load, that is.
Difficulty in loading rtik.m40 prompted
me to call Ascend TAC. I was told to
"try rtk.m40 and ftk.m40 instead". While
I was unable to get an answer to why the
rtik.m40 package would not load properly,
I was told that "rtk.m40 works". Since
I can filter IPX and such at the routers,
I did not try to investigate the problem
with the ip-only load further.
Given my dislike for IPX and NetBEUI
thrashing about in our TCP/IP-only
infrastructure, has anyone loaded
the ip-only load of 6.1.7 (rtik.m40
and ftik.m40)?
3) Serial Downloads Won't
Load, that is. While one can get the restricted
load (r*) into the Max and make it "like it" after
only a few attempts, the extended load (f*) downloads
without error, but fails with "CRC errors" when the
Max attempts to "expand" it.
This confuses me, since we use a very
sophisticated vt-100 emulator
(Attachmate KEA, the successor to the
history-soaked Crosstalk from the days of
Apple IIs and CP/M), with a file transfer
mechanism that tracks errors, counts retires,
and generally insures that things like xmodem,
ymodem, and such work perfectly.
Given that the xmodem transfer works without
errors or retries, one is forced to wonder
if the Max silently "chokes" when being fed
data at 9600bps, and does not support/attempt
a retry of the "bad" block(s). One would think
that a CRC error would be detected during
transfer, if one existed or was somehow created
(perhaps by alpha particles hitting the cable?).
Despite the fact that Ascend's web-based "Upgrade
Instructions" document using a serial link as
an upgrade tool, it simply "does not work" in
the words of Ascend tech support. I am forced to
agree, since the same file that would not load over
a direct serial link loaded without incident when I
ran an ethernet cable to the Max, gave it a temporary
IP address on the lab LAN, and used tftp.
This, of course, prompts yet another warning from
the "real world":
3a) Ascend's Upgrade Instructions Don't
(Instruct)
But this view should come as no
surprise from the lab that coined
the phrase "Ascend RUBB" (Really
Useless Big Book), as in:
"Aye, there's the RUBB"
(Macbeth).
Despite the excellent re-packaging
from 3-ring binder to paperback,
I must decree that the term "RUBB"
be used again to designate:
"Really Useless Bunch o' Books"
or perhaps
"Reasonable Upgrades Beget Bummers"
4) Option Packages Pack Up And Leave
The upgrade, once complete, erased all the options
that had been provisioned on the Max, even "Data Call".
Yet another call to Ascend, and there I sat waiting
for an e-mail with the hash codes for three hours.
This alone means that one should NEVER attempt to
upgrade a Max during the wee hours of the AM (our
normal maintenance window), since one will need to
contact Ascend to get "hash codes" for even basic
functionality like supporting ISDN callers.
Too bad hash codes are not part of what is saved
via tftp or serial dumps.
5) New Hash Codes Make Hash Of Configuration Info
After loading the hash codes sent by Ascend,
the unit lost its configuration, and had to be
reloaded from a saved copy. Once again, this
could be a serious problem in a case where the
Max is a remote one, and connects back to the
core location over a T-1 plugged into the
Max itself.
Loading a hash code "kills" the machine, and
is yet another issue that seems to prevent
remote administration of a Max, since it
looses information that would make it
reachable for administrative access.
What is needed here is an approach that allows a person
of average intelligence to read instructions, follow
procedures, and be able to upgrade a Max without making
4 different calls to Ascend. The savings in time and money
for Ascend would make the effort worthwhile, since it would
reduce tech support calls.
I simply DO NOT ALLOW upgrades or other non-emergency work
to take place outside of our "maintenance window" of
4am to 6am. Since Ascend does not have a 24-hour helpdesk
like we do, the upgrade process as described by Ascend would
have killed a POP for nearly half a day.
Be forewarned. Following Ascend's instructions to the letter
could turn your maintenance window into a "malfeasance window".
Raisin Bran now claims 10% more raisins than before. Is this "2.2 Scoops"?
james fischer jfischer@supercollider.com
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>