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

19991119: Client Routing Table (cont.)

>From: "Jennie L. Moody" <address@hidden>
>Organization: University of Virginia
>Keywords: 199911182049.NAA16853 McIDAS ADDE


Late last night I wrote the following:

>I didn't even look at McTABLE_READ or McTABLE_WRITE.  If they are
>pointing to /home/mcidas/mcidas/data, and if there is a copy of
>ADDESITE.TXT in that directory (the directory ~mcidas/mcidas/data does
>exist), then that is why the remote server is working without copying
>~mcidas/mcidas74/data/ADDESITE.TXT to ~mcidas/mcidas76/data.  By the
>way, this may be a very _GOOD_ thing.  By leaving ADDESITE.TXT in
>~mcidas/mcidas/data, you no longer have to worry about it when you do
>cut over upgrades!

Upon reflection in the "light of day", this is rubbish.  The reason
that McTABLE_READ and McTABLE_WRITE are set to point to
~mcidas/mcidas/data in ~mcidas/.mcenv (used only by the ADDE remote
server run as the user 'mcadde') is to avoid an undesired, circular
condition.  If a remote ADDE data access request was directed to read a
client routing table on the server side, then the client request would
be sent off as a second client request to the remote server specified
in the client routing table;  ADDESITE.TXT in this case.  If the
dataset location requested was set to the same machine that the first
client request came in on, then the second client request would be
turned into a third request; the third into a fourth; etc.  I purposely
setup McTABLE_READ and McTABLE_WRITE in .mcenv to avoid this
situation.  I even comment on it in the online documentation for
configuring .mcenv:


"5. Copy the information that you put in the shell-appropriate
configuration file above to the file /home/mcidas/.mcenv converting, if
necessary, to Korn Shell syntax:

umask 002

Here, ... should be replace by the same directories you added to PATH above. 

Also, MCTABLE_READ and MCTABLE_WRITE are being set to non-existent
files so that the remote server being run by mcadde will always access
data locally (otherwise a circular definition would occur)."

This will teach me to not respond to questions after midnight!

So, you _will_ have to copy ADDESITE.TXT from the ~mcidas/mcidasXX/data
directory to the new distribution data directory, ~mcidas/mcidasYY/data
to keep things working in your method of cutting over to a new distribution.
Users doing a "standard" upgrade don't have to worry about this since
ADDESITE.TXT in does not get deleted or overwritten by a new distribution.

Sorry to be misleading on the above point.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.