20030828: LDM-6 and McIDAS installations at UNCA (cont.)

>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