>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.