[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010612: ROUTE Postprocess BATCH invocations (cont.)

>From: Brian Colle <address@hidden>
>Organization: SUNY Stony Brook
>Keywords: 200105070058.f470wSp08974 McIDAS Frame

Brian,

>A month ago you helped me with my mcidas batch problem below. I
>tried the re-install under the mcidas account and things work better
>(creates map backgrounds). However, occasionally a wrong map background is
>put on an image or no background at all. As a result, I still think there
>is something wrong with my setup. One thing that I have never been able to
>understand/solve is why a FRAMENH.001 keeps being written to my
>/usr/local/ldm/data/mcidas and Frame* to ~/help.

I don't understand this one either.  We have been running ROUTE initiated
PostProcess BATCH files for years here at the UPC (on multiple machines)
and _never_ have this problem.

>mcidas>dmap.k FRAME
>PERM      SIZE LAST CHANGED FILENAME      DIRECTORY
>---- --------- ------------ ------------- ---------
>-rw-      1286 Jun 08  2000 FRAME.PROG    /usr/local/ldm/mcidas/data
>-rw-      1981 May 30  2000 FRAMECUR.PROG /usr/local/ldm/mcidas/data
>-rw-         1 Jun 12 09:27 FRAMED /usr/local/ldm/mcidas/.mctmp/720801
>-rw-     58752 Jun 12 09:27 FRAMENH.001   /usr/local/ldm/data/mcidas
>
>mcidas>dmap.k Frame
>PERM      SIZE LAST CHANGED FILENAME DIRECTORY
>---- --------- ------------ -------- ---------
>-rw-      3072 Jun 12 08:35 Frame1.0 /usr/local/ldm/mcidas/help
>-rw-      3072 Jun 12 08:15 Frame2.0 /usr/local/ldm/mcidas/help
>
>I thought these Frames should be written in ~mcidas/.mctmp only.

Right. The FRAMED, FRAMENH.001, and FrameN.M files should only exist
in transient ~/.mctmp subdirectories.

>Perhaps
>this is why the wrong map is put on sometimes, since multiple batch jobs
>are using the same FRAME?

Yes, exactly.

>Mcidas .cshrc has:
>
>umask 002
>setenv MCHOME /usr/local/ldm/mcidas
>setenv McINST_ROOT $MCHOME
>
># NOTE: conditional definition is only needed for C-shell users
>if ( ! ${?MCPATH} ) then
>  setenv MCDATA $MCHOME/workdata
>  setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help
>  setenv MCGUI  $MCHOME/bin
>  setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
>  setenv MCTABLE_WRITE "$MCHOME/data/ADDESITE.TXT"
>  setenv XCD_disp_file $MCDATA/DECOSTAT.DAT
>  if ( ! ${?PATH} ) then
>    setenv PATH ${MCGUI}
>  else
>    setenv PATH ${MCGUI}:$PATH
>  endif
>endif
>setenv MCCOMPRESS TRUE

This looks OK.

>Is there something in the mcidas install that forces the program to use
>.mctmp?

The McIDAS startup process (this goes for shell scripted invocations of
McIDAS commands as well) creates two shared memory segments that are
used by McIDAS commands to intercommunicate.  Also as part of the
startup process, a subdirectory of ~/.mctmp is created with the name
being the same as the handle for the primary shared memory segment.
The files listed above and others are then created in that directory.
Now, the problem comes in from the McIDAS MCPATH concept.  When looking
to read/write to a file, all of the directories in MCPATH are checked
to see if the file exists.  The .mctmp subdirectory is appended to the
end of the MCPATH by the startup process, so if the file(s) are not
found anywhere else, they will be found in the .mctmp subdirectory
created by the startup process.  Now _if_ the file exists in another
directory, it will be used in preference to the one in the .mctmp
subdirectory since that file will be found before the one in the .mctmp
subdirectory.  The challenge for us is to figure out why the files are
being created in the wrong directory.

All of this may be related to the fact that your PostProcess script is
a Perl script.  One thing you may want to do is remove the files that
shouldn't be there at the beginning of the Perl script.  I know that
this is a _hack_, but I can't think of anything else right off the top
of my head.  What do you think?

tom