20010304: mcidas upgrade at stc- last bits? (cont.)

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 200102202133.f1KLXZL10511 McIDAS NEXRAD display

Alan,

>Well things have gone pretty well, but there appear to be at least a
>couple of snags in upgrading from 7.5 to 7.7
>
>As you know, your restarted build of 7.7 finished ok on Fri.

Right.

>Started with the install and other things this morning
>
>1.  Tested 7.7 as per Web;  OK, no problems
>
>2.  Stopped the ldm (as user ldm)

OK, good.

>3.  Did the rename and deletions you indicated in our output directory
>    (/var/data/mcidas for us) re:  current mand. MD,  SCHEMA (replaced
>    this as directed), and *.RAT, *.RAP files

From the rest of your email, I see that I missed one step:

cd ~mcidas/workdata
cp STRTABLE STRTABLE.BAK

More on this below.

>4.  Exited and relogged in as user mcidas

OK.

>5.  Did a make uninstall.all for  mcidas7.5/src;  did not delete any other
>    7.5 files.

OK.

>6.  Ran the install for 7.7:  initially got an error code 1, which
>    suggested I try a 'make rootdirs';  I did this and then the make
>    install ran ok to completion (not absolutely sure if this happened
>    on the make uninstall or make install, but think it was the
>    latter;  my notes may be written in wrong place).

I don't recall there being additional directories in the 7.7
distribution, but there obviously was.  Do you recall what
directory(ies) were created when you ran 'make rootdirs'?  The
indication that you needed to do a 'make rootdirs' should have occurred
on the 'make install.all' step, not on the 'make uninstall.all' step.

>7.  Started a mcidas session, as user mcidas, and tried MCGUI
>    got an error message about a file called xfmbox.tcl not being found
>    in a listed subdirectory that I cannot recall entirely and did not
>    write down.

This would have indicated that the installation was not complete.  This
module gets installed in the ~mcidas/tcl/lib/tk8.0 directory.

>    I think named path was
>    /home/mcidas/mcidas7.7/tcl/lib/tcl8.0/xfmbox.tcl but am not sure.
>    Anyway, the error message gave a hint as to where this file could
>    be found, (/home/mcidas/tcl/...)  I found it there,  created the
>    necessary subdirectories in ~mcidas/mcidas7.7  and moved a copy of
>    xfmbox.tcl there.

You should not have had to do this, nor should this make any
difference.  The Tcl/Tk library routines, of which xfmbox.tcl is one,
get installed under the ~mcidas/tcl directory, and that is where they
should be found for use by MCGUI.

>    MCGUI  then started ok, but thinking about what I did makes me
>    wonder if the install moved everything where it was supposed to
>    go.

It doesn't seem like it did, but things work now without any additional
modifications; see below.

>    I did not try and create any products using MCGUI or anything
>    using the command line.
>    Guess I was too preoccupied with the above.

OK.

>8.  Your last instructions were to run the following from a McIDAS session:
>
>    BATCH XCD.BAT
>    BATCH XCDDEC.BAT
>
>    The first of these failed; with message STRING NOT FOUND: XCDDATA
>    Batch job abandon

My fault.  What happened is that the copy of STRTABLE in
~mcidas/workdata got overwritten with a new one from the distribution.
The new copy does not have XCDDATA defined in it, so the XCD.BAT
invocation will fail.  The solution _that I failed to include in my
previous email (but which is in the installation instructions)_ is to
save a copy of STRTABLE and then restore the copy after the install
finishes:

cd ~mcidas/workdata
cp STRTABLE STRTABLE.BAK

<do the 'make install.all'>

cd ~mcidas/workdata
cp STRTABLE.BAK STRTABLE

from the Unix command line:

batch.k XCD.BAT
batch.k XCDDEC.BAT

OR from a McIDAS-X session:

BATCH XCD.BAT
BATCH XCDDEC.BAT

My fault; I apologize.

>    The second, XCDDEC.BAT,  ran to completion with no errors.  I saw
>    that it created a bunch of things, but did not see any errors.

XCDDEC.BAT should run to completion since it does not reference
XCDDATA.BAT.  The problem, however, is that XCD.BAT's job is to define
REDIRECTions for a variety of files related to XCD decoding.  This
would be a show stopper for a new installation, but not for an upgrade
since those REDIRECTions should already be defined.

>    Tried the first, BATCH XCD.BAT again, but same problem.  

XCDDATA needs to be defined to be the XCD output directory:

TE XCDDATA "/var/data/mcidas

>9.  I did restart the ldm (as user ldm) and it seemed to run ok.  No errors
>    listed initially in  log file.  Have left it running, and hope our
>    other terminals will be able to get waldo's data, at least for
>    Monday.

I can access data on waldo from my machine here at home, so your other
machines should have no problems doing the same.

>Hope you can tell me what I need to do, or else fix it.  

I will be taking a closer look at the xfmbox.tcl issue above.  Again,
you should not have had to do anything to make the MCGUI work.

<a few minutes later>

I deleted the directory you made: ~mcidas/mcidas7.7/tcl/lib/...  as it
is not needed.  I was able to start the MCGUI with display back to my
machine here, so the directory is really not needed.

I also checked on upper air decoding and see that it is working for
levels higher than 100 mb.  The surface decoding seemed to be not
working after the surface .RAP file was recreated, so I renamed the
current surface MD file, and stopped and restarted the LDM:

<stop LDM>
cd /var/data/mcidas
mv MDXX0003 MDXX0003.BAK
<restart LDM>

Surface decoding seems to be working OK now.

>Thanks  

I will keep an eye on decoding on waldo (through ADDE) and tweek
anything if needed (I don't think that it will).

I would appreciate if you would retry a McIDAS-X session where you run
MCGUI so you can confirm or refute my observation that the creation of
~mcidas/tcl/lib was not needed.

Tom