Re: 19990426: no obs in gempak surface files 4/26

Thanks all for your quick replies, and thanks to Chiz
for these handy debugging aids (which I'm including
in case others might benifit).

The problem was that the data disk filled up again.
Seems due to those troublesome radar data files again.
The synop hour radar files were huge and started filling
out data disk again. Hopefully now we have things
under control again.

Again,
     Thanks for your help - it is nice to have friends :)

David

> 
> David,
> 
> My files appear fine. Several things to check:
> 
> 1) make sure you haven't filled up your disk recently
> 
>    If you disk fills up, then a zero length output file
>    will likely be created, which will not be a valid gempak data
>    management file, and no data can be written into it once
>    disk space is available.
> 
> 2) Make sure your table directories are available 
>    
>    The pqact.conf entry generally uses command line options that point
>    to your station and packing tables. If these move, or are not
>    readable by the LDM process, you won't get very far.
> 
> 3) Check the ldmd.log and dchrly and dcuair.log files for clues.
>    
>    If your system time is off, or directories are not writable,
>    then you should have some messages.
> 
>    If your pqact.conf files was edited...and maybe an entry before
>    the gempak decoders is messed up, then pqact will usually log 
>    a message in ldmd.log about the pqact.conf file and line number.
> 
>    Also, check tabs in the pqact.conf file if anything has been
>    changed recently. You can force a re-read of pqact.conf by issuing
>    a kill -HUP to the pqact process. See if rereading the file
>    mentions any configuration errors.
> 
> 4) Make sure the ldm process can execute the binaries
>   
>    Ocassionally, especially with Solaris, the LD_LIBRARY_PATH gets
>    updated or messed up and one or more of the shareable libraries
>    cannot be found. Test this by typing: ldd dchrly and ldd dcupair.
> 
>    If any shared libraries cannot be found, ldd will mention it.
> 
> 5) check the process list for dchrly and dcuair for hung processes,
>    or perhaps they are just writing to a different location if
>    a symbolic link in a directory has changed etc.
> 
> 
> Steve Chiswell
> Unidata User Support
>    
> 
> On Mon, 26 Apr 1999, David J. Knight wrote:
> 
> > Here is a weird one...
> > 
> > We are getting no data written to our gempak surface
> > or upper air files today 4/26/99. The data seems
> > to be comming in via idd, but not getting decoded
> > into gempak files. Near as I can tell none of our
> > config files have been changed. ship and synops seem
> > fine.
> > 
> > Before I pull out my few remaining hairs, can somebody
> > tell me if they are experiencing the same problem?
> > I'd hate to spend time looking for a local problem
> > if it doesn't exist...
> > 
> > Thanks
> > David
> > 
> > David Knight
> > Department of Earth and Atmospheric Sciences   Tel: (518)-442-4204
> > SUNYA   ES-228                                 Fax: (518)-442-4494
> > Albany, NY  12222                              Email: address@hidden
> > 
> > 
>