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

20041104: McIDAS problem -- no map (cont.)

>From: Harry Edmon <address@hidden>
>Organization: University of Washington
>Keywords: 200411041914.iA4JEUvV018946 McIDAS mcenv environment

Harry and David,

>It was none of the below - it was a missing TERMCHAR.001 file (David - 
>it was supposed to be in /home/disk/data/mcidas).

Actually, the TERMCHAR.001 file is supposed to be created AND destroyed
on a per-session basis.  This file should be created in a subdirectory
of the ~/.mctmp directory in the user running McIDAS.  When the
environment variables needed by McIDAS are setup correctly, files like
TERMCHAR.001 are dynamic.  When the environment variables needed by
McIDAS are not quite correct, then TERMCHAR.001 gets created in some
directory in the user's MCPATH.  When this happens for the user
'mcidas', TERMCHAR.001 (and others) can get created in directories like
/home/mcidas/data or /home/mcidas/help.  Since all McIDAS users include
these directories in their MCPATH, and since those directories will
exist in their MCPATH before the temporary subdirectory of ~/.mctmp,
their sessions will see (read and attempt to write) the version that is
not owned by them -- this usually fails.

At a point where command executions start to fail, the only option is
for the user that owns the errant files to delete them from the
directories they got written to, typically /home/mcidas/data or
/home/mcidas/help.

>From address@hidden  Thu Nov  4 14:05:42 2004

Tom,

Let's ignore the

>>cannot locate string names - rerun setup.

>errors, since the LDM doesn't produce these images as user 'mcidas'
>but as user 'ldm'.

>For reference, our environment variables are:

>MCDATA=/home/disk/data/mcidas
>MCPATH=/home/disk/data/mcidas:/home/disk/ldm/mcidas/data:/home/disk/ldm/mcidas/help
>MCGUI=/home/disk/ldm/mcidas/bin
>MCTABLE_READ=/home/disk/data/mcidas/MCTABLE.TXT;/home/ldm/mcidas/data/ADDESITE.TXT
>MCTABLE_WRITE=/home/disk/data/mcidas/MCTABLE.TXT

This looks good.

>Hmm.  I login as user ldm on air and do what batch.k does and it
>works!   Here's the steps:

>mkdir ~/.batch/$$
>cd ~/.batch/$$
>setenv HOME `pwd`
>mcenv -f 700x872 << EOF
>imgdisp.k MYDATA/IMAGES.177 1 EU=IMAGE SU=IRTEMP
>map.k SAT 6 LALO -8 INT=20 20
>frmsave.k 1 3.9-w.gif FORM=GIF
>EOF
>setenv HOME ~ldm
>xli /home/disk/data/mcidas/3.9-w.gif

Interesting.  This looks to me to be an approach that Harry created.
The approach that I promote for my user community is to model scripts
after example ones I include in the Unidata McIDAS distribution:

~mcidas/data/mcrun.sh
~mcidas/data/batch.sh

>I think something is fouled up with our ldm processes running
>here.  I'll let you know if we need your help.

The three things that users running McIDAS have to worry about are:

- correctly and completely defining environment variables that run
  McIDAS commands

- removal of files that should be transient from directories that
  get included in users' MCPATH definitions (i.e., ~mcidas/data and
  ~mcidas/help)

- making sure that Cshell users McIDAS environment variable definitions
  in .cshrc have the appropriate guards for a redefinition of MCPATH
  when mcenv gets run:

umask 002

# MCHOME and McINST_ROOT
setenv MCHOME $HOME
setenv McINST_ROOT $MCHOME

# NOTE: conditional definition is only needed for C-shell users
if ( ! ${?MCPATH} ) then
  setenv MCDATA $MCHOME/workdata
  setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help
  setenv MCGUI  $MCHOME/bin
  setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
  setenv MCTABLE_WRITE "$MCHOME/data/ADDESITE.TXT"
  setenv XCD_disp_file $MCDATA/DECOSTAT.DAT
  if ( ! ${?path} ) then
    set path=${MCGUI}
  else
    set path=(${MCGUI} $path)
  endif
endif

# Limit ADDE transfers to compressed ones
setenv MCCOMPRESS GZIP

I have been running scripts with no problems on "production" systems
like motherlode for years with this setup and have never seen any
problems.

One other comment, users running under conforming shells like sh, ksh,
and bash do not see the weird problems that Cshell users do.  The reason
is that 'mcenv' when run from a Cshell session sources ~/.cshrc _after_
it adds the transititory directory created under ~/.mctmp to the
end of MCPATH.  If the guards are not in place in one's .cshrc file,
MCPATH gets redefined to the default, and McIDAS can then not see
the files created in the .mctmp subdirectory.  This is all very
arcane McIDAS nonsense that only gets manifested for Cshell users (sigh)!

Cheeers,

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.