This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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.