Last week, current CQ DX Marathon award manager John K9EL and next year's CQ DX Marathon award manager Mark WC3W show me their
analysis that shows a significant number of logged QSOs specify the wrong CQ zone. The source of these erroneous CQ zones? An
incorrect CQ zone in the callsign's QRZ Callbook entry.

Recall that to minimize the loss of points, each QSO logged in DXKeeper has a "Country Risk" item and a "Zone Risk" item that are
initialized to "nominal risk". If you are uncertain about the validity of a logged QSO, you can set its "Country Risk" and "Zone
Risk" items to "H" (for "high"). If a QSO is confirmed, you can set its "Country Risk" item and a "Zone Risk" items to "L" (for
"low"); there's an option that does this automatically. When you direct DXKeeper to generate a Marathon submission, it first
considers QSOs with Low risk items, then it considers QSOs with nominal risk items, and finally it considers QSOs with High risk
items. Using this mechanism to flag high-risk and low-risk QSOs reduces the probability that you will lose Marathon points.

John and Mark's report motivated me to extend the next version of DXKeeper to detect erroneous CQ zones, using two of DXLab's
databases:

1. The USAP database knows the U.S. State or Territory of each station issued by the Federal Communications Commission; each U.S.
State and Territory lies entirely within one CQ zone.

2. The DXCC database knows the CQ zone of every DXCC entity that fits entirely within one CQ zone, and of some "regions" identified
by callsign that fit entirely within one CQ zone (example: the European Russian Oblast of Ivanovo)

In this next DXKeeper version, the Marathon Progress Report and Marathon Submission generators will report any QSO whose CQ zone is
inconsistent with information reported by the above two databases; if such a QSO's "Zone Risk" item is set to "nominal", it's "Zone
Risk" item will be changed to "High".

Testing this new version identified a long-latent error in the DXCC Database: Indonesian stations whose callsigns are in the range
YB7A to YB7G erroneously specify a CQ zone of 38 instead of 28. In response, Joe W4TV - in the middle of his second hurricane in
less than six weeks - assembled DXCC Database version 2.6.2, which corrects this CQ zone error, along with several other corrections
and improvements - as described in this release note:

www.dxlabsuite.com/dxview/DXCC/DXCC-2.6.2.htm

Step 4 of this release note provides instructions for downloading and running a DXKeeper script that will correct any logged QSOs
with Indonesian stations that specify the wrong CQ zone, and that will correct any logged QSOs with Cocos Island (TI9) stations that
specify the wrong ITU zone. The release note explains how to direct DXKeeper and then SpotCollector to "recompute" after running
this script, updating your realtime award tracking for Marathon and WAZ.

More testing is required before I release the new version of DXKeeper, but you can update your DXCC database to version 2.6.2 and
run the FIX_YB_TI9_Zones.txt script as soon as you wish. Simply follow the step-by-step instructions in the release note:

www.dxlabsuite.com/dxview/DXCC/DXCC-2.6.2.htm

Many thanks to Joe W4TV for his continuing support of DXLab's most important database!

73,

Dave, AA6YQ

+ AA6YQ comments below

I've asked this before, and I'm still not sure what the answer is --

What if the other op is running portable, like POTA? I'm getting lots of popups already telling me my log shows a station in CT, for example, when his LoTW entry show, perhaps Texas. It's starting to get confusing.

+ The only certain way to obtain the accurate details of your QSO partner's location -- like his or her CQ zone -- is to ask during the QSO. If I drive to Chicago tomorrow and start making QSOs, no database on the planet will be able to tell you that I'm in CQ zone 4, rather than my "home CQ zone" of 5.

+ DXView's Override mechanism, which can be populated manually, and updated from Club Log and from Jim AD1C's BigCTY database, will help with situations in which you, or Club Log, or Jim have become aware that, say, K5D is going to be operating from K5D, which is in CQ zone 8. See

https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride

+ LoTW confirmations are a source of location information, but they are not always accurate. Some ops use the wrong "Station Location" when submitting a QSO to LoTW; some ops have their CQ and ITU zones reverse in their "Station Location".

73,

Dave, AA6YQ

In the message appended below, I meant to say

" DXView's Override mechanism, which can be populated manually, and updated from Club Log and from Jim AD1C's BigCTY database, will help with situations in which you, or Club Log, or Jim have become aware that, say, K5D is going to be operating from Desecheo Island (KP5), which is in CQ zone 8."

      73,

             Dave, AA6YQ