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

20011112: 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,

>OK..so every time dataloc is run it writes to this file. Gotcha...

Right.

>And yes my scripts do have a DATALOC ADD command. But I want this. My
>scripts attempt to grab an AREA file from a server. If after so many
>attempts it does not find the image, I switch servers and look elsewhere
>after which I set he servers back to their default location (for
>me...CACIMBA...)

OK, this is the situation that I mused about in my last email.  Given that
you are switching servers, you _will_ want to edit your Unix shell
script(s) and add the definition and export of MCTABLE_WRITE.

>SO why can't I change them without deleting the file MCADDE.TXT first? I
>understand now why the file is showing up; why can't it be changed?
>
>Wait!!! I see...Follow with me in the folowing statements...

>I do have shell scripts to run the commands. In kickoff...it defines
>MCTABLE_READ="${MCHOME}/data/ADDESITE.TXT"

OK, so this sepcifies that ${MCHOME}/data/ADDESITE.TXT will be the only
file to be _read_ by McIDAS commands when determining what server to go
to.  Your problem is that your script has not said which file should be
updated when a DATALOC ADD is run.  It is most likely defaulting
to ~mcidas/mcidas/data/MCTABLE.TXT (your scripts are being run as
'mcidas').  What you most likely want is to define MCTABLE_READ and
MCTABLE_WRITE in your scripts as follows:

MCTABLE_READ="${MCHOME}/workdata/MCTABLE.TXT;${MCHOME}/data/ADDESITE.TXT"
MCTABLE_WRITE="${MCHOME}/workdata/MCTABLE.TXT"

Follow me here for a moment...

In the McIDAS login, MCTABLE_READ and MCTABLE_WRITE should be defined
as:

MCTABLE_READ="${MCHOME}/workdata/MCTABLE.TXT;${MCHOME}/data/ADDESITE.TXT"
MCTABLE_WRITE="${MCHOME}/data/ADDESITE.TXT"

This allows the user 'mcidas' to alter ADDESITE.TXT and so affect
each user that runs McIDAS (each user's MCTABLE_READ should have
${MCHOME}/data/ADDESITE.TXT as the second client table to read).
In normal operations, this would mean that 'mcidas' would have to
manually edit ${MCHOME}/workdata/MCTABLE.TXT in order to specify some
servers differently from the global settings in ${MCHOME}/data/ADDESITE.TXT.

Now, in your cron-initiated scripts, you can play by different rules.
You can use the set of default dataset-servers pairs in 
${MCHOME}/data/ADDESITE.TXT, AND you can change on the fly the server
that the cron-initiated process goes to.  This is done by setting
MCTABLE_READ and MCTABLE_WRITE to:

MCTABLE_READ="${MCHOME}/workdata/MCTABLE.TXT;${MCHOME}/data/ADDESITE.TXT"
MCTABLE_WRITE="${MCHOME}/workdata/MCTABLE.TXT"

Follow me?

>So when I run DATALOC ADD <site> it changes the MCTABLE.TXT file.  

IF that is the file designated to receive the write.  It dawned on
me this morning that the default set my McIDAS in lieu of a 
MCTABLE_WRITE specification is ~/mcidas/data/MCTABLE.TXT.  I think
you will find such a file if you look.  Note: if your 'mcidas' user
does not have a ~/mcidas/data directory, then you must create one!

>But I am still looking at the ADDESITE.TXT file so the crontab scripts
>being run do not see the change. That is why they tell me after them
>DATALOC ADD command that I am still looking at the old place.

Exactly.

>So...should I change that in the shell script?

Yes.

>Should it be a separte TXT
>file for each script in case there are several running at the same
>time?

It could be, but I don't know if you need to be that general.

>OF should I make the MCTABLE.TXT the place from where I read and
>just let it be global changes?

You could do this like I indicate above.

>I think I am closer to understanding...but I am still confused on what I
>need to do to fix it.

Set MCTABLE_READ and MCTABLE_WRITE as I indicate above in your script(s)
and make sure that these settings are exported in that(those) script(s).

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.