RES file wrapup and solution
Jay O'Brien - W6GO
Fri, 8 Dec 1995 22:40:59 -0800 (PST)
Thanks to all for your comments about the RES file format used in
CT. I can't believe all the logging programs have so many devoted
followers! Most of the responses suggested that I use the logging
program they love, as it already does what I was asking for. I am
happy that you are all pleased with your programs. When I published
the GOLIST in disk format, I worked with most of the programmers of
your programs when they built in support for my database. They are
great folks who put their customers first.
Also thanks to those of you who shared your utilities for
extracting data from the BIN files.
I have concluded, based on your inputs and my experimental
verification, that the RES file is not a "common denominator"
between contests. All the information is there, but things change
from contest to contest. Also, some of the data is not clearly
defined, but could be determined experimentally. I have concluded
that there is not a format which will provide ALL of the data from
ALL of the contests in a consistent manner. Further, there is no
guarantee that RES files will be the same in the future.
Given that, I conclude that I already have the "common denominator",
but it only contains what is needed to print a QSL, which covers my
original reason for posting my query. That's also enough to build a
logging database. It doesn't contain exact frequencies from your
radio or some of the data received, like sweepstakes Check and
Section, but if you should need that information for a specific QSO
you can always look at the RES file for that contest and pull out
When I was "premptively QSLing", I used K1EA's QSL Utility
Program which is supplied with CT. It is a great program, in that
it reads the BIN file and spits out a file which prints labels for
QSLs, sorted by country. It also creates a MASTER.QSL file. When
you process the next contest, MASTER.QSL is consulted and if you
have already sent a QSL to a callsign for a particular band for a
previous contest, it doesn't make another label.
At my request some years ago, K1EA added a -w6go switch to his
QSL program which places the QSL label file (.LAB) information into
a "flat ASCII" database instead of the format which will directly
print labels. I then imported the data into a Paradox database and
compared it with my QSL Manager list database, so I could delete
those QSLs that went to a manager. I was only premptively QSLing to
stations who were likely to send me cards via the bureau, so this
was a logical step for me, as I had the manager database on hand.
Then, from Paradox, I created the labels and sent the cards to the
outgoing bureau. It worked great for me at the time.
I will continue to use the switch K1EA put in for me (Thanks,
Kenny!) and use CT's QSL program. I don't really need all that
other information anyway. However, I will now run the QSL program
without a MASTER.QSL file present, so that all QSOs will have
records placed into the file I will then import into my QSL database
in Paradox. I will now respond to cards received via the bureau,
rather than send QSLs first, and the Paradox database will provide
quick access to all QSOs.
CT's QSL program is described in the CT Manual, under utility
programs. Run the QSL program once to see the label format (LAB
file), then run it again with the -w6go switch and you will see the
ASCII format. Unfortunately, it uses the (old) CQWW.CTY file to look
up countries, not CTY.DAT. Maybe that will be a CT version 10
To wrap up, I already had the answer to my question before I
asked it! For those of you who asked me to share my findings, the
format of the LAB file made with the -w6go switch is as follows:
CALLSIGN QSODATE QSOTIME BAND MODE QSOREPORT COUNTRY CONTEST. One
QSO per line, and TAB characters are used as field separators.
Administrative requests: ct-user-REQUEST@ve7tcp.ampr.org