[McIDAS #XRR-599672]: Configuring scouring of McIDAS data

Hi Samuel,

re:
> Wow, thanks for your help.  I thought I looked over everything, twice.
> It just goes to show that you don't notice something missing, if you're
> convinced it's there.

Been there; done that :-)

> I didn't look at the ldmd.conf file close enough.
> 
> I assumed mcxconfig set up the ldmd.conf automatically.  Now I feel silly.

No need to fill silly.   It is very often the case that it becomes impossible
to see something after looking at the problem too long.

> I think that might have been the missing step in the mcxconfig procedure 
> though 
> (http://www.unidata.ucar.edu/software/mcidas/current/users_guide/upc_configuremcidas.html)

Something you said in an email yesterday:

  "I know I ran mcxconfig. Several times in fact."

leads me to believe that the first time you ran mcxconfig, you did not specify
that you wanted to process model data.  This invocation would likely have
created the ~ldm/etc/ldmd.conf entries that I found yesterday afternoon.
A subsequent run of mcxconfig where you did specify that you wanted to process
model data resulted in new, updated ldmd.conf entries that were not used
in replacement to the original ones even though the newly created pqact.conf
files, pqact.conf_mcidasA and pqact.conf_mcidasB, were.  This scenario would
explain the missing reference to HRS (and/or NGRID) in ldmd.conf actions.

re: scouring
> I realize that the scouring needs to be setup.  My goal was to first get the
> drives filling.  We have a bit more storage on this machine, and I want to
> utilize it as quickly as possible.

I just wanted to make sure to point out that it is a step that needs to be
addressed in the next couple of days (before the set of MDXX files reaches
10 for each type of data).

> Again, you were right.  That was an oversight by my part, not setting the
> hostname.  Now that shu1 has it's hostname setup, ADDE works great.

Excellent!

> Thanks again for your help, I must have been having a bad day (or a few).

No worries.  Again, I've been through the "can's see the forest for the trees"
scenario many, many times.  All it usually takes is someone looking over one's
shoulder to do a reset.

re:
> I guess I should also mention that I had to copy the RESOLV.SRV to the 
> PUBLIC.SRV
> file in $MCDATA, but thanks again for the help.  Have a good weekend.

One thing in regards to PUBLIC.SRV:

PUBLIC.SRV was created for the IDV use of the ADDE remote server capability.
The idea is to copy RESOLV.SRV to PUBLIC.SRV (which you did), AND to delete
any datasets listed in PUBLIC.SRV that you do not want exposed to remote
users (e.g., test datasets, etc.).

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