19991027: Running LDM on Irix 6.5 (cont.)

>From: Erick Lorenz (address@hidden) <address@hidden>
>Organization: UC Davis
>Keywords: 199910272007.OAA03748 McIDAS XCD

Erick,

>I noticed that the AREA files were updating too.  What I did was to
>comment out the MCIDAS entry in pqact.conf and uncomment another entry
>that had an absolute path to lwtoa3.
>
>MCIDAS  ^(LWTOA3 .*)
>     PIPE       -close
>     /usr/local/ldm-mcidas/bin/lwtoa3
>     -d /home/data/mcidas
>     -l /usr/local/ldm/logs/mcidas.log
>
>I think this was the source of the console error message about a 
>file not existing.
>
>>Oct 27 18:10:51 pqact[8655]: pipe: execvp: lwtoa3: No such file or directory

This tells me that the PATH for the user 'ldm' was(is) incorrect.  This,
in turn, tells me that ROUTE PostProcessing upon receipt of imagery will
not work.  I verified this by:

<login as ldm>
which lwtoa3
<not found>

What is also not found is the Bourne shell script, batch.k.  batch.k is
used to run the McIDAS PostProcess BATCH files upon receipt of the image
data.  This was setup on ATM23, so you will probably want to do it
on ATM12.

I suggest:

<login as ldm>
cd decoders                       (since the decoders subdirectory IS in PATH)
cp /usr/local/ldm-mcidas/bin/batch.k .
<edit batch.k and set McIDAS environment variables to match your setup>
cd ~
which batch.k

After batch.k can be found and has been edited so that the McIDAS environment
variables are correct, ROUTE PostProcessing can/will proceed.

>Do you suppose that I need an entry in one of my PATH variables that
>points to ldm-mcidas?

Actually, I recommend copying the ldm-mcidas decoders over to the decoders
directory in the ldm account:

cd decoders
cp /usr/local/ldm-mcidas/bin/* .
<check to make sure that these decoders all have write permission>


>I couldn't find a corresponding entry in
>any of the ldm environment variables on ATM23.

I think that is because the ldm-mcidas decoders had been copied to
~ldm/decoders on ATM23.

>Anyway between the two of us the AREA files are coming in!

Wonderful.  I think the next step is the copying of the decoders as
I indicate above followed by removal of the full path to lwtoa3 in
pqact.conf.  The reason I am keen on this is that the ldm-mcidas/bin
directory will be overwritten the next time you do an upgrade to the
package.  This will/should not matter for the actual decoders (e.g.
lwtoa3, nldn2md, etc.), but will be important for batch.k (since it
has to be edited).

>I had been modifying the redirection files (LOCAL.NAM) thinking
>that that would tell XCD where to go but I was not sure.

It is a first step.  After changing ~mcidas/data/LOCAL.NAM, the REDIRECTions
in it have to be restored to the McIDAS account:

<login as mcidas>
cd mcidas/data
<edit LOCAL.NAM>
cd ~/workdata
redirect.k REST LOCAL.NAM

Note that ALL users that need to access the McIDAS data files directly
(through non-ADDE routines) will need to have their set of REDIRECTions
updated in this manner.

>I haven't completed the OSF/1 installation because I wanted to
>get a stable system running that did not have that network bottleneck
>and also I need the drive /lore from ATM23 (where ATM12 was writing)
>for the OSF machine.  So by doing this I will have a running system
>that is independent of either the old machine ATM23 or the new one ATM25.

OK, I understand.

>I will try restarting the syslogd as you suggest.  As far as I can see
>all my entries in the /etc *.conf files are correct.

OK.

>Thanks

No problem.

Tom