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

19990921: McIDAS-X installation at DU (cont.)

>From: Michael Keables <address@hidden>
>Organization: DU
>Keywords: 199909152035.OAA16060 LDM ldm-mcidas

Mike,

>First, thanks so much for the work you did on cyclone. I really appreciate
>your help.

You are welcome.

>I'm trying to establish a user account on cyclone. As the user I've done
>the following:
>
>1.  edited .cshrc
>
>> cat .cshrc
># @(#)cshrc 1.11 89/11/29 SMI
>umask 022
>set path=(/bin /usr/bin /usr/ucb /etc .)
>set path=(/usr/dt/bin /usr/X/bin $path)
>set path=(/opt/NSCPcom $path)
>set path=(/usr/proc/bin $path)
>set path=(/usr/ccs/bin $path)
>set path=(/opt/SUNWspro/bin $path)
>set path=(/usr/local/bin /usr/local/sbin $path)

Where is $MCGUI in your PATH?  Without it, you will never "see" the
McIDAS executables.  I think that you need to define the McIDAS
environment variables at the top of your .cshrc file and put the PATH
(path) definitions after them AND include $MCGUI in your PATH.

>setenv MANPATH /usr/local/man:$MANPATH    # sufreeware.com stuff

If this user will do McIDAS development, I would add
/export/home/mcidas/man.  Also, is MANPATH defined at this point?  If
not, then the reading of .cshrc will stop at this line.

>if ( $?prompt ) then
>        set history=32
>endif
>if ( ! ${?MCPATH} ) then
>setenv MCDATA ${HOME}/mcidas/data
>setenv MCPATH ${MCDATA}:/export/home/mcidas/data:/export/home/mcidas/help
>setenv MCGUI /export/home/mcidas/bin
>setenv MCTABLE_READ
>"${MCDATA}/MCTABLE.TXT;/export/home/mcidas/data/ADDESITE.TXT"

I assume that this line is not split into two in the user's .cshrc file.

>setenv MCTABLE_WRITE "${MCDATA}/MCTABLE.TXT"
>endif

Looks good to me, but these definitions should be before you define PATH
(path).

>2. edited the dtwmrc file to allow McIDAS to use the AltF6 key.

OK.  By the way, if you setup your X windows to be something other
than 8-bit (this would be done from the command line login as root
by the routine kdmconfig), you will need to reconfigure the system
to be 8-bit (the Fkey menu doesn't run in 24 bit mode; neither
does GEMPAK).

>3. created $HOME/mcidas/data
>
>4. executed userdata to copy the four required files.
>
>> ~mcidas/admin/userdata ~mcidas/mcidas7.6/data ~/mcidas/data
> 
>Copying files from /export/home/mcidas/mcidas7.6/data to
>/export/home/mkeables/mcidas/data...
> 
>Copying /export/home/mcidas/mcidas7.6/data/STRTABLE to
>/export/home/mkeables/mcidas/data/STRTABLE
>Copying /export/home/mcidas/mcidas7.6/data/UNIMENU.DEF to
>/export/home/mkeables/mcidas/data/UNIMENU.DEF
>Copying /export/home/mcidas/mcidas7.6/data/VIRT9300 to
>/export/home/mkeables/mcidas/data/VIRT9300
> 
>Done!

Very good.  Now all that remains to be done for the user is:

o define file REDIRECTions
o define locations of your ADDE remote server

>I'm ready to define the data file access, but am having permission
>problems starting McIDAS under the new account:
>
>> mcidas
>mcidas: Permission denied.

the execute permission on mcidas and mcidasx (run by mcidas)
are set to 775, this doesn't make sense.  The only thing I can think
of is that perhaps you didn't 'source .cshrc' after setting the MCDATA,
MCPATH, etc. environment variables?

>I've checked the permissions set on /export/home and /export/home/mcidas
>and both show the directory and the executable are group executable:

They are user, group, and world readable and executable, but only user and
group writable.

>What do I need to do to fix the problem?

I just logged on as you (first as 'mcidas', then a 'su -' to 'root' and
then an 'su -' to mkeables.  The initial message I got was:

# su - mkeables
Sun Microsystems Inc.   SunOS 5.7       Generic October 1998
MANPATH: Undefined variable.

This is coming from your MANPATH definition line:

setenv MANPATH /usr/local/man:$MANPATH    # sufreeware.com stuff

The sourcing of .cshrc is ending at this point, so the MCDATA, MCPATH,
MCGUI, etc. environment variables are not getting defined.  This is
demonstrated by:

> env
HOME=/export/home/mkeables
PATH=/usr/local/bin:/usr/local/sbin:/opt/SUNWspro/bin:/usr/ccs/bin:/usr/proc/bin:/opt/NSCPcom:/usr/dt/bin:/usr/X/bin:/bin:/usr/bin:/usr/ucb:/etc:.
LOGNAME=mkeables
HZ=100
TZ=US/Mountain
TERM=xterm
SHELL=/usr/local/bin/tcsh
HOSTTYPE=sun4
VENDOR=sun
OSTYPE=solaris
MACHTYPE=sparc
SHLVL=1
PWD=/export/home/mkeables
USER=mkeables
GROUP=staff
HOST=cyclone
REMOTEHOST=gale.unidata.ucar.edu

I took the liberty of editing your .cshrc file and changing the order
of the McIDAS defines (put at the top); fixing the MANPATH line; and
adding $MCGUI to the end of your path definitions.  I can then start a
McIDAS-X session (your ~/.mcidasrc file was created for you when I ran
'mcidas').

I ran into a problem with vi creating a file in /var/tmp when doing
things as you.  I chatted with Mike Schmidt, our system administrator,
about what could be causing the problem, but we both came up blank.  Do
you have problems editing files?  Do you use vi?

>Also, I haven't been receiving any data since Sunday. I've killed all ldm
>processes but when I try to restart the ldm using 
>ldmadmin start & 

I logged in as 'ldm' and did:

ldmadmin stop              (the proper way to stop the LDM)
<wait until all LDM processes exit>
ldmadmin start

The LDM came up running, but was not logging to ~ldm/etc/ldmd.log.
This happens occasionally on Sun Solaris systems.  It appears to be a
bug in Sun's syslogd daemon.  As 'root' I killed and then restarted
syslogd.

Then as 'ldm' I stopped and restarted the LDM and verified that logging
was proceeding normally and that data was flowing from your upstream
site, cirrus.al.noaa.gov.

>I get an error message that there is already a server running. 
>
>Suggestions? 

This may have been due to you trying to kill individual LDM processes.
Even if you get all of the routines, you will still have a lock file
left in /tmp and a 'pid' file in ~ldm.  Again, the proper way to stop
and restart the LDM is what I did above.

>Mega-thanks in advance.

So, now what you need to do is to define the REDIRECTions for your
account.  This is done by:

o starting a McIDAS-X session
o running:

  REDIRECT REST LOCAL.NAM

LOCAL.NAM is a file that should have been created by whoever installed
McIDAS-X.  It is a copy of the file ~mcidas/data/EXAMPLE.NAM (also put
in the ~mcidas/data directory) that has been edited so that the
directories listed match your McIDAS-XCD and ldm-mcidas output directories.

Let me know if you have any further problems setting up McIDAS for users.

Tom