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

19990122: dchrly

>From: "Frank Colby" <address@hidden>
>Organization: University of Massachusetts Lowell
>Keywords: 199901221740.KAA21111

>Dear Steve,
>
>I hope you don't mind my asking lots of gempak questions, but since I am
>new to unix (coming from years of vax/vms and dcl) I keep running into
>problems.
>
>I can decode hourly data into gempak format using dchrly at the command
>prompt, although I have to be careful how I type it.  That is, if I just
>string all the stuff together, including the full specs for the packing
>and stns tables, the command won't execute -- it is as though the
>command line interpreter can't read all this stuff at once.  If I insert
>non cr characters, so the cursor does a cr, but the interpretation is a
>"continuation" (actually a blank, according to the man page), I can get
>dchrly to run fine.  This causes a script I wrote to NOT work, I guess,
>since it tries to execute the dchrly command all at once.  I'm a little
>frustrated with that.  
>

Frank, without seeing what you are typing, I can't seem to decipher
what you are trying to say. The appropriate way to invoke dchrly
from the command prompt would look like:

cat infile | dchrly -p packfile -s stationfile -a numadd etc... YYMMDD_sao.gem

Those spaces are in fact spaces, not carriage returns.
If you need more than 1 line in a csh command invocation, you can continue
lines with the "\" character, eg:
cat infile | dchrly \
   -p packfile \
   -s stationtable \
   -a numadd \
   YYMMDDHH_sao.gem

>In addition, I have enabled dchrly to run from the ldm using the
>pqact.conf entry, changed to reflect my directory tree, but it seems to
>run without doing anything.  That is, entries are made in the log,
>entries which look "normal", but no data is decoded.  When I try to
>execute dchrly from the ldm account, trying to get the help files
>(dchrly -h), I get IP -6 error messages, which mean something about
>control characters in the input?
>

The output path should exist before dchrly id run from LDM.
Thus if you are trying to output to data/gempak/surface/YYMMDD_sao.gem,
then you need to create the data/gempak/surface directory.

The dcdecoders have options, which in respect to tables, either use
the complete path name, the GEMTBL environmental variable, or
the current directory.

For example, if you specify -s sfmetar_sa.tbl, and that file is not
in your current directory, then the decoder will see if the variable
$GEMTBL is set, and if it is, try looking for $GEMTBL/stns/sfmetar_sa.tbl.

In general, when invoking decoders from the LDM, the environmental variables
are not available, so the decoder must rely on absolute paths to the
GEMPAK tables. Check the path names, as well as read permission by
the LDM user. If your GEMPAK distribution does not allow the LDM user to
access the tables, then it will not be able to read the packing, station etc
tables and won't be able to create the output file. Also remember, when
you continue lines in the LDM pqact.conf file, a TAB must be the
first character on the line, eg:
WMO     ^S(A|P).*
<TAB>   dchrly -s /fullpath/sfmetar_sa.tbl
<TAB>           -p /fullpath/hrly.pack -m 24 -b 24 -a 200
<TAB>           data/gempak/surface/YYMMDD_sao.gem


Perhaps the difference in continuation of lines between the csh and
pqact.conf is what you were alluding to in the message above.
The LDM uses the TAB character at the beginning of a line to 
recognize a continues line, while the csh ends a line to be continues
with a "\".

>Frank
>

Steve Chiswell
Unidata User Support