>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
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.