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