NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>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