The mult check has had this problem with IARU for a very long time. With
Cabrillo the mult check has become a moot point anyway, since Cabrillo
files contain raw QSO data and not whether or not a QSO represents a
multiplier. Even dupes don't matter anymore.
The best way to get the most accurate picture of your score if you have
made edits to the log along the way (during the contest or otherwise) is
to start TR using the rescore keyword (type "TR RESCORE") in the same
directory you ran the contest from. Sit back and wish you could type
that fast!! One warning is not to touch the keyboard until the job is
done. Once you hit a key the process stops and you have to start over.
--
73 es God Bless de KK1L...ron (kk1l@arrl.net) <><
QTH: Jericho, Vermont
My page: http://www.qsl.net/kk1l
Carolyn Gyger wrote:
> It isn't working for me yet. I now have 3 versions of IARUHQ.DOM. One has
> lines ending in 0D 0A, one ending in 0D 0D, and one ending with just 0D.POST
> terminates as soon as I hit "Y" to proceed irregardless of which version of
> the .DOM file I use. The files are all in the same directory as my CONFIG
> and DAT files (IARU05.CFG and IARU05.DAT), and POST picks up IARU05.DAT
> just fine. The dupe check works great, but the mult check still terminates
> abruptly.
>
> With only a few Qs I can do this one by hand, but it is worrisome for other
> contests and the IARU next year. I've done all the tricks I know with my hex
> editor, so I would sure appreciate some help. Thanks.
>
> Carolyn K0AN
>
> ----- Original Message -----
> From: "Paul Kirley" <pkirley@fuse.net>
> To: <trlog@contesting.com>
> Sent: Monday, July 11, 2005 11:15 AM
> Subject: [Trlog] Line endings in *.dom files
>
>
>
>>I also had "too many mults" when using POST after the IARU HF event. The
>>file IARUHQ.DOM was suspected to be the problem source.
>>
>>Tree sed:
>>
>>>Is there the possibility of missing carriage returns in the file?
>>>Maybe line feeds only?
>>
>>Jim VE7FO sed:
>>
>>>I had a look at the file with a hex editor and, indeed, every line ended
>>
>>in 0A (LF) instead of 0D (CR). I replaced all the 0A's with 0D's and
>>the problem is solved.
>>
>>Because I have a hex viewer but lack a hex editor, and so the ability to
>>replicate VE7FO's solution, I investigated further.
>>
>>Using Notepad to create a small text file by typing, and then viewing the
>>result in hex, I verified that the standard Windows line ending in hex is
>>"0D 0A" (without the quotes). I usually edit *.dom files in Windows, but
>>most of my edits are to true domestic files that don't get mult checked.
>>
>>My copy of IARUHQ.DOM (which generates the error message) also has line
>>endings of "0D 0A".
>>
>>My experiments with Word and other Windows editors have all failed to get
>>rid of the terminal "0A" character. Doubling the "^p" paragraph symbol in
>>Word produced "0D 0A 0D 0A" (to give "0A 0D" as the middle characters),
>>but that didn't help.
>>
>>Is it possible that POST is looking for the non-Windows line ending of
>>"0D" (or "0D 0D" as in VE7FO's edited version)? Or might the problem be
>>caused because the Windows ending "0A" effectively becomes the first
>>character of the next line?
>>
>>73, Paul W8TM
>>
>>_______________________________________________
>>Trlog mailing list
>>Trlog@contesting.com
>>http://lists.contesting.com/mailman/listinfo/trlog
>>
>
>
>
> _______________________________________________
> Trlog mailing list
> Trlog@contesting.com
> http://lists.contesting.com/mailman/listinfo/trlog
>
>
>
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|