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

Re: 20010828: GDRADR fails



Steve:

Thanks. We were pointing to an old distribution. That was an easy one.

Tom


On Tue, 28 Aug 2001, Unidata Support wrote:

> 
> Tom,
> 
> The error messages you are seeing below indeicate that some of the
> GEMPAK environmental variables are not correctly configured, or
> you have not sourced the Gemenviron file in your script. Remember
> that sourcing Gemenviron defines the environmnetal variables
> as well as adds the GEMPAK $GEMEXE directory to your current path.
> 
> The [IP -10] message indicates that the $GEMPARM and $GEMPDF directories
> are not found. The [FL -1] errors indicate that the $GEMTBL/config directory 
> is not being found. The most likely cases for both these errors are that the
> environmental variables that GEMPAK is referring to are either not set in the
> script environment, or you might be pointing to an old GEMPAK tree and not the
> current distribution.
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> >From: address@hidden
> >Organization: UCAR/Unidata
> >Keywords: 200108281830.f7SIUn100950
> 
> >
> >Steve:
> >
> >We've been trying to use GDRADR on a RedHat 7 system 
> >(cacimbo.ggy.uga.edu). We had some success and generated mosaics using a 
> >script to rund GDRADR, following exactly what you suggested in the
> >documentation. However, I had to reboot the system for maintenance
> >and found that when we tried to restart the script that starts GDRADR,
> >it was failing to produce output files. 
> >
> >We then checked to make sure all processes were dead and did a gpend and 
> >checked the ipcs. After we were sure things were clean, we restarted 
> >GDRADR. Instead of giving us a list of options, we get...
> >
> >[ldm@cacimbo ~/mosaic]$ gdradr
> > [IP -10] GDRADR
> > [FL -1] datatype.tbl
> > [GDRADR 2] $RAD/NIDS/%SITE%/%PROD%
> > [FL -1] splpat.tbl
> > [FL -1] combo.tbl
> > [GEMPLT -1]
> >waiting 300 seconds<ctrl-c to continue>
> >
> >(You'll notice this was user ldm, but we also ran as user gempak with 
> >the same problems. I have checked all the file/directory permissions and 
> >they are fine. Both ldm and gempak are in the same group and all 
> >directories/files are group writable.)
> >
> >We're not sure where to look next.
> >
> >Thanks.
> >
> >Tom
> >
> >Thomas L. Mote
> >University of Georgia
> >
> >
> 
> **************************************************************************** <
> Unidata User Support                                    UCAR Unidata Program <
> (303)497-8644                                                  P.O. Box 3000 <
> address@hidden                                   Boulder, CO 80307 <
> ---------------------------------------------------------------------------- <
> Unidata WWW Service                        http://www.unidata.ucar.edu/      <
> **************************************************************************** <
>