19991101: Technical issues w/ McGUI

>From: Catarino David Delgado <address@hidden>
>Organization: University of Wisconsin - Whitewater
>Keywords: 199911012244.PAA19102 McIDAS-X MCGUI

David,

>here at UW-Whitewater, we continue to wrestle slowly with McIDAS and we
>believe we have a version that's working...

Sounds promising.

>Now there are a couple issues that I would like to address. One of which
>is that it is unclear to me whether we need to install McIDAS-XCD or
>not. Again, we have a "dedicated" server for processing datastream
>content.

XCD needs to be installed on the machine that is doing data ingestion
only.  It does not need to be installed on each machine that will run
McIDAS-X.

>What is also unclear is where in the Users guide for Mc 7.60, MCGUi
>information is. (c: 

This is an easy one: there is no User's Guide section for MCGUI :-(

>And now onto a different subject:
>
>The desire for getting McGUI working was what brings all of this up.
>When I try to run mcGUI at the Mcidas command window, the interface
>starts but proptly crashes and returns an error in the mcgui.k file at
>line 1335. After looking at the script, The problem seems to be that
>MCIDAS can not find the UNIMENU.DEF file inside of the ~/mcidas/data
>file.

UNIMENU.DEF should be installed in ~mcidas/data.  If it is not there,
then there has been some sort of installation problem.  You can
force the issue by:

<login as mcidas>
cd mcidas7.6/data
ln UNIMENU.DEF ~/data

The next thing you should do is to start a regular McIDAS session
as the user running into problems and:

o remove the REDIRECTion for UNIMENU.DEF if it exists:

  REDIRECT DEL UNIMENU.DEF

o see if you can see UNIMENU.DEF now:

  DMAP UNIMENU.DEF

  If you can, you should be ready to go.

o while you are at it, you can restore the UNIMENU.DEF values to the
  McIDAS string table, but this is not necessary in the latest version
  of MCGUI:

  TENTER "UNIMENU.DEF

The problem you were probably running into was the existence of a REDIRECTion
for UNIMENU.DEF which pointed to the current directory ('.').  This
is the way that things used to be done, so it is not surprising that
the REDIRECTion might exist.

>(I checked to make sure the file was indeed there, had something
>inside of it etc..., the account is wxuser so ~ is /home/wxuser.)

OK, so you don't have to do the link step above.  This tell sme that the
problem is almost 100% for sure caused by the REDIRECTion.

>The script looks logical so that implies that the paths are wrong. 

Not really.

>Please find attached the .cshrc file and the make log for the
>installation. I feel like I am thrusting you into oblivian so if you
>have any questions about the installation, ask and I will be happy to
>tell you what I can. 

If McIDAS runs, then there is most likely no problem that would require
me to look at 'makelog' or .cshrc, but I will note if I see anything 
amiss below.

>>From address@hidden  Mon Nov  1 15:49:50 1999
>
>Please note: 
>
>in reguard to the last message sent to support by me, the error message 
>returned at the mcidas console is as follows
>
>> MCGUI
>Error in startup script: system key word 1 read failed (-3)
>    while executing
>"mcidas syskey get $i"
>    (procedure "syskeyLoad" line 5)
>    invoked from within
>"syskeyLoad"
>    (file"/home/mcidas/bin/mcgui.k" line 1335)

The other thing that you should make sure of is that the user has a
REDIRECTion to the copy of SYSKEY.TAB that should be being updated by
decoders.  Again, the DMAP command will be of most help:

DMAP SYSKEY.TAB

If there is not a valid REDIRECTion to SYSKEY.TAB, you must add one:

REDIRECT ADD SYSKEY.TAB "<fully qualified directory location for SYSKEY.TAB>

The current MCGUI relies on information in SYSKEY.TAB for access to current
data.  In an upcoming update to MCGUI (the ADDEized version), this
need to read SYSKEY.TAB will disappear.

Your .cshrc file looks corect for the user 'mcidas'.  Again, I suspect that
your problem related to one or two REDIRECTions.

Tom Yoksas