>From: address@hidden
>Organization: SMSU
>Keywords: 200012301857.eBUIvlo29945 McIDAS-X 7.7x ADDE motherlode
Bill,
I really should check the support inbox before I hit send on replies.
>What'd the fish say when he swam into the concrete wall? Dam!
:o
>Sorry, it's all down hill from there.
>
>First: Yesterday you corrected my .kshrc and .mcenv to have the pointer
>for MCTABLE.TXT. It is in $MCHOME/workdata. A file by that name
>was actually in $MCHOME/data, created Aug, 1999. And it has only
>an entry pointing to Local Data. I moved it to ..../workdata.
I suggest deleting ~mcidas/workdata/MCTABLE.TXT altogether. After that,
you will be using entries in ~mcidas/data/ADDESITE.TXT only. This is
a simpler setup and easier to understand. The MCTABLE_READ I setup
in .kshrc allows the McIDAS power administrator ('mcidas') to do things
using an editor that do not affect all McIDAS users. ADDESITE.TXT is
shared by all McIDAS-X users on a system by virtue of their MCTABLE_READ
settings.
>Don't know if this will have any impact one way or another, just thought
>I'd mention it.
It will have an impact that you might not expect. That is why I suggest
deleting it. After you do delete it, I suggest that you verify that
you still have the desired set of DATALOCations (run DATALOC LIST).
>Second: You found FRAMENH files all over my machine...they are kind of
>upredictable little buggers, aren't they?
They are typically caused when a McIDAS-X session is run from a Unix
session where the McIDAS environment variables have not been properly
set.
>I have (successfully?)
>re-created them in the $MCHOME/workdata directory.
Not good or desired.
>Actually, anytime
>one of my batch jobs is initiated by cron, FRAMED and FRAMENH.001 are
>created in ..../workdata.
This means that we need to take a hard look at the McIDAS environment
variable settings in those scripts and correct what must be wrong.
>All those jobs are initiated by a shell
>script copied from mcscour.sh. Again, don't know how important this is,
>but since you pointed this out, thought I'd mention it.
It is important since something is happening that is not desired. This
will come back to bite you if it is not taken care of. We _will_ get
to the bottom of this probably sometime today.
>Third (and last): I really hate to bring this up, because its a unix
>thing I ought to know, but, when my batch jobs run from cron, they
>cannot find the ADDE servers. If I simply initiate the shell scripts
>from the /home/mcidas/src directory, they work fine, but cron,
>apparently is not propogating the mcidas ADDE environment. This is
>not a problem for local files.
The cron-initiated shell scripts need to have MCTABLE_READ defined
along with MCPATH. Use the setting in ~mcidas/.kshrc as an example
of how to do this.
>Thanks again.
We're getting there...
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.