This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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