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

19991208: ldm-mcidas Y2K issues (cont.)

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.

  • Subject: 19991208: ldm-mcidas Y2K issues (cont.)
  • Date: Wed, 08 Dec 1999 14:22:15 -0700
>From: McIDAS <address@hidden>
>Organization: McIDAS proyect
>Keywords: 199912030405.VAA02145 ldm-mcidas Y2K

Karli,

re: me taking a look at your setup
>Thank you, that might not have to be necessary at the moment since the
>feeds seems to be working, but then again I've been watching the feeds
>and I just saw NLDN zoom by but it has not yet been reflected on the
>routing table (the feed has been up for less than 15 minutes.)

OK.

re: upgrading ldm-mcidas and McIDAS in lock step
>Ok I have the binaries downloaded, and will upgrade when I get a
>chance.  What do you mean by upgrading them in lock step?

Upgrading in lock step[ means that you should upgrade both of these
packages at the same time.  That way the new ldm-mcidas point source
decoders (like profiler and lightning) will use the new McIDAS SCHEMA
to create their output data files.

The other thing about upgrading is that it is best to finish the
upgrade right after 0Z.  The reason for this is so that new MD files
that are created with ldm-mcidas and McIDAS-XCD files start fresh.
What I mean by this is that the schema for several of the MD files
change with the upgrade.  If the decoder tried to write to an existing
file that was created with an old schema, the writes would fail.  If
the output file does not yet exist, there will be no problem when the
decoders go to write their output.

Tom