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

19990914: problems bringing up McIDAS-X

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: 19990914: problems bringing up McIDAS-X
  • Date: Tue, 14 Sep 1999 13:32:27 -0600
>From: Jim Heimbach <address@hidden>
>Organization: UNCA
>Keywords: 199909141652.KAA04088 McIDAS

Jim,

>     Mcidas is running as a user called uncamcid on our server, an ULTRA-2
>running under SOLARIS 5.7.

Do you mean installed under the user account 'uncamcid' on the server?
Does McIDAS run from this account?

>Yeah yeah, I know, I don't have XCD running yet,
>but that will come later.

OK.

>The server's name is vortex.  There is a 
>SPARCstation 5 also under SOLARIS 5.7 called tornado.  Tornado is nfs'ed
>to vortex's /home and /data where the mcidas data are stashed:

OK.

>When I first tried to run McIDAS on tornado, I got a message.
>
>          X connection to vortex:0.0 broken ...

Wait.  You are running on tornado.  Your display should be set to tornado,
not vortex.

>I took care of that using the following added to /home/uncamcid/.cshrc
>
>          switch('uname -n')
>          case "vortex.*":
>               setenv DISPLAY vortex:0
>               breaksw
>          case "tornado.*":
>               setenv DISPLAY tornado:0
>               breaksw
>          endsw 
>
>Kindof brute force, but it got the job done.

OK, so now you have the DISPLAY set to the local machine.  What user
is running X Windows on this machine?  What I mean by this is who
logged on and started X.  If that user was not the one that is trying
to bring up the McIDAS-X session, then it is possible that you may
need to enable displays to the screen using xhost.  For instance, as
the user that brought up X, you would have to run:

xhost +tornado

I routinely run into this on my system.  I bring up X as my self (i.e.
the user 'yoksas') and then do something like 'rlogin gale -l mcidas'
or 'su - mcidas'.  In order for the user 'mcidas' to start X stuff
(like an xterm or McIDAS), I would have had to do an:

xhost +gale

as the user 'yoksas' when I started X.  Do you see what I mean?


>     Then when I started up, The CRT just stared at me without having
>the usual small initializing window with the mesmerizing red bug pacing
>back and forth.  Doing a ps shows the expected;
>
>     ps -Af | grep mcidas   
>     uncamcid  1046     1  0 12:33:14 pts/3    0:00 /bin/sh /home/mcidas/bin/m
> cidasx
>     uncamcid  1071   969  0 12:40:20 pts/3    0:00 grep mcidas 

I am betting that the machine is denying access to X.  Running the xhost
command by the user that started X should fix that.

>     Below are uncamcid's MC's
>
>          if (! ${?MCPATH}) then
>          setenv MCDATA ${HOME}/mcidas/data
>          setenv MCPATH ${MCDATA}:/home/mcidas/data:/home/mcidas/help
>          setenv MCGUI /home/mcidas/bin
>          setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;/home/mcidas/data/ADDESIT
> E.TXT"
>          setenv MCTABLE_WRITE "${MCDATA}/MCTABLE.TXT"
>          endif

These look correct AND should have nothing to do with your problem.

>The above seems to be working as advertised:
>
>          echo $MCPATH
>          /home/uncamcid/mcidas/data:/home/mcidas/data:/home/mcidas/help
>
>     Any ideas?  Thanks -- Jim H.

Try the xhost command and let me know what happens.

Tom