[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990201: ROUTE PP BATCH invocation failing (cont.)

>From: Owen Cooper <address@hidden>
>Organization: UVa
>Keywords: 199902011446.HAA01860 McIDAS ROUTE PP BATCH


>My question is this:
>When incoming data has the ldm kick-off a batch, and the batch needs to
>be able to write to a string table, which .NAM file does it look in to find

The McIDAS file finding mechanism is composed of both file REDIRECTions
and directories instantiated in the environment variable MCPATH.  When
a command is run outside of a McIDAS session (like when a ROUTE PP BATCH
invocation is started), initially there will be no REDIRECTions defined.
If MCPATH is also not defined, the routine being run synthesizes a MCPATH
that is composed of '/home/mcidas/data:/home/mcidas/help'.  As soon
as the mini-session created by the execution of the command comes into
being, the startup preamble for the routine looks for a file named
LWPATH.NAM in the first MCPATH directory.  If LWPATH.NAM is not found
in that directory, then the next MCPATH directory is search, and so
on.  This is the reason for the setting of MCDATA and MCPATH in the
Bourne shell script 'batch'k' that is used as a substitute for the
real McIDAS BATCH command.

Here is the code from 'batch.k' that defines the needed McIDAS environment


# Define needed macros

In this case, the first MCPATH directory is /home/mcidas/workdata.  This
is where 'batch.k' will look for LWPATH.NAM, and this is where it _should_

>These batches are being run under user mcidas, so does it need to see
>/home/mcidas/workdata/DEFAULT.NAM    ?

No, /home/mcidas/workdata/LWPATH.NAM.

>and here is a sample from DEFAULT.NAM containing STRTABLE
>SAOMETAR.RAT /incoming/data/xcd
>SCHEMA /incoming/data/xcd
>STRTABLE /home/mcidas/workdata
>SYNOPTIC.RAP /incoming/data/xcd
>SYNOPTIC.RAT /incoming/data/xcd
>SYSKEY.TAB   /incoming/data/mcidasd

We send EXAMPLE.NAM out in the distribution with the following location
information for STRTABLE:


The '.' says to look for LWPATH.NAM in the current working directory.
This is the reason that the Bourne shell script puts you in a
particular directory:


# CD to the MCDATA directory

If the copy of batch.k that you are using for ROUTE PP BATCH invocations
does not contain this code (there was at least one distribution of ldm-mcidas
that omitted this important step), you should add it:


# Format the command for execution
command=`echo "$@" | sed 's/^BATCH/batch.k/'`

# CD to the MCDATA directory

# Send all messages to the log file
exec 2>> $MCLOG 1>&2

This make sure that the REDIRECTion defined by:


finds/keeps finding LWPATH.NAM in the same place.  This may seem a little
bit difficult, but it was a way to get around the "chicken and egg problem".

>I had discovered that there wasn't a redirection for STRTABLE in DEFAULT.NAM
>so I put one in, but that hasn't helped the problem.

Again, DEFAULT.NAM is not the important file; LWPATH.NAM is.

>It turns out that DEFAULT.NAM and many other files in /home/mcidas/workdata
>were assigned different ownership when we were shuffling directories
>Saturday afternoon, which coincides with the time we started to get the 
>QTIME problem. We have corrected this problem.

The change of ownership is undoubtedly the problem.

>But, is it possible that we lost the .NAM file that the batch jobs are 
>looking for?

Yes, it is possible.  If LWPATH.NAM is gone, then you need to follow
the instructions in the McIDAS-X installation procedures that are available
from the McIDAS-X web pages under:


The short of the procedure is:

o edit DEFAULT.NAM to include ALL of the REDIRECTions that are necessary
  for your system.  This includes REDIRECTions for XCD and ldm-mcidas
  produced data files, etc.

o as the user 'mcidas', start a McIDAS-X session:


o restore the definitions in DEFAULT.NAM to the active REDIRECTion 
  repository file LWPATH.NAM:


o verify that the REDIRECTions that you defined are correct.  For instance,
  do things like:


  etc.  If you get any errors, then fix the REDIRECTion in EXAMPLE.NAM
  by editing it, and then restore the contents to the active repository:


>Or are the batch jobs looking for XCD.NAM ?


>Just so you know I tried, I spent some time going thru the archive e-mails
>and manuals but wasn't able to find my answer.  

The answer is in the McIDAS-X installation and configuration web pages.

>Please help me along this learning curve!

No problem; don't worry about it.  I would point out to you that the
comment in your first email:

"All of a sudden, since approx 7 UTC Jan 30 SFC.BAT has been failing"

is less "all of a sudden" and more "we inadvertantly changed something" :-)


You are welcome.

Tom Yoksas

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.