20030422: 20030421: problem with REDIRECT on OSF/1 4.0F

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

Hi Mary Ellen,

>We are running from the McIDAS session, not the command line.
>The user is "mel", not "mcidas".

OK, good.

>The result from the command DMAP LWPATH.NAM is:
>"-rw- 307 Apr 18 17:11 LWPATH.NAM /usr/users/mel/mcidas/data/.
>The result from the command "!pwd" is:  "/usr/users/mel/mcidas/data".

OK, this is all correct.

>Based on the
>email, it looks like everything is set up correctly. 

Yes, everything looks correct.

Please do the following and send back the results:

DMAP Frame
DMAP *.001

What I am looking for is anything out of the oridinary.  If things are
setup correctly -- and they appear to be --, and if there has been no
"strangeness" on your system -- this is what I am looking for -- then
files that begin with Frame and end with .001 should be found in a
subdirectory of /usr/users/mel/.mctmp.  Sometimes when McIDAS messes up
(typically from the environment not being quite correct), you may find
FrameN.M files in the ~mcidas/help directory and *.001 files in the
~/mcidas/data directory.  In this case, the file(s) need to be deleted
so that things will run correctly.

Also, can you send me back the results of:

% env

I want to see how the McIDAS environment variables MCDATA, MCPATH,
MCTABLE_READ, MCTABLE_WRITE are setup for 'mel'.

>Let me walk you through an example of what I am see happen in
>steps...maybe you'll see something we don't.
>
>1.) Rename LWPATH.NAM to LWPATH.NAM.ORIG
>2.) Touch LWPATH.NAM (size is 0bytes, no entries)

OK, you did not have to create the file first _IF_ there are no other
files named LWPATH.NAM in any directory in the user's MCPATH.

>3.) Launch a McIDAS session.
>4.) REDIRECT ADD AREA4* "/d2/peru/Satellite/apr2003
>5.) REDIRECT LIST
>       result: "Number of active redirection entries = 0"

OK, this demonstrates what you have been telling me about.  The file
LWPATH.NAM (located in /usr/users/mel/mcidas/data) should get updated
by the REDIRECT ADD invocation above.  The fact that is not being
updated verifies that there is a problem.

>6.) more LWPATH.NAM
>       result: one blank line. Size of file is 34bytes.

Hmm...  One blank line!?  This is most likely telling us what we need
to know.

>7.) REDIRECT ADD AREA6* "/d2/peru/Satellite/apr2003
>8.) REDIRECT LIST
>       result: "AREA6* /d2/peru/Satellite/apr2003"

Weird!  So, the second REDIRECT ADD _did_ cause an update to LWPATH.NAM.

>9.) more LWPATH.NAM
>       result: overwrites the blank line with "AREA6* 
> /d2/peru/Satellite/apr2003/". Size of file=69bytes
>10.) REDIRECT ADD AREA8* "/d2/peru/Satellite/apr2003
>11.) REDIRECT LIST
>       result: "AREA8*"   (no path)

Wow.  OK, big problem!!

>12.) more LWPATH.NAM
>       result: contains one line. overwrites AREA6* line with "AREA8*
>/d2/peru/Satellite/apr2003". Size of file=103bytes
>13.) REDIRECT ADD MDXX01* "/d1/RawSfc/apr2003
>14.) REDIRECT LIST
>       result: "Number of active redirection entries = 0"
>15.) more LWPATH.NAM
>       result: contains one line. Overwrites AREA8* with "MDXX01*
>/d1/RawSfc/apr2003". Size of file=108bytes

Got it, you definitely do have a problem.  Unfortunately, I can't
replicate this problem here since we no longer have an OSF/1 4.0x
machine in-house.  I don't suppose that this box is accessible from the
internet?  I am guessing the answer is no.

>Your email indicated that indeed the LWPATH.NAM does get overwritten each
>time as it alphabetizes the entries but our version seems like it is not
>able to keep the entries in memory to write them back to the file.

Exactly.

What would happen if you created an ASCII file with the REDIRECTions
you want in it and then use 'REDIRECT REST fname' to restore the
REDIRECTions to the session?  The file I have in mind would look like:

TEST.NAM::

AREA4*  /d2/peru/Satellite/apr2003
AREA6*  /d2/peru/Satellite/apr2003
MDXX01* /d1/RawSfc/apr2003

REDIRECT REST TEST.NAM

Also, what happens if you edit the file LWPATH.NAM, add the entries
like the ones in TEST.NAM (note that there are no quote marks!), and
then ran:

REDIRECT LIST

or

DMAP AREA4

>Thanks for the help.

If I can't get on an OSF/1 4.0x machine to find out what may be wrong,
then the only thing I can think of is a way to get around the problem.

Tom