20010310: FOUSRPT for STC (cont.)

>From: Unidata Support <address@hidden>
>Organization: St. Cloud State
>Keywords: 200103091741.f29HflL00744 McIDAS-X 7.7 FOUSRPT

Alan,

I looked into why adde.ucar.edu was able to serve FOUS14 data for
STC and waldo was not.  What I found was a little disconcerting, but
fixable.

It turns out that the new McIDAS 7.7 station database (STNDB.CORE) was
missing flags for 58 stations that indicate that they are FOUS14 (NGM
MOS) stations.  I fixed this on waldo and remade a file that is needed
and stopped and restarted the LDM.  Details of exactly what I did and
why I did it follow.

I include the following detailed explanation more for the inquiry
tracking databse than for your interest (since it is fairly arcane
stuff):

The process of one being able to list FOUS14 data with FOUSRPT involves
the initial building of an index file that contains all of the possible
FOUS14 stations; that table is named FOUS14.RAP.  FOUS14.RAP is built
when one runs the XCDDEC.BAT file as part of the XCD setup.  XCDDEC.BAT
runs a BILDTEXT invocation to create RAPid access files (*.RAP) for all
of the text data that one will be able to list raw observations from:
FOUS14, RAOB, SAOMETAR, SYNOPTIC, and TERMFCST.  In order to create the
RAPid access files, BILDTEXT reads the station database to see which
stations are flagged as being ones for which the particular type of
data can be found.  By not flagging those 58 stations as being FOUS14
sites, the station databse did not allow for those stations to get
entred into FOUS14.RAP.  The ADDE server from which FOUSRPT gets data
(actually, FOUSRPT runs OBSRPT which then contacts the ADDE server, but
that is not real important) checks to see if the ID specified in the
listing request is in the RAPid access file.  Stations like STC which
were left out are not found, so the server reports that no data can be
found for it.

Phew, so what is the fix?

In McIDAS 7.7x and on, one can add/correct stations to/in the station
database.  This ammendment process can be done by individual users for
their own benefit, or by the McIDAS administrator for their entire
site.  The ammendment process consists of creating a file named
STNDB.USER (for individual users) or STNDB.SITE for sitewide
modifications.  STNDB.USER would be created using one's favorite text
editor (e.g., vi, emacs, etc.) in the user's McIDAS working directory
(e.g., ~user/mcidas/data).  The sitewide file, STNDB.SITE, would be
created in the ~mcidas/data directory using the administrator's
favorite test editor STNDB.SITE file will be used automatically for all
station listing/access programs as long as it is readable by owner,
group, and world and each user's MCPATH is correctly configured.

Since I have already been including a STNDB.SITE file in my McIDAS
distributions, the process of adding support for the missing FOUS14
stations is just one of adding definitions for those stations to the
pre-existing file.  I did that earlier today, and FTPed the new copy to
the ~mcidas/data directory on waldo.  In order to get the RAPid access
text listing stuff to work I then had to:

<as 'ldm'>

stop the LDM

<as 'mcidas'>

cd /var/data/mcidas
rm FOUS14.*

cd ~mcidas/workdata

<extract the appropriate BILDTEXT invocation out of XCDDEC.BAT and run it
from the Unix command line:

bildtext.k INIT FOUS14.RAP   FOUS14.RAT    600 2 C4   2 12 80 FOUS14   X 32

<this recreates the FOUS14.RAP file in /var/data/mcidas

<as 'ldm'>
restart the LDM

As soon as new FOUS14 data comes in, the RAPid access stuff should be
updated, and FOUSRPT will start working for those 58 stations that were
missing FOUS14 flags in the master station database.  The fix should be
testable by late tonight or tomorrow morning.

The last comment I have concerns why the access of STC on adde.ucar.edu
kept working.  The reason for this is that I did not recreate
FOUS14.RAP when I ugraded from 7.613 to 7.7 on that machine.  So, if I
hadn't told you to go ahead and delete all of the *.R* files in
/var/data/mcidas, you would have not run into the FOUSRPT problem, or,
at least, you would not have run into it when you did.

I will give waldo a quick check tomorrow to make sure that things are
working as they should.

Signing off for now...

Tom