This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Randy, Sorry for the late reply. I just returned from Brazil where my access to the Internet was a bit sporadic... > on our noaapxcd machine we are currently only keeping > the last 5 days of MD data. For example, > > [sleet@sleet1 ~]$ ptlist.k RTPTSRC/SFCHOURLY.ALL > FORM=FILE > Pos Description Schema NRows NCols Proj# Created > DataDate > ------ -------------------------------- ------ ----- ----- ----- ------- > -------- > 4 SAO/METAR data for 10 DEC 2007 ISFC 72 7000 0 2007343 2007344 > 5 SAO/METAR data for 11 DEC 2007 ISFC 72 7000 0 2007344 2007345 > 6 SAO/METAR data for 12 DEC 2007 ISFC 72 7000 0 2007345 2007346 > 7 SAO/METAR data for 13 DEC 2007 ISFC 72 7000 0 2007346 2007347 > 8 SAO/METAR data for 14 DEC 2007 ISFC 72 7000 0 2007347 2007348 > ptlist.k: Done This is the typical setup for McIDAS sites due to the circular naming convention for McIDAS MD files. > These data are being stored in MDXX0104 - MDXX0108 > > I would like to keep the last 30 days. Is this possible? It is not possible to increase the name space being used by the McIDAS-XCD decoders beyond 10 because of the circular naming convention for MD files (e.g., MDXX0001...MDXX0010), but it is possible to keep more data online by renaming your files. I think that it would be a good idea to create a second surface dataset that has everything except the current output file and contains as many days as you want. This can be accomplished by renaming the files using the standard MDXXnnnn convention except with a different range of MD file numbers (the 'nnnn' of MDXXnnnn), or by renaming them to something more descriptive. The McIDAS ADDE server mapping table utility DSSERVE can use the DIRFILE= keyword construct for MD files (and GRID files, I might add) in the same way that folks are used to using it for imagery. So, I suggest you investigate creating a new POINT dataset (e.g., PTSRC/SFCHOURLY instead of RTPTSRC/SFCHOURLY) whose elements are the renamed MDXX0104 - MDXX0108 files. You could even include the realtime file (the one currently being written to by the XCD data monitor DMSFC) by creating a link (soft if on different file systems; hard if on the same file system) to it using the same naming convention that you decide on for the other files. > thanks, No worries. Again, sorry for the late reply. Cheers, Tom **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: FKB-492129 Department: Support McIDAS Priority: Normal Status: Closed