[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030611: ldm-mcidas fix (cont. from McIDAS discussion)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200208151624.g7FGOlK17761 McIDAS-X ADDE 

Hi Robert,

re: ldm-mcidas source distribution/build to fix routing table update problem

>Go ahead and build it as I do use the McIDAS routing table  The machine
>will remain as is until I get everything working. I still have to do
>the web stuff and scripts and all that stuff.

OK, I built ldm-mcidas v2002b+ on your machine a few minutes ago.  This
version contains the fix for updating the McIDAS routing table,
ROUTE.SYS, day and time of decoded images.  This fix will be rolled
into the next ldm-mcidas release, v2003, and binaries will be made
available for the most popular user platforms.

While at it (you _will_ learn to not give me access ;-), I did the following:

- copied the ldm-mcidas decoders most commonly used from the
  ldm-mcidas-2002b/bin directory to ~ldm/decoders

- removed the ldm-mcidas-2002b/bin directory from 'ldm's PATH

- copied batch.k, uwgrid.sh from ldm-mcidas-2002b/bin to ~ldm/decoders
  and edited them to set PATH and LD_LIBRARY_PATH

- copied ~mcidas/workdata/mcscour.sh to ~ldm/decoders and edited it
  to set PATH, LD_LIBRARY_PATH, and to add scouring of MD files
  for ETA and GFS MOS that will be created by the v2003 XCD decoders.
  I did this to save you the hassle of doing it yourself after the
  Unidata McIDAS v2003 release is made available.

- added running of scouring to the cron file for 'ldm':

  'bin/ldmadmin scour'
  'bin/newlog logs/SERVER.LOG'
  'bin/newlog logs/ldm-mcidas.log'
  'bin/ldmadmin newlog'

   The SERVER.LOG entry is for tracking remote ADDE access to your
   machine.  It will get populated with data if/when you uncomment
   out the ADDE_LOGGING environment variable setting in 

You have this system setup to decode McIDAS-XCD data in
/var/data/mcidas, but you have GEMPAK decoders setup to decode in
/data/ldm/gempak.  Not that there is anything bad about this, but we
tend to setup systems so that McIDAS data gets decoded into
~ldm/data/mcidas and GEMPAK data gets decoded into ~ldm/data/gempak
(which you have now).  Any reason for keeping the old /var/data/mcidas


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.