20030524: LDM or McIDAS Feed Problem (cont.)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200305212159.h4LLxclL042738 LDM IDD pqing Unisys NOAAPORT

Hi Jim,

I logged back on to cyclone to troubleshoot problems we discussed
in our last email exchange:

- LDM logging failures

- excessive GEMPAK decoding errors

I found that the logging problem was being caused by the lack of the
socket /var/run/log.  This is supposed to be created on bootup -- here
is the section from /etc/rc:

# Start system logging and name service.  Named needs to start before syslogd
# if you don't have a /etc/resolv.conf.
#
case ${syslogd_enable} in
[Yy][Ee][Ss])
        # Transitional symlink (for the next couple of years :) until all
        # binaries have had a chance to move towards /var/run/log.
        if [ ! -L /dev/log ]; then
                # might complain for r/o root f/s
                ln -sf /var/run/log /dev/log
        fi

        rm -f /var/run/log
        echo -n ' syslogd';
        ${syslogd_program:-/usr/sbin/syslogd} ${syslogd_flags}
        ;;
esac


The thing that was missing was the 'ln -sf /var/run/log /dev/log'.  I
made this link as 'root' and the LDM logging immediately started.
Why this had to be done by hand is something that needs to be
investigated and paid attention to after a reboot.

As far as the GEMPAK decoding errors, I found that several GEMPAK
decoders referenced in ~ldm/etc/pqact.conf did not exist in
~ldm/decoders but did exist in ~ldm/decoders.old, or did not exist in
any directory under ~ldm.  The decoders in question referenced in
pqact.conf are:

dchrly
dcsynop
dcncprof
dcprof
ldmConnect

It appears that dchrly and dcsynop decoders are quite old.  For
instance, the versions of these decoders that still exist in the
decoders directory on a UPC test machine date back to February of
2000:

/local/ldm/decoders% ls -alt dchrly dcsynop
-rwxrwxr-x   1 ldm      ustaff    381020 Feb 29  2000 dcsynop
-rwxrwxr-x   1 ldm      ustaff    457852 Feb 29  2000 dchrly

Also, we have no pqact.conf decode actions that use these decoders.

I found FreeBSD executable copies of these decoders in ~ldm/decoders.old,
so I made hard links to them in ~ldm/decoders.

I found a FreeBSD executable copy of dcprof in
/huge/gempak56d1/unidata/ldmbridge/dcprof/dcprof, so I copied it to
~ldm/decoders.

I found a FreeBSD executable version of dcncprof in
/huge/gempak56h/unidata/ldmbridge/dcncprof/dcncprof, so I copied it to
~ldm/decoders.

I found an executable of ldmConnect in ~ldm/decoders.old, so I copied
it to ~ldm/decoders.

I still see error messages which I believe are related to GEMPAK
decoding in ~ldm/logs/ldmd.log, but they are _way_ less frequent than
the what were being written before the above.

I also saw error messages related to ldm-mcidas decoding on NLDN
lightning data.  This was being caused by the lack of copies into the
output directory, /mdata/mcidas.  To stop the errors, I made links in
/mdata/mcidas for the files ROUTE.SYS, SYSKEY.TAB, and SCHEMA to
/mdata/mcidas-c.  Now, McIDAS MD files of lightning data are being
created in /mdata/mcidas.  Whether or not you actually want this is in
question, since I don't think you have any crontab initiated actions
setup on cyclone for scouring the output MDXX files before they get to
be 10 days old.

It appears to me that the GEMPAK/GEMPAK decoder installation on cyclone
should get updated and the ~ldm/etc/pqact.conf entries that run GEMPAK
decoders updated to use decoders in the current Unidata release.

As I leave cyclone, I am under the impression that things are mostly
working correctly.  The only issues I see are related to the GEMPAK
decoders being run by the LDM.

On to snow...

Tom

>From address@hidden Sat May 24 17:06:30 2003

Tom,

Thanks for all thw work. I know our GEMPAK system needs some updating. 
We have a newer faculty member that uses GEMPAK and I was hoping that he 
would stay on top of this area a bit more. We have a total GEMPAK update 
on our agenda for this summer. My colleague has been able to use 
GEMPAK for his research purposes, but the system is not set up well for 
GARP and NWX. I never was that fond of GEMPAK because of the onerous 
directory tree structure for data and having to dumb it down for 
colors--we also have FX-Net that can do much of what you can do with 
GARP and NWX. Now that some of the color limitation have recently been 
removed, we have more desire to have a better GEMPAK arrangement.

In about a year, we are hoping to have funding for a full-time 
technician. We have so much going on that we really need one.

Jim