19990108: Questions (cont.)

>From: Mark Tucker <address@hidden>
>Organization: Lyndon State
>Keywords: 199812081808.LAA17744 McIDAS-X 7.4

Mark,

re: set of REDIRECTions in LWPATH.NAM
>After editing the LWPATH.NAM many of the problems I was having have gone.

re: problems with the  MAN.BAT PP BATCH:
>The problem with MAN.BAT running as a PP BATCH is that it is being
>launched without any values for the arguments (ie. %1, %2, %3, %4 all have
>null values).

This is very odd indeed.  The code that invokes a PostProcess BATCH file
is regularized.  It always provides the same set of parameters on the
BATCH invocation command line:

BATCH pcode cylinder/name date time ccode "PP batch file to run
        ^      ^      ^    ^    ^     ^    ^__ McIDAS BATCH file to run
        |      |      |    |    |     |_______ decoding condition code
        |      |      |    |    |_____________ time of product
        |      |      |    |__________________ date of product YYDDD
        |      |      |    |__________________ date of product YYDDD
        |      |______|_______________________ cylinder (non-TEXT)/name (TEXT)
        |_____________________________________ product code

If these arguments are not there, I suspect one of two things has happened:

o the contents of the Bourne shell script, batch.k, has been altered
o you are attempting to invoke the McIDAS executable, ~mcidas/bin/batch.k,
  directly

The latter of these is what I have seen happen on your system a couple of
times.  This occurs when the PATH for the user running the LDM gets changed
so that the McIDAS bin directory is included (bad!) and is before the
directory in which the Bourne shell script, batch.k, exists.  I suspect
that this is what is happening as I have seen it on your system more than
once (I noted and warned about this in at least two previous emails).

>The batch file assumes that the second argument %2 has a
>value

The second passed parameter (%2) would be the file cylinder number for
non-textual products (e.g. AREA, GRID, or MDXX).

>and then compares and updates the syskey table, #SYS(2011),

Right, SYS(2011) is the storage location for the MD file number for the
MDXX mandatory level upper air product.

>with
>that value.  Since it is not a valid value the rest of the batch file does
>not function properly.  I haven't yet figured out  why the arguments are
>not being correctly passed to the batch when it is launched.

I suspect option two above.

>We also have a program that is used in several of the PP batch files that
>was written by Bill Fingerhut, ygdchk.k, which works when run from a
>mcidas-X session (or from the unix commandline) but does not work when
>called from a batch file.

From any BATCH file, or from ones run as ROUTE PP BATCH invocations?

>I'm at a total loss as to why this is not
>functioning.  The program checks for the existence of a grid and the
>return value is used for a condition for different processes.  I'm trying
>to find the source code to this but if you have any ideas why it would
>behave this way I'd appreciate it.

I don't know enough about how it is failing to even guess why it is failing.

>Another question I have is that it appears that the uppperair data that is
>processed by MAN.BAT comes in at 02:00 and 13:00 EST (07:00 and 18:00 UTC)
>which seems like quite a bit of lag for 0Z and 12Z data.  Is this normal?

No, this is not normal.  This is, in fact, VERY late.  I would expect to
see these data files arrive in the Unidata-Wisconsin datastream about one
to two hours after the ordinal time (i.e. either 1-2Z or 13-14Z).

re: questions on WXP
>Who should I direct WXP related questions to?

WXP has been a community supported package for quite some time now.  You
will need to rely on your Unidata "neighbors" for help on WXP issues.
If you are not already subscribed to it, you should join the WXP and/or
WXP email lists that we maintain and send your questions to them.

>BTW, we have changed the passwords on our servers.  I will call with the
>new passwords.

OK.  I will be heading to the AMS meeting in Dallas on Tuesday morning, and
I won't be returning to work until Monday, January 18.  I will try to look
in on support email from time-to-time, but this relying on this is iffy.

>Thanks.

Later...

Tom