<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.6.2">
</HEAD>
<BODY>
I confirm a bug in 2.0d1 and provided detail for all?<BR>
This command is documented as NOT-OK in a Maiko posting on making HF connects.<BR>
The "should be" conditions are documented by myself in "JNOS Owners Manual" along with the bug note.<BR>
<BR>
I issued a "c ptcpro ve4klm" from administrator status display.<BR>
The result I expected was "NO connect" because power is set to < 10 watts & propagation is bad...<BR>
<BR>
The display immediately switched into session #1 blank with "telnet" shown as the session command.<BR>
The xcvr immediately did the 50-second dance with the connect frame for pactor (I believe / did not listen).<BR>
This seems normal expecting to enter "chat mode" after connecting to ve4klm...<BR>
<BR>
After ? minutes the status line #3 returned to "0 command:", and line #1 "Ses: 1 >blinking<"...<BR>
But the session #1 screen (lines 4 thru 24) remained empty, and did nor return to session #0.<BR>
The session display never provided output nor permits a termination.<BR>
<BR>
The "ctl-]" toggles nicely from session #1 to session #0, <BR>
The "F10" toggles nicely from session #1 to session #0, <BR>
The "+++<CR>" does not respond from session #1,<BR>
The "<cr>" from session #0 toggles nicely to session #1 as the current session,<BR>
The "...> look 1" from session #0 responds 'User socket error!' that is no surprise to me...<BR>
The "session" cmd from session #0 displays the session #1 and shows it in "limbo".<BR>
all like they should?<BR>
<BR>
While session #1 blinks and behaves badly, I tried "c vhf n8yjt via pix" using a std KISS TNC.<BR>
This action progressed normally and terminated after not reaching the target station.<BR>
The session #2 terminated normally and jnos returned to sesion #1 blinking.<BR>
<BR>
SO - my interpretation is:<BR>
JNOS has data to pass to session #1 but OOPS session #1 has been aborted and can not receive the data.<BR>
JNOS did not totally abort session #1 because it continues to allow toggles back and forth (etc).<BR>
Other sessions can be opened, used, and terminated, without harm from the buggy session.<BR>
<BR>
I've attached a log extract to demonstrate JNOS process at that time.<BR>
I find no work-around used to "kill" session #1 and get rid of the body...<BR>
Therefore I will restart jnos soon to clear the bug and go on...<BR>
<BR>
Please note I authored a similar report last Wed 3/1 from the BBS command & Maiko responded that the code is still experimental for this function. He also provided a work-around for mail transfer.<BR>
Please also do NOT use this note to expedite a bug fix - it will be repaired in it's own time (just like good wine).<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>