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