[McIDAS #HNQ-544745]: Missing SYSKEY.DAT

Hi Angel,

re:
> Thanks for fixing our McIDAS setup.

No worries.

> I looked at ROUTEPP.LOG and noticed
> that the jobs GE-IR.BAT and GE-VIS.BAT are both failing.

After seeing your note this morning, I logged back in and took a look.
Apparently, the copies of GE-IR.BAT and GE-VIS.BAT in ~mcidas/workdata
are local copies for RSMAS as they should be.  The problem was that
the second line in the files had a typo:

GU REST GRAPHICS 1

The correct line is:

GU REST GRAPHIC 1

This says to restore the GRAPHIC.GRX color table to frame 1.  Since there
is no GRAPHICS.GRX, the command would fail:

BATCH UV 140 108068 201500 1 "GE-VIS.BAT
SF 1
GU REST GRAPHICS
GU: SPECIFIED FILE DOES NOT EXIST - GRAPHICS.GRX
GU: Done

Since the default for McIDAS BATCH files is to exit on any error, the entire
script would stop executing at that point.

I corrected the typo so the invocations should now work.

> I tried
> "route.k REL N1" but when I do a LIST it still shows as suspended.

I looked at this while logged on.  The read/write permissions for ROUTE.SYS
and SYSKEY.TAB were set to 644, and the file was owned by 'ldm', not 'mcidas'.
I changed the read/write permissions on the files and also set the umask
for 'ldm' to be 002 and restarted the LDM (I changed umask and restarted
while on yesterday, not this morning).

After making the read/write change, I RELeased the postprocessing related
to GOES-East/West and topography compositing:

<as 'mcidas'>
cd $MCDATA
metofis-mcidas* route.k REL CI CV CW
S Pd         Description         Range       Last      Received  Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
  CI GOES-E/W IR Composite       80-89       none        none        none     3
  CV GOES-E/W VIS Composite      90-99       none        none        none     3
  CW GOES-E/W H2O Composite      70-79       none        none        none     3
route.k: Done
metofis-mcidas* route.k REL N1 N2 N3 N4 N5 N6 N7 N8
S Pd         Description         Range       Last      Received  Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
  N1 GOES-East IR/TOPO Composi  220-229      none        none        none     3
  N2 GOES-East VIS/TOPO Compos  230-239      none        none        none     3
  N3 GOES-West IR/TOPO Composi  240-249      none        none        none     3
  N4 GOES-West VIS/TOPO Compos  250-259      none        none        none     3
  N5 MDR/TOPO Composite         260-269      none        none        none     3
  N6 Mollweide IR/TOPO Composi  270-279      none        none        none     3
  N7 GOES-E/W IR/TOPO Composit  280-289      none        none        none     3
  N8 GOES-E/W VIS/TOPO Composi  290-299      none        none        none     3
route.k: Done

> I don't know why some imagery is not being scoured,

I believe that I misspoke about scouring.  The following ~ldm/etc/scour.conf
entry will scour the ~ldm/data/gempak tree back to 30 days of data:

~ldm/data/gempak                30      

I got fooled by the large number of days of data being kept on disk (30 days
of Nexrad Level III data for all radars is a LOT of data!).  My experience is
that sites typically keep one to two days of data online, not 30.

By the way, looking through ~ldm/etc/scour.conf, I see a likely reason that
the McIDAS decoding got messed up:

#~ldm/data/mcidasd              3

If this entry was uncommented, then the static files in ~ldm/data/mcidasd would
get deleted (e.g., SCHEMA and SYSKEY.TAB if its read/write permissions were
such that 'mcidas' could not write to it).

The scouring of the McIDAS stuff is correctly being done out of its own
cron-initiated action:

 # McIDAS-XCD scouring
00 19 * * * decoders/mcscour.sh

Another thing I did yesterday that was related to cron-initiated jobs was:

- move the ldm-mcidas.log file from /usr/local/ldm/logs to /ldm/logs
- add a crontb entry to rotate the ldm-mcidas log files:

# Rotate ldm-mcidas log files
00 19 * * * bin/newlog ldm-mcidas.log 4

Back over in the 'mcidas' account I added a file REDIRECTion for ROUTEPP.LOG:

<as 'mcidas'>
cd $MCDATA
redirect.k ADD ROUTEPP.LOG \"/ldm/logs

This will allow scouring of /ldm/logs/ROUTEPP.LOG by the cron-initiated McIDAS
scour script, /ldm/decoders/mcscour.sh

> I'll have to ask
> around on Monday. Some other fellow was messing with the GEMPAK imagery
> and I'm not sure what his intentions were.

It looks like whoever setup/modified the scouring being done by the LDM 'scour'
utility (Pete Pokrandt?  I see his name the 'crontab -l' listing) opted to
set things up to keep 30 days of all data under /ldm/data/gempak.

Looking some more through /ldm/etc/ldmd.conf, I see that someone commented out
the request for NLDN lightning data.  This may be what was desired, or it may
be due to metofis.rsmas.miami.edu not being allowed for the data at SUNY Albany
(the home of the feed machine, striker2.atmos.albany.edu):

metofis-ldm* notifyme -vxl- -f NLDN -o 3600 -h striker2.atmos.albany.edu
Mar 09 16:24:07 notifyme[24490] NOTE: Starting Up: striker2.atmos.albany.edu: 
20080309152407.844 TS_ENDT {{NLDN,  ".*"}}
Mar 09 16:24:07 notifyme[24490] NOTE: LDM-5 desired product-class: 
20080309152407.844 TS_ENDT {{NLDN,  ".*"}}
Mar 09 16:24:07 notifyme[24490] INFO: Resolving striker2.atmos.albany.edu to 
169.226.43.55 took 0.131004 seconds
Mar 09 16:24:08 notifyme[24490] ERROR: NOTIFYME(striker2.atmos.albany.edu): 7: 
Access denied by remote server
Mar 09 16:24:11 notifyme[24490] NOTE: Interrupt
Mar 09 16:24:11 notifyme[24490] NOTE: exiting

If you want to ingest the NLDN data, you will need to send a request to allow
metofis to:

David Knight
address@hidden

If you decide to get the data and have it available in McIDAS, you will need to 
add
a decoding action for the data to /ldm/etc/pqact.gempak.  Here is a 
representative
action:

#########################################################################
#
# NLDN (Vaisala Lightning) section using LDM-McIDAS 'nldn2md' decoder
#
# NOTEs:
#        - obtain 'nldn2md' decoder from binary LDM-McIDAS distribution
#          or build from source
#        - copy 'nldn2md' to ~ldm/decoders
#        - make sure that ~ldm/decoders is in the PATH for 'ldm'
#        - stop and restart the LDM to activate
#
#########################################################################

# NLDN lightning product
NLDN    
^([12][0-9][0-9][0-9]|[0-9][0-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9])
        PIPE    -close 
        nldn2md -vl logs/ldm-mcidas.log
        -d /machine/data/ldm/mcidas 70 NLDN DIALPROD=LD \1\2 \3\400 DEV=CCN

As always with pqact.conf entries, you have to be careful to use tabs where 
needed.

> Thanks again,

No worries.

Last comment as a heads-up:  To make logging on easier, I added my key to the
~mcidas/.ssh/authorized_keys file.  I'll understand completely if you choose to
delete this entry.

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: HNQ-544745
Department: Support McIDAS
Priority: Normal
Status: Closed