20000613: Help converting non-ADDE script (cont.)

>From: Angel Li <address@hidden>
>Organization: RSMAS/University of Miami
>Keywords: 200006061956.e56JuLT23087 McIDAS-X ADDE cron mcbatch.sh mcrun.sh

Angel.

re: snooping around

>I'm going to be running around in and out
>of my office all day. I'll try and get back to you if you have any
>questions. Do whatever you think is necessary.
>
>Thanks a bunch,

Well, I logged in and started poking around right after receiving the
access information.  I really didn't do much of anything, but things
are apparently working.

Here is what I did and some observations:

o I noticed that you have the MCDATA directory set to be /s1/ldm/mcidas/data
  in a wide variety of scripts used by the LDM and cron-scheduled scripts
  (e.g., xcd_run, batch.k, areapack, dsinfo, etc.)

o You have McIDAS environment variables defined in your LDM environmental
  files, ~ldm/.bashrc and ~ldm/.cshrc.

o I notice that you updated your routing table entries for the UW image
  products to switch to use of the GE-IR.BAT, GE-VIS.BAT, etc BATCH
  files.  I was happy to see this since the 7.7 McIDAS release will
  not have the IR8.BAT, VIS8.BAT, etc BATCH files included.

The recommendations in the Unidata online McIDAS web pages recommend
against defining McIDAS "stuff" (McIDAS environment variables MCDATA,
MCPATH, etc.) in the LDM environment.  One of the main reasons for this
is to keep the LDM account "clean" and to help keep the user from
shooting him/her self in the foot (McIDAS and the LDM are both complex;
it is hard sometimes to keep LDM stuff isolated from McIDAS stuff so
that they don't intefere with each other ).  It appears, however, that
your setup has covered all of the potential pitfalls in doing so.  For
this reason I will not recommend redoing your setup to strictly follow
the online docs.

In a previous email concerning ADDEizing your route PP BATCH files, I
failed to recommend changing from use of FRONT (which needs to have the
frontal information stored in ASUS1* files which can be found through
McIDAS REDIRECTions) to FRNTDISP (the ADDE replacement).  Since you are
now running XCD, your system has the front information available in a
way that is easily accessed by ADDE.  I took the liberty of editing
~mcidas/data/GE-IR.BAT, etc. and changing 'FRONT OLAY FRAME' to
'FRNTDISP OLAY FRAME'.  This is all that is needed to ADDEize.

In order to setup the McIDAS account to be able to look at the data being
ingested by the LDM, I:

o logged in as 'mcidas'
o defined McIDAS environment variables in both .cshrc and .bashrc
o I copied a number of files from ~ldm/mcidas/data to ~mcidas/workdata:
  cd workdata
  cp ~ldm/mcidas/data/LWPATH.NAM .
  cp ~ldm/mcidas/data/RESOLV.SRV .
  cp ~ldm/mcidas/data/STRTABLE .

I could then crank up a McIDAS session as 'mcidas' and exercise the code
and look for potential problems.  Since the 'ldm' account has McIDAS
environment stuff defined for it, I also ran a McIDAS-X session as 'ldm'.

One problem: I found a copy the file Frame1.0 in the ~mcidas/help
directory.  Files named FrameN.M should be created on a
session-by-session basis in subdirectories of the hidden .mctmp
directory.  There is one file for each frame defined in the user's
session.  The existence of Frame1.0 (McIDAS frame 1 information (e.g.,
navigation, etc.)) somewhere other than ~user/.mctmp/nnnnn indicates
that something went wrong at some time.

The problem with FrameN.M showing up in a directory in the user's
MCPATH set of directories is that it will be used instead of the copy
created for the current session in ~user/.mctmp/nnnnn.  This can cause
problems exactly like the one you were seeing (wrong image information
for a frame that has an image displayed in it), and it can lead to
concurrently running sessions stepping on one another.  The latter
situation is especially bad for the mini-sessions that get kicked
off by ROUTE PostProcess BATCH invocations.

I deleted ~mcidas/help/*.0* (there was only Frame1.0), so potential
clashes should go away.

Right now, I am waiting for new UW image products to come in so I
can verify that the ROUTE PostProcess BATCH invocations are working
correctly.  I can execute the commands in the BATCH files "by hand"
from a McIDAS-X session run as the user 'ldm', so I think everything
should be OK, but...

Tom