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

20001009: McIDAS: MCGUI fails

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20001009: McIDAS: MCGUI fails
  • Date: Mon, 09 Oct 2000 17:03:52 -0600
>From: Erick Lorenz <address@hidden>
>Organization: UC Davis
>Keywords: 200010092026.e99KQR407535 McIDAS-X MCGUI ROUTE

Erick,

>On at least one of my classroom workstations, when I enter MCGUI on the
>command line, the GUI screen appears for an instant then disappears and the
>following message is displayed in the command window.
>
>MCGUI
>Error in startup script:
>       System Key word 1 read failed (-3)
>"mcidas syskey $1"
> (procedure "syskeyLoad" line 5)
>   invoked from within
> (file "/unidata/mcidas/bin/mcgui.k" line 1333)

This is most likely caused from the user's McIDAS-X session not having
a valid REDIRECTion for the copy of SYSKEY.TAB that is located in the
directory where AREA, MDXX, and GRID files get decoded.

>I was afraid at first that this might have something to do with two users
>using the same account on different machines but I am now pretty sure that
>was not the case.

Are you saying that the same account, with the same HOME directory
works differently on two different workstations?  From conversations we
have had previously, I suspect that the user's HOME directory for a
user is local to the machine that they are running on.  Is this not
the case?  If it is the case, I suspect the missing or incorrect
REDIRECT for SYSKEY.TAB.

>McIDAS seems to work on other respects on this machine.

Only the MCGUI and Fkey menus would be affected by this.  McIDAS itself
should keep running with no problems.

>Also is there any way that a product stream could become suspended
>spontaneously:
>
>After last weekend all the AREA files were several days old.  A check of
>ROUTE LIST showed that they were all suspended.  A RELEASE command restored
>the data flow.  I do not remember ever having issued a SUSPEND command.

No, not that I know of.  The only way to change routing table entries
is to run ROUTE or to overwrite the copy of ROUTE.SYS with a file where
the entries were suspended.  Hopefully, the read/write permissions on
ROUTE.SYS and SYSKEY.TAB are such that only the users in 'mcidas' group
can modify them.

>Thank you

Talk to you later...

Tom

>From address@hidden Wed Oct 11 13:45:26 2000
>Subject: Re: 20001009: McIDAS: MCGUI fails 

I finally traced this problem to the lack of a symbolic link in /var in the
offending machine.  

ATM20 is the file server and has /home/data with /mcidas and /xcd.
I mount the disk /home on atm20 as /unidata on each student workstation and
then have a link /var/data --> /unidata/data so that the redirections
/var/data/mcidas and /var/data/xcd will work in mcidas.  Somehow that link
disappeared or was never there although I thought that MCGUI used to work.

Anyway all is well with that machine.  We now have 7 student workstation
running both Windows and Linux which can run McIDAS.  I am still using the
model where there is just one copy of the McIDAS binaries on ATM20.  So far
the class hasn't exercized the system enough to make it break down.

Thanks

Erick Lorenz, UCDavis