|
>a. The installation manual of the product is incomplete. The
>information contained in the READ.ME files in the distribution were
>critical to the installation. This is specially true for installation
>with a non-DEC Ethernet board (the PC I used had an SMC Elite Combo,
>using an NDIS driver with Pathworks).
You are partially correct; packet drivers are not available for all
Ethernet adapter boards. After some testing, we decided to include the
NDIS shim. The information in the README.TXT file will be in the manual
for V1.1.
>b. The lack of co-existence with Pathworks is a major drawback. It is
>very inconvenient to have to reboot and reconfigure the PC everytime we
>need to run HUBwatch. The READ.ME files mentioned an unsupported setup
>for HUBwatch and Pathworks co-existence. I did not try that method yet.
>I'll let you know of my impressions as soon as I succeed with that
>setup.
We agree that it is a major drawback; we hope to make Pathworks co-existence
supported in V1.1, if you are running Pathworks V4.1 over DECnet. Pathworks
5.0 and HUBwatch 2.0 should coexist with no limitations, we hope.
>c. It appears that some database manager (DBM) is used with HUBwatch.
>That DBM seems to be sensitive to data corruption. If HUBwatch aborts
>(as it did many times, see below) database consistency is lost.
>Opening an existing network results in
> RAIMA DATA MANAGER USER ERROR -6
> INVALID DB_ADDRESS
> C errno=0: error 0
> DLL: Raima Data Manager 3.21A
>That network database component had to be deleted. A DB check and
>rebuild/recovery utility would be useful in this case.
I guess we didn't find all the possible data corruption problems. Any more
information you could provide as to what caused this error would be
appreciated. Once you have the corrupted data problem, the only way
to get rid of it is to run IN.BAT in the HUBWATCH/CORE directory. This
will, unfortunately, wipe out your network database.
>d. HUBwatch seems to have a bug which causes the mouse movements to be
>misinterpretted. HUBwatch seems to behave initially, but after a few
>minutes of use, the problems show up. Moving the mouse causes
>unpredictable windows reactions (e.g., resizing windows, moving windows,
>changing focus from one window to another, iconizing windows, etc.).
>The PC in question has a Logitech serial mouse. To exit from the
>problem, I had to use the keyboard commands for Windows to exit from
>HUBwatch and other window applications, and finally exit Windows. Once
>the mouse problem occurs, all of Windows is impaired; it must be
>restarted.
We never saw anything like this problem, and we did do some testing with
a serial mouse, though perhaps it wasn't a Logitech. It does sound like
an interrupt or I/O problem. I don't think the 0x69 is the conflict though;
it sounds more like a physical interrupt conflict (1-5). Is there another
unused interrupt vector that you could set the Ethernet card to? or the
async port to?
|
| >We never saw anything like this problem, and we did do some testing with
>a serial mouse, though perhaps it wasn't a Logitech. It does sound like
>an interrupt or I/O problem. I don't think the 0x69 is the conflict though;
>it sounds more like a physical interrupt conflict (1-5). Is there another
>unused interrupt vector that you could set the Ethernet card to? or the
>async port to?
The customer has checked and he really has a bus mouse - not a serial mouse.
He is also getting the PC hardware checked to make sure it is not a PC
hardware problem. Will provide more details soon.
|