[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010119: McIDAS-X and the EU command (cont.)
- Subject: 20010119: McIDAS-X and the EU command (cont.)
- Date: Fri, 19 Jan 2001 09:46:27 -0700
>From: David Ovens <address@hidden>
>Organization: University of Washington
>Keywords: 200101161857.f0GIvXe05081 McIDAS-X EU
Dave,
>After removing all of the bad files in ~ovens/mcidas/data/, I am now
>left with only this:
>
>PERM SIZE LAST CHANGED FILENAME DIRECTORY
>---- --------- ------------ ------------- ---------
>-r-- 1286 Jun 08 2000 FRAME.PROG /home/disk/ldm/mcidas/data
>-r-- 1981 May 30 2000 FRAMECUR.PROG /home/disk/ldm/mcidas/data
>-rw- 1 Jan 19 00:31 FRAMED /home/disk/blizzard2/ovens/.mctmp/96
> 03
>-r-- 55488 Jan 19 00:28 FRAMENH.001 /home/disk/data/mcidas
>58756 bytes in 4 files
>
>It appears to me, from what you mention above that the
>/home/disk/data/mcidas/FRAMENH.001 file is a problem, and it is brand
>new!
Yes, it is a problem, but it may not be brand new. The reason I say this is
that the DMAP listing will show the first file name when there are multiples
unless you tell it otherwise (by including FORM=ALL). Your previous listing
had a copy of FRAMENH.001 in your McIDAS working directory so that copy
was listed.
A couple of comments on the listing above:
o the files *.PROG are used by the Unidata MCGUI and Fkey menu interfaces
to McIDAS. They are included in the distribution and will get updated
each time the distribution is updated
o FRAMED is located in the correct directory: a directory that is created
on-the-fly by the McIDAS startup process. All files created in
subdirectories of ~/.mctmp are needed for the individual session. They
are deleted along with the directory they are in when one properly
EXITs McIDAS (i.e., types EXIT in the McIDAS command window or uses
the EXIT action in the File section of MCGUI).
o files that end in .0x (e.g., .001, etc) should never be created in any
directory other than a subdirectory of ~/.mctmp. One problem that many
folks have run into over the years is a situation where the user
'mcidas' has some sort of an aborted session (e.g., the machine was
rebooted while a McIDAS session was active). If this occurs, and if
one or more of the files that should be in ~/.mctmp are left in a
different directory that is in other users' MCPATH set of directories,
then that/those user/users will begin experiencing very strange behavior
in their McIDAS sessions. Your situation was a "classic" example of
this kind of situation. I have observed that if users have their
McIDAS envionment variables correctly defined (i.e., MCDATA, MCPATH,
MCGUI, MCTABLE_READ, and MCTABLE_WRITE) then sessions that get aborted
will not spew the various files (the ones that are supposed to be in
~/.mctmp) in unwanted directories
>We are running some batch mcenv scripts as user ldm, and since
>starting this email, I see that the file has been change even more recently.
>
>-rw-rw-r-- 1 ldm 55488 Jan 19 00:42 /home/disk/data/mcidas/FRAMENH.0
> 01
Once the file gets created and is "findable" through a user's MCPATH,
it will get used. The use will most likely entail the file getting
updated with new information pertinent to the McIDAS session that is
using it. This includes the mini-sessions created by batch mcenv
scripts. By the way, the MCPATH setting you list below shows how this
file is being accessed: you have included /home/disk/data/mcidas in
your MCPATH. This is neither good nor bad. I just offer the comment
so that you (and any other sites that reads the Unidata McIDAS email
archives) can see how the file is being found.
>If this file is indeed a problem, do you have any suggestions on how
>to avoid this?
o make sure that no McIDAS session of any kind is currently accessing
this file (e.g., no shell script is running; no user sessions are
running, etc.)
o delete it
o review your various batch mcenv scripts and make sure that your McIDAS
environment variables are all and correctly defined
>Should we run our scripts in ~ldm/mcidas/data or ~mcidas/workdata?
I am strongly in favor of keeping McIDAS stuff separated from the LDM.
This is why I recommend that a site's 'ldm' configuration not contain
any McIDAS environment variable definitions (i.e., do not put a
definition for MCDATA, MCPATH, etc. in ~ldm/.cshrc). Defining these
variables in a shell script that runs McIDAS commands will isolate the
McIDAS stuff from the LDM environment altogether. For this reason
I would suggest that the shell scripts not be run out of the LDM
account unless you are confident that you understand McIDAS enough
to avoid problems (I offer this comment for folks reading the email
archives).
>Is there a special procedure to exit a mcenv script
>that we are omitting?
Since I havn't seen your scripts, I can't say that you are missing anything.
All I do in scripts that I run is an exit at the end.
>Also, here are my McIDAS environment variables, in case they help.
>
>MCDATA=/home/disk/blizzard2/ovens/mcidas/data
>MCPATH=/home/disk/blizzard2/ovens/mcidas/data:/home/disk/data/mcidas:/home/dis
> k/ldm/mcidas/data:/home/disk/ldm/mcidas/help
>MCGUI=/home/disk/ldm/mcidas/bin
>MCTABLE_READ=/home/disk/blizzard2/ovens/mcidas/data/MCTABLE.TXT;/home/disk/ldm
> /mcidas/data/ADDESITE.TXT
>MCTABLE_WRITE=/home/disk/blizzard2/ovens/mcidas/data/MCTABLE.TXT
These look correct. I add the following strictly for the sake of our
searchable email archives.
Contained in the 7.7 online documentation is a link to a file,
user_env.csh, that shows how to setup McIDAS environment variables in a
user's .cshrc file (C shell users of course) (equivalent definitions
for Bourne/Korn shell users can be found in the user_env.sh file):
# 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
setenv PATH $MCGUI
else
setenv PATH ${MCGUI}:$PATH
endif
endif
# Limit ADDE transfers to compressed ones
setenv MCCOMPRESS TRUE
The same kind of thing is done in Unix shell scripts that run McIDAS
commands with the exception that the conditional block construct:
if ( ! ${?MCPATH} ) then
...
endif
is not used. As a starting point for 7.7 users, I included two example
Unix Bourne shell scripts in my distribution:
mcbatch.sh
mcrun.sh
mcbatch.sh is a skeleton that:
o illustrates how to run a sequence of McIDAS commands from a Unix shell
script (a Bourne shell script in this case)
o is installed in ~mcidas/data
o is designed to be copied by a user and modified to match his/her setup
mcrun.sh is a skeleton that:
o illustrates how to have a Unix shell script execute a McIDAS BATCH
file. mcrun.sh is also a Bourne shell script.
o is installed in ~mcidas/data
o is designed to be copied by a user and modified to match his/her setup
All of the addenda updates to Unidata McIDAS-X contain versions of these
files that are complete; the versions released in the original 7.7
distribution were missing definition of MCTABLE_READ and MCTABLE_WRITE.
>Thanks again.
You are welcome.
>P.S. I hope you don't respond to this until later tomorrow. If you've
>been in Albuquerque (sp?),
Funny you should mention the spelling of Albuquerque. This was the one
thing that I didn't even think about while doing my AMS presentation.
I only started worring about the spelling the morning I had to fly out,
and my overheads were already packed. Luckily, I, like you, spelled it
correctly :-)
>you should be getting some sleep by now.
Thanks for the thought!
Tom