>From: "Jennie L. Moody" <address@hidden> >Organization: University of Virginia >Keywords: 199911182049.NAA16853 McIDAS ADDE Jennie, 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: http://www.unidata.ucar.edu/packages/mcidas/mcx/mcxacct.html "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 MCDATA=/home/mcidas/workdata MCPATH=${MCDATA}:/home/mcidas/data:/home/mcidas/help MCGUI=/home/mcidas/bin MCTABLE_READ="/home/mcidas/mcidas/data/MCTABLE.TXT" MCTABLE_WRITE="/home/mcidas/mcidas/data/MCTABLE.TXT" PATH=${MCGUI}:... export MCDATA MCPATH MCGUI MCTABLE_READ MCTABLE_WRITE PATH cd $MCDATA 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. Tom
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.