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

20011108: why a DATALOC doesn't update to the fesired host

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

Paul,

>OK...after working for weeks on these scripts to ensure proper satellite
>pix, I now cannot find the problem. Running mcIDas now I am trying to run
>
>DATALOC ADD RTGINI PAPAGAYO.UNL.EDU
>
>only to have me stuck on ADDE.UCAR.EDU at least that is what MCIDAS is
>telling me.
>
>I run the above command and it returns DATALOC -- done and tells me I am
>still at ADDE...
>
>Perplexed...

Here is what is probably going on.

'DATALOC' is used to list, add, and delete entries from the default
client routing table.  McIDAS supports the concept of multiple client
routing tables, more than one that van be read and only one that can be
written.  The list of client routing tables that can be read is
controlled by the Unix environment variable MCTABLE_READ.  The single
client routing table that is designated to be written is controlled by
the Unix environment variable MCTABLE_WRITE.

The definition of these environment variables should follow:

<user is not 'mcidas'>

setenv MCHOME ~mcidas
setenv MCDATA ~/mcidas/data

setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
setenv MCTABLE_WRITE "$MCDATA/MCTABLE.TXT"

<user is 'mcidas'>

setenv MCHOME $HOME
setenv MCDATA $MCHOME/workdata

setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
setenv MCTABLE_WRITE "$MCHOME/data/ADDESITE.TXT"

The idea is that the user 'mcidas' can setup the global client
routing table ADDESITE.TXT, and the settings there will be used
by all users.

Users that are NOT 'mcidas' can define their own routing (DATALOCs)
and have them saved in their ~/mcidas/data/MCTABLE.TXT table
(by virtue of their MCTABLE_WRITE).  The values in MCTABLE.TXT take
precedence over the ones in ADDESITE.TXT.

The user 'mcidas', on the other hand, will only update the global
routing table, ~mcidas/data/ADDESITE.TXT when doing DATALOCs.  If,
however, a MCTABLE.TXT file exists in the ~mcidas/workdata 
directory, its entries will be used in preference to the ADDESITE.TXT
entries.  This setup allows the 'mcidas' user (who should be thought of
as 'root' for McIDAS activities) to maintain client routing
entries separate from the average user.  The drawback to this is
that 'mcidas' must manually edit ~mcidas/workdata/MCTABLE.TXT.

So, it is likely that:

o you are running the DATALOCs from the 'mcidas' account
o you have a MCTABLE.TXT file in the ~mcidas/workdata directory

The simplest thing to do at this point is to delete
~mcidas/workdata/MCTABLE.TXT.  Then the DATALOC you specified
will be seen and you will point at papagayo for RTGINI imagery.

If all of this is happening as a user other than 'mcidas', it
typically means that the ~/mcidas/data/MCTABLE.TXT file is not
writable.

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

Please let me know if your problem is something other than what I
listed above.

Tom