[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20040320: strange ADDE issue on newpsn (RH 9) (cont.)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200403190340.i2J3enrV010796 McIDAS ADDE

Robert,

I continued to test ADDE connections to newpsn from machines at the UPC
and from user machines on which I have logons.  I remembered that the
slowness in connecting from UPC machines is due to a configuration
setup we use here that checks for a particular type of response to
connection attempts in a process that validates transactions.  This
checking is turned on for all UPC machines except the Sun Solaris SPARC
box that I first used to contact newpsn.  The validation check times
out after 30 seconds if it doesn't receive the expected response and
then allows the connection to proceed.  This is the reason that
connecting to newpsn was taking 30 seconds from all UPC machines except
the Sun SPARC one.  One mystery solved...

I logged onto three different user machines in the Unidata community
and tested ADDE access to newpsn.  All three were able to contact
newpsn's ADDE server with no problems and with no delays.  The first
user machine was a Sun SPARC 5.8 box; the second was a Fedora Core 1
Linux box,; the third was a RedHat 8.0 box.  I have been trying to find
a non-UPC machine running RedHat 9 to test the connection to
newpsn, but I havn't found one yet.

Just to make sure that I know where your testing stands, I need to
know:

- did you rerun 'DATALOC ADD RTIMAGES newpsn.nsbf.nasa.gov' before
  trying to access newpsn's ADDE server?

- if yes, did you verify that the IP address for newpsn in ADDE
  client routing table got updated to the correct value?  Again,
  if you are running as 'mcidas', you would need to check the
  entries in both ~mcidas/workdata/MCTABLE.TXT and ~mcidas/data/ADDESITE.TXT.
  I am betting that what is going on is:

  MCTABLE_WRITE points to ~mcidas/data/ADDESITE.TXT
  MCTABLE_READ  includes ~mcidas/workdata/MCTABLE.TXT first and
                then ~mcidas/data/ADDESITE.TXT

  When you run DATALOC ADD or DATALOC HOST, ADDESITE.TXT gets updated
  correctly, but an incorrect entry in MCTABLE.TXT does not (this is
  as it should be if your MCTABLE_WRITE is setup to point at ADDESITE.TXT.
  Since MCTABLE.TXT is listed first in MCTABLE_READ, the old, bad IP
  for newpsn gets used, and your connection will fail.

  If your problem is an old value in MCTABLE.TXT, then the easiest/best
  thing to do is delete the file.  You can edit it, of course, but
  the potential for the problem will remain.

If your problem is not what I outline above, would it be possible for
me to logon to one of the machines you are having problems on so I can
do some troubleshooting?  The tests I have run from the variety of
machines I have access to have not shown that there is any problem with
the ADDE server setup on newpsn.  I must conclude that the problem is on
the client machines that you have the problem on, and guess that
the problem is the client routing table pitfall.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.