20020819: McIDAS-XCD on a new RedHat 7.3 Linux box (cont.)

>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200208191756.g7JHuBK26547 McIDAS-XCD Linux

Bill,

This is the email that I was in the midst of sending you yesterday
when you called.  I am finishing it so that the information in our
inquiry tracking system is complete.

Sufficit to say that MD file decoding proceeded on your new RedHat
7.3 Linux box as the clock rolled past 0Z.  This was the kind of
behavior we have both seen on systems running McIDAS-XCD.

As a review, what we did was:

1) consolidated XCD and ldm-mcidas created data files into a single
   directory, /var/data/ldm/mcidas/xcd

2) corrected a bug in xcd_run.  The bug was the deleting of the
   log file right after redirecting all output (stdout and stderr)
   to the file.  This bug seems to reek havoc on Linux systems,
   but not others

3) correct a typo in ~ldm/etc/pqact.conf.  The typo was the spaces
   after DDPLUS|IDS and PIPE in the action that pipes textual products
   to xcd_run specifying the DDS flag:

DDPLUS|IDS      ^.*     PIPE
        xcd_run DDS

As I finish this note, I have to say that things seem to be working
more-or-less correctly.  The one thing that I do not understand,
however, is that the permissions on the files being created by
XCD decoders were -rw-r--r--.  The umask set for both 'ldm'
and 'mcidas' is 002, so files should be created with -rw-rw-r--
permissions.  The only thing I can think of that would cause this
to happen is in how the LDM was started/restarted yesterday.  When
you had a login as 'ldm', how did you do the login?  What I am
driving at is if you did:

su ldm

then the umask that would have been in place in your session would
have been the one that was in place in the login from which you
did the 'su ldm'.  If you have occasion to become 'ldm' to do
work, you should always login, or become 'ldm' with:

su - ldm

The '-' says to inherit and use all of the environment setup for
'ldm'.  A 'su ldm' does not.

The remainder of this email is what I was writing yesterday.


>Since classes start in two weeks, I really don't want to move
>to the latest version, 2002. I have a lot of scripts and just
>don't need that now.

I would venture to say -- without an intimate knowledge of your
scripts -- that the work you have put into getting them to work
with v7.8 would translate directly to v2002.

>We were behind schedule before the hack,
>so now things are really rushed.

I understand.  I would love to see you using a current release,
however, since the amount of effort I put into bug fixes for a
previous release is minimal.

>I can see consolidating the data in one directory. I don't
>believe any scripts have "hard wired" directories; they all
>rely on file redirection. I will try this.
>
>The directories, xdata and xcd, are nsf mounted by each 
>workstation in the lab. ADDE obsoletes this, but we are not
>100% ADDE -- just mostly.

OK, I understand.

>Labstuff contains primarily our menu scripts, and other
>'enhancements' used locally. LWPATH.NAM is a backup in case 
>someon loose theirs, and needs a quik fix.

OK.  I just get nervous when I see copies of LWPATH.NAM in directories
other than the user's McIDAS working directory.  The potential for
screwing up and using the wrong one is just too great.

>Should I consolidate xdata and xcd?

I think so, yes.  This will make XCD and ldm-mcidas installation/configuration
easier.  It should help eliminate the type of problem you are facing
now and before.

The easiest way to combine the directories is to move all files from one
to the other; delete the now empty directory; and then make a soft link
to the existing directory using the deleted directory name:

cd /var/data/ldm/mcidas
mv xdata/* xcd
cd xdata
rm *
cd ..
rmdir xdata
ln -s xcd xdata

Tom