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: mynul khan <address@hidden> >Organization: St. Cloud State >Keywords: 200409201503.i8KF3KnJ029837 McIDAS user Mynul, >As far as I understand mcidas has been installed >perfecly because we have been using mcidas for last >one month. OK. >I followed your instructions except >reinstalling mcidas. I am glad that you didn't reinstall, because that is definitely not needed. >I would appreciate if you could >take a look in the new account and the "student" >account from which you will be able to use mcidas >without any problem. I am able to get onto meteor as 'mcidas', but I don't have the necessary password to become 'student'. I also don't know the name of the new account you created, but I suspect that it is 'tonyh'. Is this correct? A quick look at the setup in the 'tonyh' account does not show anything amiss. Listing ~tonyh/mcidas/data/MCTABLE.TXT shows that you have correctly set this account to use the remote ADDE server on meteor. Furthermore, the ADDE datasets are setup correctly in the 'mcidas' account and access to them through the remote server seems to work with no problems as 'mcidas'. So, the only guess that I have at the moment is that the PATH for the user 'tonyh' does not include the /bin directory. If this is the case, it will not be able to find the 'compress' and 'uncompress' utilities that are needed for ADDE transfers when the environment variable MCCOMPRESS is set to TRUE as it is in ~tonyh/.cshrc: # C-shell environment variable definitions for a general user # MCHOME - the HOME directory of the user 'mcidas' setenv MCHOME /home/mcidas # NOTE: conditional definition is needed for C-shell users if ( ! ${?MCPATH} ) then setenv MCDATA $HOME/mcidas/data setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help setenv MCGUI $MCHOME/bin setenv MCTABLE_READ "$MCDATA/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT" setenv MCTABLE_WRITE "$MCDATA/MCTABLE.TXT" if ( ! ${?path} ) then set path=$MCGUI else set path=(${MCGUI} $path) endif endif # Limit ADDE transfers to compressed ones setenv MCCOMPRESS TRUE source /home/gempak/GEMPAK5.7.2p2/Gemenviron If you can logon as 'tonyh' and see if you can find 'compress': <as 'tonyh'> which compress it will tell us alot. If which fails, the fix can be either of the following two options: - add /bin to the PATH of 'tonyh' - edit ~tonyh/.cshrc and change: setenv MCCOMPRESS TRUE to setenv MCCOMPRESS GZIP The reason for the second change is that 'gzip' and 'gunzip' are now built as part of McIDAS, so they can always be used. The other reason to make the change -- probably for all of your McIDAS users -- is that the default port for the GZIP option is 112, and the intention is to move away from use of ports 500 and 503 to 112 only. If modifying PATH or changing MCCOMPRESS for the new user (again I am assuming that this is 'tonyh') doesn't work, I will need to dig deeper to find out why the account is not able to access data through the remote ADDE server on meteor. Can I get the password so I can see what the indications are when trying to access data? >Thanks No worries. Cheers, 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.