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 Don, re: > Thanks for the info. Sorry for the delay in responding, but > I'm at the ESIP meeting in Portland this week. No worries. > How is a dataset defined as an "archive" dataset? This is reall funky... An archive dataset is characterized by an RT=A setting in a RESOLV.SRV entry. The problem is that DSSERVE does _not_ support the specification of RT=A on the command line. Here is an illustrative example: DSSERVE ADD ARCHIVE/GE4KIR AREA TYPE=IMAGE DIRFILE=IR_(YYYY)(DDD) RT=A "TEST CREATION OF ARCHIVE DATASET You must specify either YES or NO for REALTIME= DSSERVE: done DSSERVE failed, RC=2 So, one must create a RESOLV.SRV entry using RT=[YN] and then edit it to change the [YN] to an A! re: general upgrade to several ADDE servers > This will be very useful, so thanks for taking it on. The work is now in progress. My intention is to enhance code that Scott L. wrote for the archive dataset support. Interestingly, his work was very restrictive on when very limited replaceables would be used: - if RT=A in a RESOLV.SRV definition (and this must be done by hand) - if DIRFILE= contains (YYYY), (yyyy), (DDD), or (DDD) The second condition means that the dates used in an archive dataset are limited to using years and Julian days. My enhancements will allow use of any date/time specification supported by the C 'strftime' function. This is what I used in the ldm-mcidas package. re: no data in a dataset just after 0Z when data files are organized by day > I got hit by this yesterday, just before my demo. I set up > a bundle of the latest 5 IR images and the latest 10 radar > images over portland that I was going to use for my demo. > Just before the session started, I tried to load the bundle > and it turned out to be just after 00Z, so I got squat. > Luckily, by the time I gave my demo in the session an hour > later, the data had updated. But, there was a bit of panic > there for a while. ;-) Yea, been there done that :-( Hopefully, I can come up with an elegant (as opposed to hardwired/kludgy) solution for this problem. 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: WLV-393485 Department: Support McIDAS Priority: Normal Status: Open