> >I think for the ZL4 example we might do
> >
> >ZL = New Zealand, with general co-ordinates of ZL
> >ZL1 = blah, with more specific co-ordinates, zone etc
> >ZL2 = blah, with more specific co-ordinates, zone etc
> >...
> >with no record for ZL4 (so the program would fall back to the ZL record).
>
Good scheme.
CTY.DAT doesn't contain sub-entity info ("VK6 is in zone 29" etc) so that
info would have to come from somewhere else. But it's good to have the
facility designed in.
> Any ZL can now be in any ZL sub-entity, and this has been the case for a
> number of years. Until recently (~18 months ago) I had a ZL3 call (ZL3LH),
> and was living here in ZL2 for more than 10 years before changing to my
> "vanity" call of ZL2DEX.
Yes. The ZL4 was just an example. Any ZL could be *anywhere* in the
country.
No big deal, because all of ZL is in the same CQ and ITU zones. But that
becomes a problem for the US prefixes.
I see CT still makes the assumptions about this and says K9XY is in CQ
zone 4.
Hence my suggestion to add another column to the table that flags countries
like ZL, W etc as being prefix non-specific and VK as being OK for deducting
the zone from the prefix. So, if you work VK6AB you *know* he is in zone
29, if you work K9AB he *may be* in zone 4.
Pity about the CLX db.
The latest ARRL DXCC list doesn't show the Chesterfields (TX0), the latest
CTY.DAT does. Although the ARRL is the ultimate source, CTY.DAT is
probably more useful and more up-to-date?
However, the ARRL DXCC list has some additional info: whether the ARRL
QSL bureau will handle cards to that entity, and whether 3rd party traffic with
that entity is OK, of possible interest to US ops.
Wilbert ZL2BSJ
