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

20010831: McIDAS 7.8 Upgrade (cont.)



>From: "Patrick O'Reilly" <address@hidden>
>Organization: UNI
>Keywords: 200108271516.f7RFGA116922 McIDAS-X 7.8 upgrade

Patrick,

>The upgrade instructions were great, didn't have XCD installed, so not sure
>about those.

If you are not decoding data gathered through the Unidata IDD, then you
don't need XCD installed.  If you are ingesting data with the IDD, then
you probably do want to setup XCD on one machine.  The machine to set
it up on would be the one that the LDM is running on.  After getting
XCD decoding working, you would also setup the ADDE remote server on
the same machine so that all other machines in your department could
get the data from it via ADDE.

>A couple strange things though...

Now, why couldn't your message end with the first comment :-(

>Have done the upgrade on 4 machines so far and only one gets meteograms and
>thermo diagrams.  The other three give this error:
>
>Error: system key word 2003 read failed (-3)

I was going to tell you that you shoudl not be seeing this with the
latest version of MCGUI, but I just looked at the code and see that
there are a couple of lines still in the svcaMeteorogram procedure
that _incorrectly_ access the system key table, SYSKEY.TAB.  What this
means is that the McIDAS sessions that you were trying to run the MCGUI
from have an incorrect REDIRECTion for the file SYSKEY.TAB.  Check this
by running the following from those sessions:

DMAP SYSKEY.TAB

I am betting that your listing will not show the existence of this file.
That listing would look something like:

DMAP SYSKEY.TAB

PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
0 bytes in 0 files

If you get a listing like this, you can do either of two things:

o locate the correct copy of SYSKEY.TAB and setup a valid REDIRECTion
  for it

o delete the REDIRECTion for SYSKEY.TAB and let the copy sent out with
  the McIDAS distribution be used

I suggest the latter course of action.  To delete the REDIRECTion for
SYSKEY.TAB, run the following from the sessions having problems:

REDIRECT DEL SYSKEY.TAB

Fixing the finding of SYSKEY.TAB will also cure the problem you are
seeing while trying to plot thermodynamic diagrams.

>I have attached the error log for both meteograms and thermodynamic
>diagrams.  Not sure why one machine works and the rest get errors.

OK, I will comment if necessary after the error log listing below.

>Also, one machine gave me an error after building the executables:
>
>make:warning: Clock skew detected.  Your build may be incomplete.

This is a comment from make.  The way make works is that it compares
the time stamp on an object file with the time stamp on the source for
that module.  If the time on the source is newer than the object file,
the object file is remade.  If it is older, it is not.  'make' is
telling you that your system clock time was adjusted wile the build was
proceeding.  The best course of action in this case is to:

<login as 'mcidas'>
cd mcidas7.8/src
make clobber
make mcx
make install.mcx

If, for some reason, the time stamp on the source files in
~mcidas/mcidas7.8/src are in the future (your clock was really wacked
at one point), then the rebuild above will still not work the way it
should.  In this case, I would reextract all of the source from the
original distribution compressed tar file, mcidasx780.tar.Z.

>Apparently it is.  I get satellite data fine, but all other types plot May
>31 2001, not August 31 2001, even when explicitly specified.

So, your system clock is really out of whack.  Before doing anything, you
need to set it to the correct time.

>Of course no
>data shows up for May 31.  Hope you're familiar with these errors, couldn't
>find anything searching e-mail archives.

The syskey message is a McIDAS thing.  The time skew message has nothing
to do with McIDAS per se; it is directly caused by your system clock
being off.

The installation instructions for the LDM have information on running
xntp on machines.  xntp is used to go out on the net; get the correct
time; and then set the time on the local machine.  You should look into
doing this since so much of meteorological data analysis is dependent
on knowing what the current time is.

>Thank you again for all your help....

You are welcome.  

>From address@hidden Fri Aug 31 10:44:19 2001
>Subject: Missing attached files
>
>If my head weren't screwed on.....

No problem...

>ystem key word 2003 read failed (-3)
>    while executing
>"mcidas syskey get 2003"
>    (procedure "svcaMeteorogram" line 27)
>    invoked from within
>"svcaMeteorogram"
>    invoked from within
>".menus.disp.mnu.obser invoke active"
>    ("uplevel" body line 1)
>    invoked from within
>"uplevel #0 [list $w invoke active]"
>    (procedure "tkMenuInvoke" line 29)
>    invoked from within
>"tkMenuInvoke .menus.disp.mnu.obser 1"
>    (command bound to event)

I am glad you included this output.  It helped me find the two lines
in the svcaMeteorogram procedure (contained in upcguiprocs.tcl) that
were inadvertantly left in.  I will remove the lines from the file
in the next addendum for McIDAS.  For now, the fixing of the REDIRECTion
for SYSKEY.TAB as I outlined above will get you going.

>ystem key word 2011 read failed (-3)
>    while executing
>"mcidas syskey get 2011"
>    (procedure "thermoDiagram" line 32)
>    invoked from within
>"thermoDiagram"
>    invoked from within
>".menus.disp.mnu.obser invoke active"
>    ("uplevel" body line 1)
>    invoked from within
>"uplevel #0 [list $w invoke active]"
>    (procedure "tkMenuInvoke" line 29)
>    invoked from within
>"tkMenuInvoke .menus.disp.mnu.obser 1"
>    (command bound to event)

There was one line inadvertantly left in the thermoDiagram procedure.
It will be removed with the next addendum as well.  Again, fixing the
REDIRECTion for SYSKEY.TAB will cure this problem also.

Please get back to me to verify (or refute) that changing the
SYSKEY.TAB REDIRECTion fixes the meteorogram and thermodynamic diagram
problems you note above.

Tom


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.