[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20011112: why a DATALOC doesn't update to the fesired host (cont.)
- Subject: 20011112: why a DATALOC doesn't update to the fesired host (cont.)
- Date: Mon, 12 Nov 2001 12:31:37 -0700
>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