20010119: McIDAS-X and the EU command (cont.)

>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