20030421: problem with REDIRECT on OSF/1 4.0F

>From: "Tonkin, Martha E." <address@hidden>
>Organization: Northrop Grumman
>Keywords: 200304211441.h3LEf47U008241 McIDAS-X v2002b Compaq OSF/1 4.0F

Hi Martha,

>The problem is, McIDAS 2002b was built on Tru64 Unix 4.0f (while it
>builds on Tru64 Unix 5.1, the 5.1 McIDAS executable won't run on the
>4.0f system).

Right, I wouldn't expect executables to be backwardly compatible.

>The McIDAS executable resides on a user partition that
>is an ADVFS partition built on 5.1
>
>When the McIDAS REDIRECT command is run on the 5.1 system, it works
>perfectly.  When the REDIRECT command runs on the 4.0f system, even
>though it was built on that system, the LWPATH.NAM file is updated in a
>weird manner.

I never ran into this on our OSF/1 4.0x systems.

>Lines in the file are overwritten with the new REDIRECT
>ADD data rather than the lines being appended to the file.

Actually, the file should be overwritten each time REDIRECT is run
and not simply appended to.  The reason for this is that the entries
in the REDIRECT definition file, LWPATH.NAM, get alphabetized.

>Other times
>the new line which is supposed to be appended is just ignored. However,
>no errors are logged by the REDIRECT command. When a REDIRECT LIST is
>issued in McIDAS immediately after the REDIRECT ADD command is issued,
>the data returned is wrong and when we cat LWPATH.NAM indeed it does
>not contain the data which was just added.  The file ownership and
>permissions are fine, and there are absolutely no error messages thrown
>up by the os.

The first thing I would check is that the copy of LWPATH.NAM that you
think should be getting updated is the one that McIDAS thinks it should
update.  The location of LWPATH.NAM will be determined by REDIRECTions
(kind of a circular dependency), and by the directories in the user's
MCPATH.  I have instances of strange behavior of REDIRECT when the
location of LWPATH.NAM is specified and the user is not in the
correct directory.  For instance, I recommend that sites define
REDIRECTions so that LWPATH.NAM is found in the current working
directory:

LWPATH.NAM   .

However, it is expected that the user will be in the correct directory
when REDIRECT is run.  This was easy to insure when users only ran
from a McIDAS session, since I modified the McIDAS startup script
to put the user (CD, that is) in the correct directory (which
is ~mcidas/workdata for the user 'mcidas' and ~/mcidas/data for
other users).

Are you running the REDIRECT command from a McIDAS session (i.e.,
typing the commands from the Text and Command window or MCGUI console),
or are you running the REDIRECT comamnd(s) from the Unix shell prompt
(i.e., running redirect.k).  If the answer is the latter, then
it may be the case that you are in the wrong directory when running
REDIRECT.   To check out which copy of LWPATH.NAM McIDAS will use/update,
use the DMAP command:

DMAP LWPATH.NAM

Again, the copy used/updated should be one in your McIDAS working
directory.

>We tried runnning the REDIRECT command on the 4.0f system and writing
>to the old user area, which is still around (it's an ADVFS file system
>built on 4.0f), which also did not work.

I guess that I don't know enough about 'the old user area' to say
whether or not this should be a problem.  I am suspicious that a
copy of LWPATH.NAM is getting updated correctly, but it is not the
one you think it is.  The other thing I am a little worried about
(even though you assured me that the read/write permissions on
LWPATH.NAM are OK) is that the copy that McIDAS is trying to update
is not writable by the user you are running McIDAS as.

>We tried deleting the entire
>directory structure for the particular user on the 5.1 user partition
>and recopying the files from the old user partition to the 5.1 user
>partition for that particular user, but again the problem occurred.
>The whole thing is bizarre.

The DMAP command above should help shed light on what may be going
on.

>Any suggstions you can make would be much appreciated.

Let me know the results of the 'DMAP LWPATH.NAM' invocation from a
McIDAS session.  Also, please let me know if you are doing this as
the user 'mcidas', or as some other user.  Finally, while still in
the McIDAS session, please run:

!pwd

so we know what your current working directory is.

Tom