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

[#WLV-393485]: archived datasets



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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.