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

20040410: batch jobs interferring with current .NAM (cont.)

>From: Owen Cooper <address@hidden>
>Organization: Aeronomy Laboratory/NOAA
>Keywords: 200404081605.i38G5UCT028198 McIDAS scripts REDIRECT MCPATH

Hi Owen,

>Thanks you for your reply. I tried your modified script and it did 
>indeed run without interfering with my open mcidas session, i.e. the 
>REDIRECT file that was loaded in my open session stayed loaded after the 
>script ran and I was able to access all the MCIDAS data that were linked 
>to that .NAM file. So no problems there.

Sounds good so far.

>But I ran into the problem that my script could not find the MAP EU or 
>SU files called by the .BAT file.

I see from the output that it did not find the file SATANNOT either.
SATANNOT and the .EU/.SU files in the McIDAS distribution get
installed in the ~mcidas/data directory.  These files should be
accessible by virtue of MCPATH being defined  to include this
directory.

>I don't understand why these files could not be found seeing as $MCDATA 
>is in my $MCPATH, although now it is not the first entry as $TMPDIR is 
>now the first entry.

So, you have different .EU/.SU files that you are using and they are
stored in your MCDATA directory?  This would seem to say that the
MCPATH definition is invalid after the first directory.  Getting
a listing of $MCPATH in the running script would help us to see
if this is true, or if there is some other problem.

>I have attached the .scr .sh .BAT and .log files from my test run, plus 
>the resultng GIF image. All the batch job does is plot a previously 
>remapped NEXRAD AREA file. Could you take a look and see what's missing?

The script I sent you does not exhibit the problem you are seeing on
your system: it can see all of the .EU/.SU files in the distribution
and SATANNOT.  I tried this on our AIX 5.1 machine and on Solaris SPARC
5.6.

What is the set of REDIRECTions you are restoring in your script
(ICARTT04.NAM)?

The following listing is your TEST.sh script with comments stripped out:

>TEST.sh
>
>#!/bin/sh -f
>
>SHELL=sh
>export SHELL
>
>MCHOME=/home/mcidas/solaris
>
>case `id` in
>'uid=0('*)
>        echo "ERROR: cannot execute as user 'root'"
>        exit 1
>        ;;
>uid=?'(mcidas)'*        |\
>uid=??'(mcidas)'*       |\
>uid=???'(mcidas)'*      |\
>uid=????'(mcidas)'*     |\
>uid=?????'(mcidas)'*    |\
>uid=??????'(mcidas)'*   |\
>uid=???????'(mcidas)'*  )
>        MCDATA=$HOME/workdata
>        ;;
>*)
>        MCDATA=$HOME/mcidas/data
>        ;;
>esac
>
>NEXRAD_TMPDIR=$HOME/.mctmp/$$
>mkdir $NEXRAD_TMPDIR
>
>MCPATH=${NEXRAD_TMPDIR}:${MCDATA}:$MCHOME/data:$MCHOME/help
>
>MCLOG=$MCDATA/mcbatch_NEXRAD_test_$3$4.log
>
>if [ -f "${MCDATA}/MCTABLE.TXT" ]; then
>  MCTABLE_READ="${MCDATA}/MCTABLE.TXT;${MCHOME}/data/ADDESITE.TXT"
>else
>  MCTABLE_READ="${MCHOME}/data/ADDESITE.TXT"
>fi
>
>PATH=$MCHOME/bin:$PATH
>
>LD_LIBRARY_PATH=$MCHOME/lib:$LD_LIBRARY_PATH
>
>exec 2>$MCLOG 1>&2
>
>export MCHOME MCDATA MCLOG MCPATH MCTABLE_READ PATH LD_LIBRARY_PATH
>
>cd $NEXRAD_TMPDIR
>
>mcenv -f 1@700x800<<EOF
>redirect.k REST ICARTT04.NAM
>batch.k $1 $2 $3 $4 $5 CONTINUE=YES
>exit
>
>EOF
>
>cd $MCDATA
>rm -rf $NEXRAD_TMPDIR
>
># Done
>exit 0


Nothing in your script jumps out at me as being incorrect.  Could
you add a couple of lines in the script to help in debugging:

mcenv -f 1@700x800 << EOF
redirect.k REST ICARTT04.NAM
redirect.k LIST
echo `env | grep MC`
batch.k $1 $2 $3 $4 $5 CONTINUE=YES
exit

>Thanks!

The problem must be in the definition of MCPATH somewhere, but I
just don't see it from your listing.  Perhaps the additional two
lines in your TEST.sh script will help us find out where the
problem really lies.

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.

>From address@hidden  Mon Apr 12 09:40:56 2004

Hi Tom,

Okay, no problems with the new .sh script.
Silly mistake really.......
My home account can be accessed from either Solaris or Linux machines.
The .sh script was set-up to run on Solaris, but I was testing the 
script from the Linux side.
So the script was looking for files under /home/mcidas/solaris when it 
should have been looking under /home/mcidas/linux

My next step is to run several of these modified .sh scripts at once to 
make sure they don't interfere with each other.
Thanks for you help!
all the best,

Owen