Hi David,

I've been watching this thread with interest.  Still running stock 2.60 DOS
under DV here, but I do have a hunch ..

 DN> On Tue Nov 24, 1998, Craig Ford wrote in a message to David Nyquist:

 CF> It is a known (and mostly cosmetic) problem. BTW, check your logs
 CF> closely, you'll see that it doesn't happen all of the time
 CF> (especially not with other systems running Binkleyterm).

 DN> Well it happens all the time on outgoing connects.  Here is
 DN> a snippet of a system that's running Intermail.

Does it EVER happen on inbound connects?

 DN> : 25 Nov 00:58:17.10 BINK Dialing 532-4367 (199:1/1 -- MILKY WAY)
 DN>   25 Nov 00:58:40.39 BINK 'CONNECT 26400/ARQ/V34/LAPM/V42BIS'
[..]
 DN> : 25 Nov 00:58:44.07 BINK Session method: ZedZap
 DN> + 25 Nov 00:58:45.17 BINK CPS: 565 (464 bytes)  Efficiency: 17%
 DN> + 25 Nov 00:58:45.17 BINK Sent-Z/32 H:\GAMES\BRE\OUTBOUND\199B0201.129
 DN>   25 Nov 00:58:45.22 BINK File
 DN> H:\GAMES\BRE\OUTBOUND\199B0201.129 deleted.
 DN> + 25 Nov 00:58:46.72 BINK CPS: 529 (233 bytes)  Efficiency: 16%
 DN> + 25 Nov 00:58:46.72 BINK Sent-Z/32 H:\binkley\outbound.0c7\009803be.we0
 DN>   25 Nov 00:58:46.83 BINK File
 DN> H:\binkley\outbound.0c7\009803be.we0 truncated.
 DN> * 25 Nov 00:59:03.80 BINK Lost Carrier.
 DN>                           ^^^^^^^^^^^^^^^

That's about 17 seconds after the end of business.  A fair delay, but one
that's not uncommon with Frontdoor and Intermail systems, in my experience;
I've often sat here wondering 'what's his mailer waiting for, then?'

 DN> * 25 Nov 00:59:06.87 BINK End of WaZOO/EMSI Session.

Another 3 seconds till Bink knows that ZedZap's done.  Again, not uncommon.

 DN>   25 Nov 00:59:07.52 BINK Received: 0/0K Sent: 2/1K Total: 2/1K CPS: 23
 DN> * 25 Nov 00:59:08.52 BINK Seconds: 30  Tariff: 0  Fee: 0
 DN> RFee: 0  System: 199:1/1

 DN> As you said it is a cosmetical problem.  There is no
 DN> serious problems taking
 DN> place.  I just thought I would bring it out in the open for
 DN> the XE team to fix.

It looks to me that in saying 'cosmetic', XR6 DOS is just reporting a
message that is usually suppressed, that is, the sessions referred to
having appeared to terminate normally, with all files properly sent and
received, then Bink is reporting the loss of DCD often associated with the
end of a session, where either end can wind up winning the 'race' to hangup
first.  The ZedZap specs don't enforce either end quitting first, which
some people have found odd.

I'm used to looking at FOSSIL buffer dumps after various calls, and most of
my recent modems have also shown Termination Reason in the AfterCall modem
stats as either Link Disconnect (the other end hungup first) or Local
Request (my end did) with more or less even odds to other Bink systems, XR
and 'classic'.

Some other systems (such as Frontdoor and Intermail) seem to use a
different timeout, hanging onto the line rather longer after the business
is all done.

So unless there's any suggestion of sessions ending prematurely, before all
the work's been done, it seems to be really just a bit of extra reporting.

There's a chance it might occur more frequently if you have your modem
setup to do longer 'cleardown' on loss of DTR at your end; I've seen some
that seem to take ages, maybe an extra 20 seconds or so, compared to those
configured to do fast cleardown, so those would regularly lose the 'race'
to quit first, but apart from that, be happy if your sessions are getting
the mail ok .. :)

Cheers, Ian

--- MaltEd 1.0.b5