[LDM #FGZ-978731]: LDM installation and configuration at USNA

Hi Alex,

Another quick, but important comment:

The more I thought about the code in the ~ldm/etc/TDS/util/ldmfile.sh
that sets the default log file, the more I realized that this might
have been the problem with NIMAGE product processing.  The reason is
that the logic in ldmfile.sh checks the parameters passed to it, and
will use the second passed parameter as the name of the log file to
write to.  If the name of the log file to write log messages to is
not provided, then it sets the default log file to be ~ldm/logs/ldmd.log.
The problem in this case is that your log files directory is ~ldm/var/logs,
not ~ldm/logs, and it is most likely that ~ldm/logs does not exist, and
ldmfile.sh does not try to create this directory.  When log output is
to be written, there will be an error generated, and ldmfile.sh will
exit.  All of this happens before the NIMAGE product is written to
disk, so the effect will be that no data file will show up in the
expected output directory, and an error log message will be written
to the LDM log file.

So, please make the change to ~ldm/etc/TDS/util/ldmfile.sh that I
sent in my last email as soon as you have time:

In ~ldm/etc/TDS/util/ldmfile.sh change:

# Send all messages to the log file
if [ $# -eq 2 ]; then
   logfile=$2
else
   logfile=logs/ldm-mcidas.log
fi

to:

# Send all messages to the log file
if [ $# -eq 2 ]; then
   logfile=$2
else
   logfile=var/logs/ldm-mcidas.log
fi

The change is to preprend 'var' logs/ldm-mcidas.log.

Again, nothing will need to be done for this change to
take effect, and after the receipt of a new NIMAGE product,
the ldm-mcidas.log file should show up in the ~ldm/var/logs
directory and the newly received product should be written
to a subdirectory of /data/ldm/pub/native/satellite.

If the NIMAGE processing is working correctly after the above
change, then the next thing I would do is to switch back to
use of LDM-6.13.4 and see if it continues to work there.  This
test would be done _before_ rebuilding the LDM after making
sure that the LDMHOME environment variable is defined in
the environment in which the LDM is built.  If the rebuild
has already been done, no worries as setting the environment
variable is the correct thing to do anyway.

Last comment:

If the above tests result in a working LDM-6.13.4 distribution,
the next step will be to investigate why the other decoding
actions were failing.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: FGZ-978731
Department: Support IDD
Priority: Normal
Status: Closed
===================
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.