To PCluster discussion group members:
 
Here is the original 'lookup' example I sent to Buckmaster as
part of my inquiry:
 
MR JA BUTTERY - G7OPJ
38 WIGMORE GARDENS WORLE WESTON SUPER MARE
AVON UK,  BS229AQ  C50^W9RNF^0^H9zkrhB)B)f)   <-------
                   ========================
 
Dan Bateman of Buckmaster was kind enough to respond with the
following remarks.  73/Ted (W8KVK)
 
---------------
 
Hello Ted,
 
I don't think BuckTSR could be at fault, but anything is possible.
It hasn't changed since October 1995.
 
We have small test program called BUCKTEST.EXE that will perform a
callsign lookup using the BuckTSR and return it to STDOUT (a DOS window).
This is a good way to see exactly what BuckTSR returns to the calling=
program.
 
Here is how you use it:
 
BUCKTEST R: 102 G7OPJ
 
The R: is of course the CD-ROM drive letter, and the 102 is the interrupt
number in decimal.  Most people won't have to change the 102 unless you
for some reason install BuckTSR on a different software interrupt.
 
This is what I get when I look up G7OPJ from our March 8, 1999 HamCall
(the delimiters in the data won't look quite right being pasted from
a DOS window into Eudora).
 
C:\dan\hamcall\BUCKTSR\DEBUG> bucktest r: 102 g7opj
TSRTest:  Parsing command line...
TSRTest:  Drive letter: R
TSRTest:  Interrupt: 102  (66h)
TSRTest:  Callsign: G7OPJ
TSRTest:  Calling BuckTSR to set drive letter...
TSRTest:  Back from BuckTSR...
TSRTest:  Calling BuckTSR to set string address...
TSRTest:  Back from BuckTSR...
TSRTest:  Calling BuckTSR to look up G7OPJ
TSRTest:  Back from BuckTSR...
TSRTest:  Data returned:
=A6G7OPJ+A+MR JA=A6BUTTERY+38 WIGMORE GARDENS WORLE WESTON SUPER MARE+AVON
UK-BS229AQ+19981002=A6
 
It looks like you're getting all of the data that we have, but just with
extra garbage.  Maybe you could try the BUCKTEST.EXE as well, just to
confirm my results.
 
At first when I saw the garbage I thought that maybe the author of
PacketCluster wasn't clearing his string that we put the callsign data
into.   But BuckTSR explicitly puts ASCII 32 (spaces) between the end of
the callsign data the the NULL at the end of the string.  So, that
shouldn't be a problem.
 
I'm not sure what can be done, but a few questions come to mind:
 
1.  Is this garbage problem the same on EVERY machine running PacketCluster?
2.  Are there any calls that do not have garbage?
3.  Try G0ABI, this call has an e-mail address at the end.
    Does the garbage look different?
 
Hopefully some of this will trigger an idea.
 
Regards,
 
Dan Bateman
Buckmaster Publishing
(800)282-5628           (540)894-5777       (540)894-9141 (FAX)
batemand@buck.com