20011110: why a DATALOC doesn't update to the fesired host (cont.)

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: COD
>Keywords: 200111082120.fA8LK8121993 McIDAS ADDE DATALOC

Paul,

>well what you have described is what the porblem is definitely. I do not
>understand why MCTABLE.TXT is being written. Somehow, it is updated...

The only way that MCTABLE.TXT can get written is for a DATALOC ADD
to be run when ~/<working_directory>/MCTABLE.TXT is designated to be
the file to be written.  It is possible that:

o ~/<working directory>/MCTABLE.TXT is the default file for writing
  unless one has explicitly specified a different file in
  one's MCTABLE_WRITE environment variable

o you have a cron-initiated script still running that is doing a 
  DATALOC ADD that is updating ~/<working directory>/MCTABLE.TXT

You should check all of the scripts you are running to see if DATALOC ADD
is being run.  If it is, you should stop it.

>the
>user mcidas who is doing the cronscripts, etc...is looking at MCTABLE or
>ADDESITE?

By looking at, I take it that you mean reading.  If yes, then the order
of the files read when trying to find out which server to go to is
totally governed by the setting of MCTABLE_READ.

>Why is MCTABLE.TXT being written

A DATALOC ADD _is_ running somewhere.

>and when does it get written to?

When the DATALOC ADD is run.

>Everytime I delete it, it comes right back when a command is entered.

I am convinced that at least one of your scripts is doing the DATALOC
ADD.  This may have been done before you understood that DATALOC
does not have to be run each time.  I believe that Gilbert had such
a script at one time (possibly still does); did you happen to get
one or more scripts from him?

re: Finally, if you are seeing this problem from cron-initiated scripts,
you may need to include definitions of MCTABLE_READ in those scripts.

>How would I do this? I have a script like the following which changes
>servers if the desired image is not present...

<deleted McBASI script>

In order to run your McBASI script from cron, you would have to run a
Unix shell script in which various McIDAS environment variables are
set and then mcenv is started and the McBASI script run.  It is in this
script that MCTABLE_READ and possibly McTABLE_WRITE have to be set.

In the McIDAS 7.8 distribution, I included a couple of example shell
scripts that are designed to be copied, edited, and then used to
run McIDAS commands from cron:  ~mcidas/data/mcrun.sh and
~mcidas/data/mcbatch.sh.  Each of these scripts shows what environment
variables need to set.  Here is a snippit from mcrun.sh:

 ...

#
# Set MCPATH using MCDATA and MCHOME
#

MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help

#
# Define MCLOG to be $MCDATA/mcrun.log
#

MCLOG=$MCDATA/mcrun.log

#
# Set MCTABLE_READ based on the existence of $MCDATA/MCTABLE.TXT.  Users
# should modify this section to match their setup if it does not follow
# the recommendations in the Unidata McIDAS-X online documentation
# for configuring user accounts.
#

if [ -f "${MCDATA}/MCTABLE.TXT" ]; then
  MCTABLE_READ="${MCDATA}/MCTABLE.TXT;${MCHOME}/data/ADDESITE.TXT"
else
  MCTABLE_READ="${MCHOME}/data/ADDESITE.TXT"
fi

 ...

This skeleton does not define MCTABLE_WRITE since I had assumed that
one would _not_ be doing DATALOC ADDs inside of the script.  This may,
in hindsight, be a shortsighted assumption (for instance, one might
want to test if a server is reachable and change to another one if the
first is not available).

The following code addition is, therefore, in order (insert just after
MCTABLE_READ definition section above):

#
# Set MCTABLE_WRITE based on which user is running this script.
#

case `id` in
'uid=0('*)
        echo "ERROR: cannot execute as user 'root'"
        exit 1
        ;;
uid=?'(mcidas)'*        |\
uid=??'(mcidas)'*       |\
uid=???'(mcidas)'*      |\
uid=????'(mcidas)'*     |\
uid=?????'(mcidas)'*    |\
uid=??????'(mcidas)'*   |\
uid=???????'(mcidas)'*  )
        MCTABLE_WRITE="$MCHOME/data/ADDESITE.TXT"
        ;;
*)
        MCTABLE_WRITE=$MCDATA/MCTABLE.TXT"
        ;;
esac


After adding this section, the 'export' line has to be altered to include
exporting of MCTABLE_WRITE:

export MCHOME MCDATA MCLOG MCPATH MCTABLE_READ MCTABLE_WRITE PATH 
LD_LIBRARY_PATH

After completely specifying which client routing tables are to be read
(MCTABLE_READ) and written (MCTABLE_WRITE), there should be no suprises
about why a particular table is being read or written.

Please let me know if the above made sense to you.

Tom