Greg writes:

> We are in the process of "locking down" the users' sessions on the
>  HP3000 so that they cannot close the terminal emulator window
>  while they are still connected. This is to force the users to log off
>  the HP3000 application correctly. This is possible in Reflection, which
>  is the most frequently used emulator for our system.
>
>  We recently installed the Advanced Telnet patches and are planning to
>  promote QCTerm to external users (who are very budget-constrained),
>  especially to those over the other side of Australia who have been
>  experiencing very slow telnet access. I'm hoping that Advanced Telnet
>  will benefit them significantly.

We're not opposed to putting new features into QCTerm, but it's important for
us to understand the motivation. In that regard, let me say that it's my
understanding that the "feature" that you mention exists in Reflection is
*not* there to make life easier for the application programmer but rather to
cover over a bug in NS/VT and/or Reflection.

A remote user who is using Reflection via NS/VT and who simply closes
Reflection often leaves a hanging ghost session on the HP3000. This too was a
problem in the HP3000's earliest implementations of telnet, but Jeff Bandle
and I worked to completely rid the HP3000 of that bug three or four years ago
for telnet. If you get the "advanced telnet" patch on your machine, you will
now have that code. The upshot is now when a user closes a QCTerm window
without logging off, you get a very graceful shutdown of first the
application and then of the session. Nothing ever hangs nowadays.

To my mind therefore, the Reflection-like "feature" is not necesary in
QCTerm. The only other reason that I can imagine it having value is that your
application is so fragile that *not* walking out of it properly might leave
the application in some unauthorized state. Having a "you can't quit QCTerm
until you sign off properly" escape sequence might be of some value in that
circumstance, but I would sincerely recommend a better applications design as
the proper way to correct this problem.

Moreover, such a "feature" won't do anything to fix the problem if the
communication link breaks. Under the current design, if the TCP/IP telnet
link is broken, or if the user changes IP addresses, or if the user simply
shuts QCTerm down, or should the PC freeze up, the result will be exactly the
same event: the telnet server on the HP3000 will very gracefully kill the
application and log off the current user.

If, on the other hand, we put in a "you can't quit QCTerm until you sign off
properly" escape sequence, if something untoward should happen, such as a
communication break or the HP3000 goes down, the remote user is going to be
hung with an unkillable QCTerm session on his or her PC. That's certainly
bound to cause a lot of confusion -- and I don't think that that's a very
good design. While we can ameliorate that problem to some degree on our end,
this doesn't seem like the right place to solve the problem. All we're going
to do is generate a lot of support calls.

So, if you don't mind, try the advanced telnet patch first for a few months
and let me know what you think then. Advanced telnet solves a myriad of
problems, not just long-distance communications, but I can say with certainty
that it will make telnetting from Kalgoorlie to Wollongong a real pleasure.

As things stand now, the HP3000 is very likely going to be the only machine
in the world to have advanced telnet capabilities. I don't have much interest
in trying to put it into UNIX or Linux. Indeed, the HP-UX weenies won't even
return emails that Mark Bixby and I have sent them on the subject. But more
than that, the UNIX communications are simply a mess. We're not abandoning
UNIX users, but we're going to take a different approach with UNIX in
QCTerm's forms design that will get very much the same behavior, but not in
an advanced telnet mode.

Nonetheless, I've always thought that advanced telnet was going to be a truly
significant differentiating feature of MPE, especially for long-distance
world-wide telnetting into very large, consolidated HP3000s.



In that regard, another user wrote me this morning:

> I am using QCTerm to connect to an HP3000 in Tanzania.
>  It's a slowwwww connection, but QCTerm makes it bearable.
>
>  However, even though I start off the connection with Advanced Telnet set
>  on, it revrets back to Standard as soon as I connect to the machine, and
>  only after a successful logon can I switch to Advanced Telnet.

Because the user set up a dummy account for me and gave me logon
instructions, I was able to sign on to the machine in Tanzania. The problem
in this instance is that the machine doesn't have the "advanced telnet" patch
on the system. It's using the old, standard telnet code.

The new versions of QCTerm now negotiate with the remote server and ask
whether the remote HP3000 has advanced telnet capabiliites. Again, this is
new code that Jeff Bandle and I worked out together. Any standard machine
(Linux, Unix, etc.), as well as older versions of the advanced telnet code,
respond "no," so QCTerm automatically switches itself back into standard
telnet, regardless of how you have the settings set. That's what's happening
in Tanzania. But with the advanced telnet patch, the remote HP3000 says,
"yes, I can do advanced telnet", and QCTerm then automatically puts itself
into that mode, again regardless of how you have the settings set.

It's possible for you to change the mode after you are properly signed on,
but we made the mode-determination process wholly automatic for you, so that
you can switch back and forth between machines and never have to give the
mode any thought.


Finally, Jeff wrote, following John's comments:

> > As far as migration from MPE/iX to HP-UX or Linux, based upon my own very
>  > limited HP-UX and Linux experiences, I would think that this enhancement
>  > would be MORE important when dealing with HP-UX or Linux ...
>
>  If you really want Linux compatibility, make it do VT and/or X
>  emulations (I'm just kidding about the X part, Wirt, that would be a
>  real waste of your valuable time).  But VT (as in DEC emulation, which
>  on second thought might be more important with the merger!) is a least
>  common denominator for most all *nix application *except* HPUX.

We'll almost certainly never put DEC emulation into QCTerm. There are a lot
of free DEC terminal emulators out there already, and I can't see a lot of
profit in generating another free DEC emulator (but heck, I can't see a lot
of profit in generating a free HP terminal emulator, either :-).

However, neither are we finding any problems with using QCTerm with anyone's
UNIX. During the initial logon negotiation process, we properly describe
ourselves to the host as an HP terminal emulator, and every UNIX we've seen
responds properly. The problem often lies in the way that people have their
UNIX servers set up in their profiles. After all of the negotiation is over,
and everyone agrees that we're an HP terminal emulator, and the user is
properly signed on, the user-defined profiles then kick in and declare the
terminal emulator to be DEC, completely obviating all of our carefully
crafted negotiations. If people would simply remove that terminal type
definition material and let the terminal emulators properly negotiate their
IDs, I don't think that there would be any problems.

Wirt Atmar

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