>From: "Alex Huang" <address@hidden> >Organization: UNCA >Keywords: 200307301533.h6UFXPLd024978 LDM McIDAS upgrade Hi Alex, >Wow, you are a genius or what, :-)), That should be a ;-) (wink). >thank you so much for helping us out and letting me know what was done. I'm glad to help. >I think you did a solid job for us, but I have a few more wishes as follows: Ready... >1. I setup a student account >for students to use GEMPAK; and another account of >to use mcidas. Both are working, so I don't think >you need to do anything, thank you. OK. Please let me know if you would like me to look in on these. By the way, is McIDAS installed and run from other machines? If yes, I think that those machines should be upgraded to v2003 to match storm2. Please let me know if you would like me to do this. >2. Can you make storm2.atms.unca.edu receive and decode Model data and >only archive for the recent TWO days? I just did this for McIDAS. Do you want me to change the setup for GEMPAK? >Matt Rosier tried to play with the >model data in GEMPAK, and I am not sure it is done right. I see 7 days worth of *.gem model files on storm2, so it looks like Matt has that setup correctly. Can the data be accessed from GEMPAK? If not, the problem is most likely a simple one of where the data is being output. Please let me know if you are wanting me to setup storm2 to decode and keep 2 days of GEMPAK-decoded model data. re: modifying the LDM boot time startup script to check the LDM queue integrity before starting, because the queue can get corrupted >3. Actually it happened once (I think), I got the error like "p?q.id exits, >etc.." while booting, so I deleted that file, and rebooted the machine, and >it started to work again. (Lucky me). What happened in your case was the machine crashed/was stopped and the LDM was not shutdown properly. The LDM creates a file ~ldm/ldmd.pid that contains the process ID of the lead rpc.ldmd. The LDM startup procedure checks to see if this file exists, and, if it does, it complains that things were not shutdown properly. The fact that things started OK for you means that the LDM queue was not damaged by the reboot. >Do you want to make it dummy (that's me)-proof for the future? Thanks. OK. I will update the startup script to be a little smarter: - cleanup after an improper stop: ldmadmin clean - check for a viable queue: pqcat -s > /dev/null - delete and remake the queue _if_ it was damaged ldmadmin delqueue ldmadmin mkqueue - restart ldmadmin start re: cron jobs that produce different maps >4. I agree that cron jobs need to be placed in a permanent directory, I >think I can ask Bob Benites to do it, but if you have 10 minutes, can you do >it for me? Done. I put the C shell scripts in the ~ldm/util directory. I also added this directory to the PATH for 'ldm' (in .cshrc), and added /home/ldm/util to the PATH sepecification in the contab file. >Will /ldm/util be a good place for it? Yes, absolutely. This is exactly what the util directory is good for. >Do you think it may >loose the link if it is moved to other directory? No, I think everything will be OK. >5. I think I am done with my wishes for now, thank you again. I really >appreciate it. No worries. >Have a virtual beer until we meet again. :0)) Since you are (virtually) offering, I'll have two ;-) Tom
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.