20020508: cronjob and RTPTSRC data (cont.)

>From: Owen Cooper <address@hidden>
>Organization: NOAA Aeronomy Laboratory
>Keywords: 200205082229.g48MTKa18194 McIDAS

Owen,

>Yes the wether is nice, finally! Monterey can be a cold and damp place
>when you have persistent norhterly winds.  But today the sun is shining
>:o)

Sounds good.

>The shell script that I am using is modifed from mcbatch.sh and it is set
>up in the exact same way that all of the other shell scripts that I am
>running form cronjobs 30+ times per day.

Hmm...

>The only parameters that I
>changed are the lines where the .BAT file is called.

If what you sent in the first note:

cd $MCDATA
mcenv << EOF
  redirect.k REST ITCT.NAM
  mcenv -f 1@648x748 batch.k $1 CONTINUE=YES
  redirect.k REST DEFAULT.NAM
exit

Is really what you have in your copy of mcbatch.sh, then the problem is
in the second call of mcenv.  I would change the above lines to:

cd $MCDATA
mcenv -f 1@648x748 << EOF
  redirect.k REST ITCT.NAM
  batch.k $1 CONTINUE=YES
  redirect.k REST DEFAULT.NAM
exit

The problem is most likely caused by you running a second invocation
of mcenv from within an invocation of mcenv.  Since it appears that
your intention is to modify the mcenv invocation so that you have a larger
frame, the code above should be suitable.

>So I am really
>puzzled as to why the cronjob cannot find the data.

I think that the second invocation of mcenv (which runs batch.k) is
losing the information setup for the first invocation of mcenv.

>The UAPLOT command assumes the data are in RTPTSRC data sets.

Right.

>Does the
>dsserve listing have to be entered each time I run the script?

No, not if MCTABLE_READ is setup correctly in the script and exported
before mcenv is run.  This will insure that the definitions for
where to get the data (which ADDE server) will be the same as when
you run the command from the Unix prompt.

>What do you think?

I am highly suspicious of the second mcenv invocation.

Tom