20000919: ROUTE PostProcessing setup at Oregon State (cont.)

>From: Wayne Gibson <address@hidden>
>Organization: Oregon State University
>Keywords: 200009142249.e8EMnCb02002 LDM ldm-mcidas batch.k

Wayne,

I am standing in for Mike on this one.

>Bottom line ...
>
>What is the downside of rotating logs by the process of shutting down ldm, 
>rotating logs, and stating up ldm?

The only downsides are:

o it is a more complicated procedure

o every time you stop the LDM, you run the mostly small risk of corrupting
  the queue.  This may happen if/when a person gets antsy about an rpc.ldmd
  not finishing as soons as s/he likes and so kills it (-9). The downside
  of getting a corrupted queue is having to delete it; remake it; and
  then getting the entire hour's worth of data from the upstream feed
  site.

I must say, however, that neither of these is real pressing if one is
not careless.
.
>Another way to look at it is what would I gain by hacking the code and
>building ldm from source code verses hacking the ldmadmin script?

Mike and I chatted about this before lunch.  My slant is that you really
don't want to get into the mode of having to modify source code each
time there is a new release of the LDM.  The change may be simple at
first, but it could grow to be more complex with time.  I am in the
same situation with McIDAS, and it is a real time killer.  So, given
that you have a procedure that works, it is probably best to leave things
alone.

Tom Yoksas