MZ,
My original comments and those below are the result of "defending"
the PM2's that are currently installed in a large communications
company with several thousand employees. They have approximately
45 PM2's installed all over the US and have NOT kept up with the
ComOS upgrades over the years (most are still running 2.4). I defended
the PM2 from the perspective that "they" have not managed the devices,
and they should not bad-mouth the PM2 since they've not kept
current. They originally were proposing replacing the PM2's with
another vendor's hardware, however they decided to keep them and
contracted with my company to upgrade all 45. Extensive Q/A calls
with Support ended with a decision to upgrade all to ComOS 3.3.2c1,
replace the old "B" eproms with "M" versions, and upgrade the 1meg
RAM to 4megs. We are currently about 30% complete with the project.
We have run into about every conceivable problem doing these upgrades
(with only about 12 completed) that you've seen on this listserver.
Over the past three weeks, we've spent no less than 20 hours on the
phone with Support trying to constructively work through these.
Each time we receive a little bit more factual assistence from Support,
but its like pulling teeth to get there.
The Support folks know about the PMconsole for Windows problems and
have various personal suggestions about "don't use that function...
as it doesn't work right". Why they haven't documented these for
internal purposes is beyond me, but I'd guess most of this has been
documented and it is one of the primary reasons why Livingston
recently hired a new employee whose primary responsibility is to
rewrite the PMconsole for Windows software (and I know the
individual's name too).
As with a large number of posts to this listserver, pointing out
errors/problems immediately turns into a personal confrontation
with one or more Livingston employees until such time as screen
prints and other "factual" documentation is so overwhelming that
someone finally admits it "could" be a problem. Passing the
information on problems to Support via email and/or telephone
calls *seems* to be ignored, or at the very least, goes
unanswered from a user's persepective. So its fairly obvious
there is a management issue within Livingston that needs to be
addressed and at least a portion of that issue is related to
human communications with customers. Personally, I have NO
vested interest in Livingston's success (I don't own any product)
and do not personally know any employee's; therefore all
of my comments are intended to be constructive statements that
should be used by Livingston to either improve the product and/or
internal processes.
>>1. Default routing entries are not displayed,
>
>I'm not sure what you mean. Where? Doing what?
If one telnets into a PM2 and do "show route", you see the default
route values. From PMconsole for Windows (v1.1) on a WFW 3.11 PC
you select "Tables" then "Routes", you only see a blank screen.
>>2. The Edit cut and paste is not functional (published), although
>> ctrl-C and ctrl-V do work,
>
>That is annoying yes, hardly a significant problem. Especially when
>the control keys still work.
Agreed.
>>3. Editing host tables causes a PMconsole GPF (and loss of Windows
>> Resources) when the host table exceeds 982 bytes (approx
>> 43 host entries),
>
>See answer to 4.
Your answer below does not address the statement above. This large
communications company does NOT have any form of DNS installed. They
have elected to use host tables for all name resolution including
their NMS, unix hosts, etc. Their PC's (about 1000) use a shared
host table that is installed on several Novell file servers, which
really has nothing to do with this issue, but works for them.
Their 45 portmaster names were the only entries they were including
in the portmaster host tables, until such time as we "discovered"
the limitation noted above. Due to the limitation, they now have
to use IP addresses (not names) for all portmaster configurations.
>>4. Host table allows complete duplicate entries, duplicate IP's,
>> and/or duplicate names (with different IP's),
>
>Yes, it does. And it does on the command line too. You can have
>more than one name on an IP. The host table is *DIRT STUPID*. It
>is not even meant for regular use, and we discourage its use. It
>is there for the few customers who really need it because they do
>not have DNS. The proper way to use a PM is to have DNS working
>or to use IPs. The Host Table is there for emergency backup use
>for the most part. If you have 43 host entries, you aren't using
>it as it ws meant to be used. And it is implemented as a completely
>simple lookup table. It is up to the human to know that they are
>doing. We're not going to error check for every possible screwup.
>Sysadmins should know better than to give the same name to two IPs.
>But two names to the same IP is legitimate.
>
>Not a real problem, IMHO.
It is a problem from the perspective that there is no documentation
as to the size limitations, and, using PMconsole for Windows allows
the user to blatantly stumble into a GPF.
That may be your humble opinion, however this large company (like
many others) have deligated portmaster management to a select few
that are not sys admin's, CAN read, but have not been provided
with sufficient information from Livingston to allow them to be
successful. If you would try to suggest to ANY sysadmin that
they could not have anything greater than 43 entries in their
unix host table, you would still run into a large number of them
that would object to your opinion (like it or not). The point
is the GPF, not whether your/my opinion is any better than
someone elses.
>>5. Following an "upgrade", spuradically will receive an error
>> window mentioning something about 'cannot write to AUX port',
>
>Is it reproducable? Anyone else see this? Unless we can reproduce
>it we can't fix it. This is the first report of it I have seen.
No its not reproducable. As mentioned it happens "spuradically";
approximately one out of five or ten upgrades. Clicking on "OK"
allows the process to complete in what appears to be a normal
manner. So its not serious, just a anonyance at this time.
>>6. No checking for configuration version change problems that
>> we are now all becoming somewhat sensitive to even though the
>> information to do so is available to PMconsole,
>
>I don't believe this is correct. Upgrading from what to what? If
>you go from say 3.0.4 to 3.3.1 I'm faily certain you will get a
>warning.
>
>What upgrade did you test where you expected to get a message and
>did not?
Several PM2's were upgraded from 2.4 -> 3.0.4 -> 3.3.2c1 following
the "ComOS 3.3.2 Release Note" documentation, section "Upgrade
Instructions". The functional ComOS version is displayed on the
PMconsole for Windows just as soon as a valid session is initiated
with a PM2, so PMconsole has the information.
You know (based on your previous comments published numerous
times to this listserver) the format of the config file changed
with 3.3.2c1. PMconsole (v1.1) certainly could be used to either
not allow or maybe update a config file to handle the changes.
Based on the serious problems recognized and mentioned on the list
server relative to versions 3.3.1, going with that version with
its bugs was not a consideration. So, going with 3.3.2c1 for a
stable PM2 was about the only choice (which was supported by
several Livingston employees).
None of the failed upgrades provided any indication or messages
that things were not correct until after the "reboot". The reboot
of these failed upgrades produced various messages like repeated
kernel reloads, totally hung PM2's, watchdog timer expirations,
etc., etc. (Most failures had to be addressed through netbooting
and/or U24 jumper.)
>>7. The greater the amount of traffic moving through a PM2 when
>> doing an "upgrade" from PMconsole, the higher the probability
>> of corruption following a reboot,
>
>This is something that one or two peop;e have have reported as a possible
>problem due to circumstantial evidence. Has it been reported as a bug
>via support? (Not that I know of, but I don't know everything that
>has been going on.) Is it a PMconsole for Windows bug - which is
>what we were talking about? Even if it is a bug, it is probably not
>related to PMWin as it was reported with UNIX pmconsole. AFAIK we
>have not seen hard evidence of it happening, just some interesting
>reports from users based on what circumstantial evidence.
The evidence is truely circumstantial, and really, more of a gut
feeling than anything. In doing the past ten or twelve upgrades,
we have used a printed checklist or script to ensure the steps are
consistent and accurate. Upgrading multiple PM2 10-port machines
from 2.4 -> 3.0.4 -> 3.3.2c1 has about (??) a 50% success rate. The
only major differences noted between these upgrades was the amount
of traffic and (obviously) some configuration parameters differ
between them. No modem tables, filters, user tables, or location
tables. The same PMconsole for Windows software (and the
same Compaq 486-33mhz notebook) was used, and PMconsole for Windows
was reloaded once to ensure there was not a problem with it. And,
yes the Support folks were involved with the failed implementations.
Whether they created any documentation on this is unknown to me.
Most failed implementations had to be netbooted (from the same PC),
and in some cases we had to use the U24 jumper method to bypass
reading the configuration data, and clearing all four nvrams.
Obviously the failed upgrade is SO bad there's not enough left
to determine what factually happened; only gut feeling.
>>8. When editing serial port values, the number of data bits does
>> not appear on the screen, and apparently cannot be changed
>> without telneting to the box or using a directly connected
>> console port to edit the value from the PM2 command line.
>
>PMconsole for Windows is deliberately restrictive. It is meant to
>limit the number of things configured - like not configuring speeds
>seperately. Since 99.99% of the users are 8N1, it generally causes
>more problems that it helps. And most of our advanced users, who
>are the ones likely to be changing things like that, report that they
>never use PMconsole and prefer the command line. So it was written
>for a specific audience.
The 99.99% might be your gut feeling for ISP use of the box, but
this communications company is using the PM2 with dedicated remote
serial connections (from various 7E1 9600 baud console ports), and
therefore can't use the PMconsole software to fully configure
their serial ports. Using your logic, 99.99% of your cutomers
probably don't deal with Netdata or Device Service=Telnet but its
shows up in PMconsole.
>>All of these have been seen from multiple WFW 3.11 machines
>>configured in several different ways, and are otherwise very
>>stable PC's.
>
>I have never had a problem with it on my WfWG 3.11 486-DX75 notebook,
>and that notebook is a stew of weird drivers because I test stuff on
>it. And a great many people report no problems running it. I'm sure
>it acts weird on some PCs - so does MS-Word.
Well I'm not sure what that has to do with anything. The fact that
other folks have problems, and, we CAN and HAVE documented
problems to Support as well as to this listserver, certainly appears
there are serious problems somewhere between PMconsole and a PM2.
I'd be more than happy to work with someone/anyone to produce a
more formal and constructive list of problems if you'd like, and we
can do it either on the list or privately. If you'all would
rather ignore them, that's fine too.
Rich
adar0@routers.com