20000509: Perl and mcenv (cont.)

>From: Bryan Rockwood <address@hidden>
>Organization: Creighton
>Keywords: 200004271734.e3RHYfG05347 McIDAS Perl CGI BIN

Bryan,

re: old Perl script was executing commands individually

>Yes, found that one out by going through perldoc.  I had the environmental
>stuff worked out, but didn't know how to process the commands.

OK>

>Thanks.  I
>have hit one problem, though.  When I am creating the product, I create
>the command line and store it to a variable, and then I run the variable
>when the time is right.  This seems to work 75% of the time.  The other
>25%, I get the following error from the log file:
>
>uaplot.k KOAX COL=2 3 7 1 4 7 7 8
>No observations found for selection conditions
>SNDSKEWT: Less than 3 mandatory p/t levels available!  No plot.
>SNDSKEWT: Failed to save sounding plot -- Error = -1
>UAPLOT:  Done
>Frame saved in /home/apache/htdocs/mc_output/OReE0JOGkQ0AABa1DuI_skewt.gif

The error being reported back from SNDSKEWT (UAPLOT runs SNDSKEWT) says
that there is not enough data from the station to do the plot.  In order
to check this out, you could do a UALIST for the station after making
sure that the station ID, KOAX in this case, has a station IDN (WMO
ID number).  UAPLOT does a lookup on the station ID that you provide to
find the station's IDN.  The IDN is what is used by SNDSKEWT to plot
the skewt-T.  I just checked and KOAX does have a station IDN, and it is
72558.  Given this, the problem might be:

o the station report is abbreviated, and SNDSKEWT is reporting back
  the correct error

o you have not installed the upper air data monitor (decoder) addendum
  that fixes problems encountered when a site reports multiple copies
  of upper air data (e.g., TTAAs, TTBBs, etc.), but the first copy is
  empty (has only the header followed by NIL)

o something else for which we don't yet have enough information to figure out

>For the top line, I just echo'ed the command variable to the logfile to
>verify I didn't screw that up.  Now, if it does work, I get the following:
>
>uaplot.k KOAX COL=2 3 7 1 4 7 7 8
>Erased image and graphic frame  1
>SNDSKEWT: Failed to save sounding plot -- Error = -1
>UAPLOT:  Done
>Frame saved in /home/apache/htdocs/mc_output/ORgJmpOGkQ0AABaxEsQ_skewt.gif

This is for an invocation that works?  Hmm... SNDSKEWT saves the data from
a skewt-T in a file named SNDSAVE.nnn, where nnn is a three digit number.
This file is used to do interactive sounding manipulations.  You should
check your MCPATH directories to see if there is/are SNDSAVE.nnn file(s)
that are not writable.  Perhaps SNDSAVE.nnn not being writable is the problem.

>This can be within seconds of each request.

So, you are saying that you can run the command through a web page and it
will fail and then run it again quickly and it will succeed?  What is
the web page (so I can take a look)?

>The only thing different
>between the script you sent me and my script is that the McIDAS
>environmental settings are in a perl module so I can use them in other
>scripts.  Do these errors make any sense?

No, not unless you are running the script just as the sounding information
for the station is being decoded.  What you will probably want to do
is get more debugging output from the commands being run so we can
find out exactly what is happening.  To do this, add the DEV=GCC keyword
sequence to the uaplot.k command line:

uaplot.k KOAX COL=2 3 7 1 4 7 7 8 DEV=GCC

Tom

>From address@hidden Tue May  9 10:39:28 2000

Bryan,

re: Perhaps SNDSAVE.nnn not being writable is the problem.

>Probably not.  I would imagine, based on the script, that the file would
>attempt to write to /home/mcidas/workdata, but being as the script is run
>as user nobody, can't create the file.  Probably the best solution for
>this is to install suEXEC for Apache and run it as a user with the McIDAS
>setup for their account.  Having global RW access for the workdata doesn't
>sound too secure :-).

You should create a new directory readable and writable as the user running
the CGI script and make it the MCDATA directory.  As always, the MCDATA
directory should be the first one in the user's MCPATH.

>Since this isn't needed for the static image, it
>shouldn't be a problem, right?

No, but getting rid of all insignificant problems helps troubleshoot
real ones.

re: running the CGI script soon after a failure

>Yes, that is the case.  The page is at
>http://whistler.creighton.edu/cgi-bin/mc_skewt.cgi

OK.

>The data is written to a directory on the web server located at
>http://whistler.creighton.edu/mc_output/
>
>That is where I am putting the log file, as well.  There is the standard
>perltest.log, and I made a copy of a bad request, which is located in
>bad_perltest.log

OK.

re: unless you are running the script just as the sounding information for
the station is being decoded.  

>This can happen in the middle of the day, so that wouldn't be the problem.

OK, so the problem is something else.

>Both scripts logs above where run with the DEV=GCC at the end of the
>command, so they have a full output.

OK.  It appears that the log file gets overwritten each time a plot
is made.  You may want to change the logging to append to the file until
the plot failure problem can be figured out.

Tom

>From address@hidden Tue May  9 11:01:57 2000
>Subject: Re: 20000509: Perl and mcenv (cont.) 

>You should create a new directory readable and writable as the user running
>the CGI script and make it the MCDATA directory.  As always, the MCDATA
>directory should be the first one in the user's MCPATH.

Done, I am using the same directory as the output gif images.

>OK.  It appears that the log file gets overwritten each time a plot
>is made.  You may want to change the logging to append to the file until
>the plot failure problem can be figured out.

Also fixed.

Rockwood