Greg writes:

> The reason for our desire to disallow user-initiated disconnection via the
>  terminal emulator, as opposed to logging-out of the application cleanly
>  and then closing the emulator, is to prevent data corruption and to do
>  a bit of end-of-session work (cleanups, statistics logging, etc).
>
>  Every so often, a couple of times a year, we get a data corruption from
>  a session not closing cleanly. This causes downtime of around 2 hours
>  while we recover the database from backup & transaction logfiles. We
>  have had the occasional major drama when this recovery didn't work
>  fully, but that's another story.
>
>  I know that we'll still get a lot of disconnected sessions due to network
>  initiated inactivity timeouts and communications problems, but this will
>  stop a large number of the disconnections that we experience.
>
>  As far as "unkillable" emulator windows left after a network disconnection,
>  what I suggest is a setting to disallow the user from disconnecting from
>  the host, including closing the emulator window while connected. This
>  would allow the emulator to be closed if a disconnection happened.

Well, you talked me into it, you silver-tongued devil.

We won't however implement it in the same fashion as Reflection has. Rather,
we've decided to put the feature in as part of the QCTerm forms mode
commands. At the moment the commands are:

    Esc %k0F - erases the current background form and sets QCTerm
                      in a mode to receive a new background form definition
file
                      (and puts QCTerm into forms mode, if it's not already
there).

    Esc %k1F - transmits delta changes on current form

    Esc %kC  - completes the current form definition, draws the form, and
                      moves the form to the display window.

    Esc %kR  - causes QCTerm to leave forms mode and revert to terminal
                      emulation.

    Esc %kE  - kills the QCTerm window on the PC (complete shutdown).

In this same vein, the new commands are:

    Esc %k0U - sets QCTerm to normal mode with regard to "unkillable" state,
                       (i.e., the "unkillable" state will not be in effect.)
This will
                       be the default condition, the way things are now. A
                       hard reset will return the emulator to this state.

    Esc %k1U - puts QCTerm in "unkillable" mode.

While we can reliably tell if we are connected to a remote host under telnet,
we can't be nearly as sure when we're connected serially. A significant
proportion of the Winmodems that are in PC's no longer reliably relay their
connection status to MSCOMM, the Microsoft-supplied OCX we use, thus whenever
the user tries to kill an "unkillable" QCTerm window and the connection is
either (i) serial or (ii) telnet and the telnet connection still exists,
we'll put up a message explaining the situation to the user: "Please exit
your application in the manner prescribed by the application or perform a
hard reset to clear the "unkillable" flag before you try to close the QCTerm
window again."

If the user is connected via telnet and the connection is dropped,
accidentally or otherwise, the "unkillable" state variable will be cleared at
that time as well and the user will never see the explanatory message.

The Esc %kE and the Esc %k0/1U sequences will be usable outside of QCTerm's
forms mode. Indeed, you can use the Esc %kE sequence now, in the current
version of QCTerm, if you wish.

I consider this design to be robust enough not to cause any excess support
calls.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *