Hi Fabian & Group,

Very interesting indeed and works FB. Noticed an "Internal Server Error"
when prefix is not found. But realize you put it working quickly. Thanks.

The primary prefix is not neccesarily included in the list for all
prefixes because it might be a subset of the 'all prefixes' list.

FB, understand about the "D" and even Eu Russia. Here are the ones I was
thinking about:
below do not include "primary prefix" in alts list, as others
Easter I.: 12: CE0Y:
Malpelo I.: 09:
Argentina: 13: LU:
Macquarie I.: 30: VK0M:
Norfolk I.: 32: VK9N:
South Shetland: 13: VP8/h:

BELOW doesn't have either primary in alts list
Antarctica: 13: CE9:
----

The algorithm is to look for the longest matching prefix;

So am guessing this is how you handle the entire call in the cty.dat file
when the call is not in "home" area.

The full calls in the list, of course, serve very well for its intended
purpose - contesting and loggers. However, they work not at all for a true
"prefix search". i.e. when a user types prefix then there is a conflict
between the true country prefix and the call not in home area.
For example:
France: 14: F: 4U1SCO...
--
user types 4U1, -- and no more -- does he get ITU or does he get France?
Yes, he would want ITU, but of course depends on how code is written?

OK, I admit it, I've been working on how to do prefix lookup for years.
Many, many folks on here more capable than me. G

It seemed the real best prefix search would be using the international
allocation list. But that isn't so good either. Thus the cty.dat type lists
of active prefixes is superior in many ways.

Thanks,
Jim - KU5S
--
email sent to:
is discarded without being seen.
Sorry for any inconvenience.