staceyc@sco.COM (Stacey Campbell) (03/01/91)
In article <1504@rascal.UUCP> theo@rascal.UUCP (T. Kramer) writes: >In article <10248@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >>You must define an acsc string for your terminal. > >Unfortunatly ACS is not portable across UNIX V.2, XENIX V.2 etc. This is >however, a strict requirement for our code. ACS_ macros work fine on both Xenix 2.3.2 (and later) and SCO Unix with the proviso I mentioned in the previous post that the Xenix tic command does not grok acsc in terminfo source files; in which case use the Unix tic and transport the ticced file back to Xenix. Some SCO products are now moving to curses color, so we develop on Unix and ship the color applications and color terminfo files for Xenix. >I would agree with you >that if I used the ACS_ defines I would not need (w)attron and (w)attrof, >but because our code must be portable including, hopefully, our terminfo >source files I can not depend on ACS_ defines. I've developed a fair bit of public domain code that compiles on BSD, System V.2, V.3.0, and V.3.2 curses and have come to the conclusion that it is very important to follow the manual for System V.2 and System V.3.[0-2] curses. Trying to fake out the ACS_ characters to maintain code portability with non-System V curses can be done, but because non-System V curses doesn't have a generally recognized way of storing ACS information, you will have to develop a system that works for every single terminal you plan on supporting. I usually find myself writing the following code; #ifdef ACS_HLINE box(win, 0, 0); #else UseCruftyBoxHack(win); #endif If you aren't willing to use ifdefs or use a seperate source pool (as seems to be the case) then adding, for example, color to a curses portable application becomes near impossible. >>"REMEMBER THAT sgr AND sgr0 MUST ALWAYS BE SPECIFIED". > >I need the call to (w)attrof as in my actual code I need to output >normal character information after for example having painted a box on >the screen. If you absolutely must use non-standard methods to put alternate characters on your screen then wattron() and wattroff() _will_ do what you want. >The point of my request for >help, however, is why does SCO Opendesktop Development System curses >not output an \E% or \E%% or \E\% but does output AA and BB and \E$ and ... >for the (w)attroff call? I seriously believe that this is a serious bug >in the curses package which makes it difficult if not impossible for me, >and I am sure many others who have selected curses for portability, to >generate production binaries using the SCO UNIX and Opendesktop development >systems! Which prompted me to go back to your original post and try out your program and terminfo file again. :-) The reason the qvt101+so entry is failing isn't exactly glaring, but once you see it all becomes clear. Your qvt101 entry contains the numeric capability xmc#0. The guy who wrote System V.3.2 curses claims that it deals with magic cookies correctly (he posts occasionally to Usenet), though I have yet to see a scrap of documentation that explains what is required of the terminfo file and the curses program (obviously something, otherwise your program would work). I am somewhat confused by the 0 in xmc#0, the manual says the numeric value to xmc is the "number of blank characters left by smso or rmso". If this value is zero then it would seem that there is no magic cookie required, therefore xmc should be removed. Perhaps the 0 is special. Either way, if xmc#0 is removed from the qvt101+so terminfo file the program will emit rmacs. The curses source implements in a number of places; if (! magic_cookie_glitch) turn_off_attributes(); I've added comp.unix.programmer to the Newsgroups line because I know there's some folks there who have dealt with this problem. A simple way to fix the problem is to see if your terminal supports _any_ attributes without magic cookies, then remove xmc and set smso and rmso to that attribute, for Wyse 50s I think this attribute is protected mode. Here is a program that demonstrates the problem; #include <curses.h> int main() { int index; int y, x; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } Here's the original terminfo file (with acsc and sgr0 added); # Terminfo source code for my (theo's) qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
@usaos.uucp (03/01/91)
Xref: xenitec comp.terminals:1825 sco.opendesktop:592 comp.unix.programmer:1163 Keywords: qvt101, freedom100, curses Message-ID: <10513@scolex.sco.COM> Date: Thu, 28 Feb 91 20:26:18 GMT References: <1502@rascal.UUCP> <10248@scolex.sco.COM> <1504@rascal.UUCP> Sender: news@sco.COM In article <1504@rascal.UUCP> theo@rascal.UUCP (T. Kramer) writes: >In article <10248@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >>You must define an acsc string for your terminal. > >Unfortunatly ACS is not portable across UNIX V.2, XENIX V.2 etc. This is >however, a strict requirement for our code. ACS_ macros work fine on both Xenix 2.3.2 (and later) and SCO Unix with the proviso I mentioned in the previous post that the Xenix tic command does not grok acsc in terminfo source files; in which case use the Unix tic and transport the ticced file back to Xenix. Some SCO products are now moving to curses color, so we develop on Unix and ship the color applications and color terminfo files for Xenix. >I would agree with you >that if I used the ACS_ defines I would not need (w)attron and (w)attrof, >but because our code must be portable including, hopefully, our terminfo >source files I can not depend on ACS_ defines. I've developed a fair bit of public domain code that compiles on BSD, System V.2, V.3.0, and V.3.2 curses and have come to the conclusion that it is very important to follow the manual for System V.2 and System V.3.[0-2] curses. Trying to fake out the ACS_ characters to maintain code portability with non-System V curses can be done, but because non-System V curses doesn't have a generally recognized way of storing ACS information, you will have to develop a system that works for every single terminal you plan on supporting. I usually find myself writing the following code; #ifdef ACS_HLINE box(win, 0, 0); #else UseCruftyBoxHack(win); #endif If you aren't willing to use ifdefs or use a seperate source pool (as seems to be the case) then adding, for example, color to a curses portable application becomes near impossible. >>"REMEMBER THAT sgr AND sgr0 MUST ALWAYS BE SPECIFIED". > >I need the call to (w)attrof as in my actual code I need to output >normal character information after for example having painted a box on >the screen. If you absolutely must use non-standard methods to put alternate characters on your screen then wattron() and wattroff() _will_ do what you want. >The point of my request for >help, however, is why does SCO Opendesktop Development System curses >not output an \E% or \E%% or \E\% but does output AA and BB and \E$ and ... >for the (w)attroff call? I seriously believe that this is a serious bug >in the curses package which makes it difficult if not impossible for me, >and I am sure many others who have selected curses for portability, to >generate production binaries using the SCO UNIX and Opendesktop development >systems! Which prompted me to go back to your original post and try out your program and terminfo file again. :-) The reason the qvt101+so entry is failing isn't exactly glaring, but once you see it all becomes clear. Your qvt101 entry contains the numeric capability xmc#0. The guy who wrote System V.3.2 curses claims that it deals with magic cookies correctly (he posts occasionally to Usenet), though I have yet to see a scrap of documentation that explains what is required of the terminfo file and the curses program (obviously something, otherwise your program would work). I am somewhat confused by the 0 in xmc#0, the manual says the numeric value to xmc is the "number of blank characters left by smso or rmso". If this value is zero then it would seem that there is no magic cookie required, therefore xmc should be removed. Perhaps the 0 is special. Either way, if xmc#0 is removed from the qvt101+so terminfo file the program will emit rmacs. The curses source implements in a number of places; if (! magic_cookie_glitch) turn_off_attributes(); I've added comp.unix.programmer to the Newsgroups line because I know there's some folks there who have dealt with this problem. A simple way to fix the problem is to see if your terminal supports _any_ attributes without magic cookies, then remove xmc and set smso and rmso to that attribute, for Wyse 50s I think this attribute is protected mode. Here is a program that demonstrates the problem; #include <curses.h> int main() { int index; int y, x; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } Here's the original terminfo file (with acsc and sgr0 added); # Terminfo source code for my (theo's) qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
kpv@ulysses.att.com (Phong Vo[drew]) (03/04/91)
In article <10513@scolex.sco.COM>, staceyc@sco.COM (Stacey Campbell) writes:
:
: becomes clear. Your qvt101 entry contains the numeric capability
: xmc#0. The guy who wrote System V.3.2 curses claims that it deals
: with magic cookies correctly (he posts occasionally to Usenet),
: though I have yet to see a scrap of documentation that explains
: what is required of the terminfo file and the curses program (obviously
: something, otherwise your program would work).
:
He's about to do that again :-).
On terminals with magic cookies, you must define "xmg" for terminfo
(or "sg" for termcap) for curses to work correctly.
You do not need to do anything else.
: I am somewhat confused by the 0 in xmc#0, the manual says the numeric
: value to xmc is the "number of blank characters left by smso or
: rmso". If this value is zero then it would seem that there is no
: magic cookie required, therefore xmc should be removed. Perhaps
: the 0 is special. Either way, if xmc#0 is removed from the qvt101+so
: terminfo file the program will emit rmacs. The curses source implements
: in a number of places;
:
xmc defines two attributes: (1) the number of blanks left by smso&rmso,
and (2) the fact that characters output in the region between smso
and rmso will be hilited even if the cursor moves out of that
region, then moves back in for output. Attribute (2) is the reason for xmc#0.
It is common to the HP26* family of terminals.staceyc@sco.COM (Stacey Campbell) (03/07/91)
In article <14405@ulysses.att.com> kpv@ulysses.att.com (Phong Vo[drew]) writes: >In article <10513@scolex.sco.COM>, staceyc@sco.COM (Stacey Campbell) writes: >: becomes clear. Your qvt101 entry contains the numeric capability >: xmc#0. The guy who wrote System V.3.2 curses claims that it deals >: with magic cookies correctly [...] > >On terminals with magic cookies, you must define "xmg" for terminfo >(or "sg" for termcap) for curses to work correctly. >You do not need to do anything else. Now we enter deep water. There is no mention of xmg in either the AT&T 3.2.0 source or AT&T 3.2.1 source. tic definitely doesn't like it. Do you mean xmc? I've compiled the following program with the stock AT&T 3.2.1 curses source and with xmc#0 and xmc#1 and it does not emit the sequence to turn off smacs (either sgr0 or rmacs). Is this a bug in the C example (probably not), terminfo file (maybe, I've never written a magic cookie terminfo file, though it looks okay), or in libcurses.a? Comments? #include <curses.h> int main() { int index; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } The terminfo file; # Terminfo source code for theo's qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
jim@segue.segue.com (Jim Balter) (03/07/91)
In article <10513@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >The guy who wrote System V.3.2 curses claims that it deals >with magic cookies correctly (he posts occasionally to Usenet), There are a couple of significant bugs related to magic cookies. One is that, after clearing to end of line it drops a cookie at the beginning of the cleared area but forgets it did so due to bad parenthesization. Another is that any change video attributes also forces changing color attributes, which isn't necessary, at least on HP terminals (which are the only cookie terminals supporting color that I know of). curses forgets that the color cookie was dropped, due largely to bad code organization. >though I have yet to see a scrap of documentation that explains >what is required of the terminfo file Other than setting xmc appropriately, what should be required? >and the curses program I don't think curses programs need to know anything, other than that the output may look horrible on xmc#1 terminals. >I am somewhat confused by the 0 in xmc#0, the manual says the numeric >value to xmc is the "number of blank characters left by smso or >rmso". If this value is zero then it would seem that there is no >magic cookie required, therefore xmc should be removed. Perhaps >the 0 is special. xmc#0 means that cookies take no space but that the terminal is still magic-cookie-like. For xmc terminals, setting an attribute affects the current cursor location and all locations to the right of it up to the next magic cookie. For xmc#1 terminals, the magic cookie actually takes up a screen location. For non-xmc terminals, setting an attribute sets a state which affects all subsequent output until the next attribute setting. >The curses source implements >in a number of places; > > if (! magic_cookie_glitch) > turn_off_attributes(); Actually, the test is usually magic_cookie_glitch >= 0; magic_cookie_glitch is < 0 if it wasn't specified in the terminfo file. This is understandable from the above. If !xmc, turning off attributes turns them off for subsequent output. If xmc, this would turn them off at the current cursor location, which not what is wanted. It turns out that there are other glitches in the code where this distinction for xmc terminals isn't made, because the magic cookie stuff was obviously grafted onto (rather than integrated into) some already badly organized code.
jim@segue.segue.com (Jim Balter) (03/07/91)
In article <14405@ulysses.att.com> kpv@ulysses.att.com (Phong Vo[drew]) writes: >On terminals with magic cookies, you must define "xmg" for terminfo >(or "sg" for termcap) for curses to work correctly. You mean "xmc" of course ("sg" is right for termcap).
peter@ficc.ferranti.com (Peter da Silva) (03/07/91)
Some televideo-braindamage style terminals allow you to set the attribute character width to 0, allowing you to write a character in the magic cookie cell. So the magic cookies don't show up on the screen but still do weird stuff like set the rest of the screen to the attribute. Try turning "ms" off and "xs" on. In terminfo, that means you must disable "move_standout_mode" and enable "ceol_standout_glitch". -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
kpv@ulysses.att.com (Phong Vo[drew]) (03/08/91)
In article <10625@scolex.sco.COM>, staceyc@sco.COM (Stacey Campbell) writes:
:
: Now we enter deep water. There is no mention of xmg in either the
: AT&T 3.2.0 source or AT&T 3.2.1 source. tic definitely doesn't like it.
: Do you mean xmc? I've compiled the following program with the stock
Yes, I did mean xmc.
: AT&T 3.2.1 curses source and with xmc#0 and xmc#1 and it does not emit the
: sequence to turn off smacs (either sgr0 or rmacs). Is this a bug in the
: C example (probably not), terminfo file (maybe, I've never written a
: magic cookie terminfo file, though it looks okay), or in libcurses.a?
: Comments?
:
Your test code looks ok. My own libcurses.a works ok though I haven't tried
your terminfo entry - I use termcap myself. I can't testify to system V
curses even though theirs is a descendant of mine.jim@segue.segue.com (Jim Balter) (03/09/91)
In article <10625@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >Do you mean xmc? Yes, he does. >I've compiled the following program with the stock >AT&T 3.2.1 curses source and with xmc#0 and xmc#1 and it does not emit the >sequence to turn off smacs (either sgr0 or rmacs). Is this a bug in the >C example (probably not), terminfo file (maybe, I've never written a >magic cookie terminfo file, though it looks okay), or in libcurses.a? >Comments? It's a bug in your expectations. curses is doing fine here. xmc#0 implies a cookie terminal, which is field oriented. The cookie program produces, with TERM=qp : sgr0 Thise is wrong but harmless in this case. It's a result of the field-oriented code being incompletely grafted onto code for state-oriented terminals. clear Clear da screen. cup(0,21) Go to the end of the field. rmacs Terminate the field, by turning off acs for the rest of the line. cr Go to the beginning of the field. smacs Start the acs field (columns 0-20). The field is ended before being started to prevent twice changing the state of the characters to the right of the field. lqqqqqqqqqqqqqqqqqqqk Place some characters into the acs field. This assumes the alternate characters for the qvt101 are the same as for the vt100. If not, the acsc capability must be set accordingly. RTF3.2M. cup(23,0) Go to bottom left corner. This should work properly on a real field-oriented terminal. If the qvt101 normally has field-oriented attributes but acs is state-oriented, then curses doesn't support it. But if acs is truly field-oriented, then there is no need for a final sgr0, because that wouldn't affect subsequent output. -- Jim Balter, Segue Software, Inc.
theo@rascal.UUCP (T. Kramer) (03/09/91)
In article <10513@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: > > ..... Trying to fake out the ACS_ characters to maintain >code portability with non-System V curses can be done, but because >non-System V curses doesn't have a generally recognized way of storing >ACS information, you will have to develop a system that works for every >single terminal you plan on supporting. I usually find myself writing >the following code; > >#ifdef ACS_HLINE > box(win, 0, 0); >#else > UseCruftyBoxHack(win); >#endif We have, in fact, done so. But thanks for the advice all the same, we will probably implement something like your suggestion in a following release :-) >I am somewhat confused by the 0 in xmc#0, the manual says the numeric >value to xmc is the "number of blank characters left by smso or >rmso". If this value is zero then it would seem that there is no >magic cookie required, therefore xmc should be removed. Perhaps >the 0 is special. Either way, if xmc#0 is removed from the qvt101+so >terminfo file the program will emit rmacs. Again, thanks very much for the advice, I have removed the xmc entry from my terminfo source and all works great, except and wait for it, every time I emit wattroff I get a '%' on the screen! Yes it does appear that the double percentage in the rmacs and sgr0 sequences are _not_ required! Sorry, it takes so long for me to respond. Lots of development pressures :-) Another problem that we have for curses is that we can not place an alternate character (not using ACS_ ) at the bottom right hand corner of the screen, This is for all terminals we use ie. SCO ansi, freedom 100, vt100, vt220, qvt101. +-------------------------------+--------------------------------------------+ | theo@rascal | And so the magic cookie crumbles | +-------------------------------+--------------------------------------------+
theo@rascal (03/10/91)
Xref: xenitec comp.terminals:1863 sco.opendesktop:621 comp.unix.programmer:1233 Keywords: qvt101, freedom100, curses Message-ID: <1508@rascal.UUCP> Date: Sat, 09 Mar 91 13:05:16 GMT References: <1502@rascal.UUCP> <10248@scolex.sco.COM> <1504@rascal.UUCP> <10513@scolex.sco.COM> Reply-To: theo@rascal.UUCP (T. Kramer) Followup-To: comp.terminals In article <10513@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: > > ..... Trying to fake out the ACS_ characters to maintain >code portability with non-System V curses can be done, but because >non-System V curses doesn't have a generally recognized way of storing >ACS information, you will have to develop a system that works for every >single terminal you plan on supporting. I usually find myself writing >the following code; > >#ifdef ACS_HLINE > box(win, 0, 0); >#else > UseCruftyBoxHack(win); >#endif We have, in fact, done so. But thanks for the advice all the same, we will probably implement something like your suggestion in a following release :-) >I am somewhat confused by the 0 in xmc#0, the manual says the numeric >value to xmc is the "number of blank characters left by smso or >rmso". If this value is zero then it would seem that there is no >magic cookie required, therefore xmc should be removed. Perhaps >the 0 is special. Either way, if xmc#0 is removed from the qvt101+so >terminfo file the program will emit rmacs. Again, thanks very much for the advice, I have removed the xmc entry from my terminfo source and all works great, except and wait for it, every time I emit wattroff I get a '%' on the screen! Yes it does appear that the double percentage in the rmacs and sgr0 sequences are _not_ required! Sorry, it takes so long for me to respond. Lots of development pressures :-) Another problem that we have for curses is that we can not place an alternate character (not using ACS_ ) at the bottom right hand corner of the screen, This is for all terminals we use ie. SCO ansi, freedom 100, vt100, vt220, qvt101. +-------------------------------+--------------------------------------------+ | theo@rascal | And so the magic cookie crumbles | +-------------------------------+--------------------------------------------+
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/15/91)
As quoted from <9103100200.aa15841@xenitec.on.ca> by theo@rascal: +--------------- | Again, thanks very much for the advice, I have removed the xmc entry from | my terminfo source and all works great, except and wait for it, every time | I emit wattroff I get a '%' on the screen! Yes it does appear that the double | percentage in the rmacs and sgr0 sequences are _not_ required! +--------------- Correct. You need only use a double % when the sequence is parameterized; see the terminfo man page. In particular, "sgr" is parameterized but "rmacs" and "sgr0" are not. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR on 40m, 10m when time Internet: allbery@NCoast.ORG permits; also 2m, 220, 440, 1200 America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH