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

20010421: Thoughts on LDM reclasses

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.

  • Subject: 20010421: Thoughts on LDM reclasses
  • Date: Sun, 22 Apr 2001 12:14:45 -0600

I just looked at src/protocol/ldm.h. I noticed that UNIDATA is now = 47.
It used to be 63. The rational for subtracting SPARE(16) out of
UNIDATA was to prevent accidental passing of data when SPARE was used.
That made sense. We weren't using SPARE, so why include it.

I was just wondering what would happen if a site was running
LDM 5.0.10+ which was ALLOWING 47 (UNIDATA), and a site with an older
LDM version was requesting 63 (Old UNIDATA). My assumption here is that the
upstream would have to reclass the requested pattern. If that were the case, 
the upstream would probably be better ALLOWING UNIDATA|SPARE or even ANY.

Now, does this match what we are seeing with Brockport to U-M Lowell?
That might be the case if Brockport were running the current 5.1.3
and Lowell was running a pre-5.0.10 version. I looked at the latency.input
logs and UML is running 5.0.8. Brockport is running 5.1.3.

From the ALLOW lines you sent to support yesterday, it appears that you are
ALLOWING UNIDATA|FSL2 to uml. Can you change this to UNIDATA|SPARE|FSL2
(or ANY temprarily) sao as to test whether this makes a difference in your
reclasses? Of course, that means you need uml to be feeding from you at that
point.

Chiz


Steve Chiswell
Unidata User Support