20020802: RAOBCON OUT=SAVE does not write day or level to GRID header (cont.)

>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200207311741.g6VHfM921120 McIDAS-X 7.8 RAOBCON PTCON

Bill,

>As I upgrade scripts to 7.8, my code that creates grids of
>THAE are still using UCC. UCC does what I want. So I am safe
>as long as UCC is available, however, I recall that UCC is
>scheduled to be sunset in 7.9  . 
>And, I don't know if it is in 2002?
>What is the status of UCC ?

Two things here:

1) SSEC changed the version numbering scheme.  What was going to be
   v7.9 is now v2002.  All releasees from here on out will be
   named using the year of release and a single letter (e.g., 'a', 
   'b', etc.) indicating an addendum.  The current release is
   v2002 and the first addendum will be v2002a.

2) UC, UCC, etc. (the MDX macros) are not built in Unidata McIDAS
   v2002.  The code, however, is still in the distribution so that
   folks that really need the executables will still have them.
   Also, the install for v2002 does not remove any of those executables
   (e.g., uc.k, ucc.k, etc.) from the installation 'bin' directory.
   So, users that are upgrading from v7.x will still have the v7.x
   executables available (along with .hlp files in ~mcidas/help).
   Folks doing brand new installations will not have the executables
   since they won't exist in the 'bin' directory.  The can, however,
   build and install those executables by running 'make sunset' and 
   then 'make install.sunset' during the build process.

One last thing, I took a look at the code in PTCON that sets up the
header information for gridded data that will be put in the output
GRID file, and I think I understand what is going on.  "Simple"
gridded fields, those from primary variables, do get all information
put into output GRID files.  You can verify this by running RAOBCON
for things like Z, T, etc.  "Complex" variables, those calculated
from primary variables do not get their grid headers correctly filled
out.  The test that prevents this from happening will have to be
refined to only exclude those derived parameters for which a level
doesn't make sense (like the difference between two levels).

I will work on trying to fix the problem after the end of my workshop.

Tom