20030422: problem with REDIRECT on OSF/1 4.0F (cont.)

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

Mary Ellen,

>       Good suggestions and some interesting results:
>
>DMAP FRAME:
>       -r--    1347    Jul 30  FRAME.PROG /usr/users/mcidas/data
>       -r--    1981    Jun 22  FRAMECUR.PROG   /usr/users/mcidas/data
>       -rw-       1    Apr 22  FRAMED /usr/users/mel/.mctmp/1662983
>       -rw-    205632 Apr 22   FRAMENH.001 /usr/users/mel/.mctmp/1662983

OK, but the command to run is:

DMAP Frame

It is important that the capitalization be correct.  McIDAS stores
navigation, etc. information in files whose names are Frame1.0, Frame2.0,
etc.

>DMAP *001:
>       -rw-    205632  Apr 22  FRAMENH.001 /usr/users/mel/.mctmp/166293
>       -rw-    45056           Apr 22  TERMCHAR.001 /usr/users/mel/.mctmp/1662
> 93
>       -rw-    32404           Apr 01  VIRT001 /usr/users/mel/mcidas/data

This looks good.

>Per your email I don't think anything looks strange in the above output.

Right, at least for the *.001 files.

>Output from %env
>       MCDATA: /usr/users/mel/mcidas/data
>       MCPATH: 
> /usr/users/mel/mcidas/data:/usr/users/mcidas/data:/usr/users/mcidas/help
>       MCINST_ROOT: /usr/users/mcidas
>       MCTABLE_READ: NOT DEFINED
>       MCTABLE_WRITE: NOT DEFINED

For the user 'mel', McINST_ROOT does not need to be defined (being defined
does no harm, however).

MCTABLE_READ and MCTABLE_WRITE control the access to and use of
McIDAS client routing tables.

>I'm not sure the impact of not having MCTABLE_READ and MCTABLE_WRITE
>defined.

Since they are not defined, they default to both essentially being
defined as /user/users/mel/mcidas/data/MCTABLE.TXT.  This is OK.

>I produced the file TEST.NAM and ran the REDIRECT REST TEST.NAM command in
>the McIDAS session. This command worked successfully which was confirmed by
>REDIRECT LIST.

Interesting to say the least!

>Running this command also updated LWPATH.NAM correctly. I
>took my chances and ran a REDIRECT ADD for AREA8*
>"/d2/peru/Satellite/apr2003. This was not as successful. The line in
>LWPATH.NAM for AREA6* was overwritten by AREA8* and is confirmed by REDIRECT
>LIST.

OK, so there really is a problem with the ADD action of REDIRECT.

>I also ran DMAP AREA4. This command produced the output: "0 bytest in 0
>files". I'm not clear what this command is telling us or if this is a
>reasonable output from the command.

If you ran 'DMAP AREA4' after the unsuccessful 'REDIRECT ADD', then all
bets are off.  What is the output after you do the 'REDIRECT REST
TEST.NAM'?  Again, I am searching for a way for you to get around this
not working.

>Unfortunately, you guessed correctly in that you are not able to access the
>particular machine via the internet so we'll just have to find that work
>around as you suggest.

I thought as much.  It seems to me now that the most workable option
would be to use an editor to put needed REDIRECTions in an ASCII file
and then use REDIRECT REST of that file to update your LWPATH.NAM
file.  Also, if McIDAS is not running, you can simply add the
REDIRECTions to LWPATH.NAM using the same text editor.

One other thing I would try is to rebuild the REDIRECT executable:

<login as 'mcidas'>
cd mcidas2002/src
rm redirect.o redirect.k
make redirect.k
rm ~/bin/redirect.k
ln redirect.k ~/bin

The other thing that could be done is to change the optimization that
REDIRECT is created with.  What I mean, is that redirect.k is most
likely built with optimization turned on.  Turn it off, or set it to
debug ('-g') and rebuild redirect.k.  Who knows, maybe just rebuilding
the executable will get you going.

Tom