20010727: 20010726: running GEMPAK5.6 decoders

James,

Glad you have things working.

The problem with placing ship data in a daily file is that you
are limited to 30,000 observations in a ship file- where every location/time
is a separate observation. While you could use the YYYYMMDD template,
you would likely exceed the 30,000 observation limit.

The ldmadmin script is configured to rotate the ldmd.log file when
you start up the LDM, but you must have "setuid" permission
on the hupsyslog program in the ~ldm/bin directory for rotating the log.

Make sure the ldmd.log file is owned by ldm, and in the ldmadmin script you have
not set log_rotate to 0.

<snip>
# set this to 0 if you don't want the ldm log files rotated whenever you
# start or restart the ldm.

$log_rotate = 1;
<snip>

If you have problems getting ldmd.log to rotate, let support know and
we'll get someone to help on that end.


Steve Chiswell
Unidata User Support




>From: James Murakami <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200107272052.f6RKqu111095

>Steve,
>
>Eureka! It works!!
>
>After checking for directories and permissions, all of which
>checked out fine, I think the culprit was a silly mistake
>with the pqact.conf.
>
>I had made a copy of the then running pqact file. I made
>all the necessary modifications. I then copied this new
>file into the operational file (cp pqact.conf.new pqact.conf).
>I did a ldmadmin pqactcheck, and corrected three errors.
>
>This was well before I was ready to flip the switch, so to
>speak. So, when I was ready, I had forgetten about the changes
>I had made. I did a copy of "pqact.conf.new" not knowing that
>this file still contained incorrect formatting.
>
>Had ldm created a new "ldmd.log", I would have seen my error
>right away. How do I get ldm to start up creating such files
>again?  
>
>Secondly, can ship/buoy data be collected as a day's file
>rather than hourly? The man page, if I interpreted it correctly
>states that the files will be hourly or 6-hourly (if only
>ship reports required).
>
>Anyway, thanks so much for helping this "pretend" programmer.
>
>James
>
>
>> 
>> James, from your message below, your gempak logs should be in
>> /data/logs/dchrly.log and /data/logs/dcgrib.log.
>> Make sure the /data/logs directory exists, since GEMPAK won't create 
>> the log directory.
>> 
>> Dcmetr entry you have is decoding into /gempak/data/surface. Again, make sur
> e that
>> directory exist. Dcmetr won't create the data directory either.
>> 
>> Dcgrib2 uses the $GEMTBL/grid/gribkey.tbl file to define the data directory
>> used for each type of grid data it finds. The table as I provide it 
>> is set to decode under the ~ldm/data/gempak/model/ directory (eg,
>> the paths in gribkey.tbll are data/gempak/model...relative to the running
>> LDM. To display this data in nmap, make sure the MODEL environmental variabl
> e
>> is correctly defined in Gemenviron.
>> 
>> You will have to modify those paths acccordingly to your system. Dcgrib2 wil
> l
>> create directory paths as it needs.
>> 
>> Steve Chiswell
>> Unidata User SUpport
>> 
>