>From: "Alex Huang" <address@hidden> >Organization: UNCA >Keywords: 200307301533.h6UFXPLd024978 LDM McIDAS upgrade Hi Alex, >Thank you for prompt reply and action. Glad to help... >OK, this is what I want you to help me with, since you are so kind. ;-) > >1. Please upgrade McIDAS in typhoon.atms.unca.edu and lab1.atms.unca.edu >to v2003, Done. >and make sure the student account (user id: atms) will work for both >McIDAS and GEMPAK. I am setting up the McIDAS side. I talked to Chiz, and he is going to setup the GEMPAK side to match his recommended installation. This includes doing the following: - splitting the pqact.conf files into three different sets: pqact.conf - McIDAS, McIDAS-XCD, and non-GEMPAK FILE actions These are very simple and limited in number. pqact.conf.gempak - GEMPAK actions that follow the GEMPAK distribution this will change some output directories which is not a big deal, and it will make upgrading GEMPAK _MUCH_ easier in the future (a good thing) pqact.conf.difax - current DIFAX printing actions: pqact.conf.difax.weekday - DIFAX printing actions - weekday pqact.conf.difax.weekend - DIFAX printing actions - weekend pqact.conf.difax.vacation - DIFAX printing actions - vacation After the split, there will be three separate pqacts running on storm2. - modifying the rotatemaps.csh, weekend_maps.csh, weekday_maps.csh, and vacation_maps.csh The modifications will be to remove the stopping and restarting of the LDM which is not needed to accomplish the switch in DIFAX printing schedules. Instead, the appropriate pqact.conf.difax.* file will be copied to pqact.conf.difax and a HUP signal will be sent to the pqacts telling them to reread their configuration files. -- It is much better to not stop and restart the LDM if you don't have to. >2. Yes, I want GEMPAK only holds 2 days of model data. OK. After the Chiz changes the directory strucure for GEMPAK data output tomorrow, we will adjust the scouring to keep 2 days of model data in GEMPAK format. This should free up a good bit of room for you. >I know the model >data are there, but I couldn't access those model output in GEMPAK, as you >said, the connection may not be right. This is the main reason that Chiz wants to change where things are being decoded and filed for GEMPAK. The structure in use now does not match what is expected by a generic GEMPAK installation. He will change it so that it does match, thus making future upgrades much easier. >So please check it out for me, thanks. Will do. >3. What kind of back-up device or procedure we need to have? So far we >have none for storm2.atms.unca.edu, :-((. The backup procedure you use depends on your backup objectives. A lot of sites consider that data is transitory, so they don't bother to backup the data directories. Other sites want to archive data, so they go to great lengths to backup the raw and decoded data. Most sites should institute a backup plan that saves the directories where software is installed. This is typically done fully once every week or two, and incrementally every night. Folks that are doing this typically use high density tape systems like DAT. >Oh, I got to go to teach now, thank you so much once again, and have a nice >day. I will write back to you when the work is finished. This will be sometime tomorrow. 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.