Bill writes:
> As for there being some requirement that NS be installed, quite
> frankly that is
> a new one by me. When "tm_cms_type_mgr" is bound to STDIN/LIST Posix
> apps (not necessarily threaded apps) may not work quite correctly. This is
> because Posix may make calls like IOCTL() that tm_cms_type_mgr can't
> handle. The only way I know of that you get this type manager bound is
> when the device sub-type is a zero. For subtypes 1, 2 or 3 we bind
> tm_terminal. That one works.

Ah, everything is starting to make sense now!  I'll bet it is a safe guess
that [log in to unmask] problem is that without the full NS
installed, some users who connect to the 3000 with some particular
connection method (I would guess only VT) end up with their terminal I/O
bound to the older Type Manager rather than the new one.  I can see that all
of his/her three problems:

> 1) Syslist processing in multi-threading;
> 2) JAVA programs executing on the HP e3000;
> 3) Native Mode Terminal I/O.

could be affected by an old TM that doesn't know about the more modern
functions put in in support of Posix, etc.

DBECKER's quote:
> If you happen to have NS/3000 AND you are using a terminal emulator
> on a PC AND the subtype 1 is sent to NS/VT, then, and only then
> will you have the Native Mode terminal emulator.

makes sense in the context of Bills information if what's happening is that
without the full NS, the VT Server component is producing a virtual terminal
device of subtype 0 rather than >0, which would be required to get the
"good" TM.

Ah! Something just percolated up out of my memory that at some point a few
years ago, HP stated that in order to get the full benefit of certain
VT-related enhancements one would need to buy the full NS package, even
though "basic" VT was included in FOS as part of the bundled LanLink
product.

If I Recall Correctly, typeahead over VT was the original reason for this,
as HP was trying to get people to buy NS by preventing the "free" VT from
being able to take advantage of typeahead.

It makes perfect sense that typeahead was probably only implemented in
tm_terminal, and the decision was made to prevent the "free" VT server from
binding to the new Type Manager in order to limit the functionality of the
free product.

In the mean time, many new enhancements went into tm_terminal which the rest
of the world (i.e. Posix) is dependent on, and there may not be anyone who
even remembers the decision to limit the free VT to only use the CM type
manager.  Certainly the ramifications of this decision would take a while to
spot today.

So, my guess is that somewhere in the "free" VTSERVER program (or its
related code) there is a "0" that, if changed to a "1", would fix the
problem and bring the free VT up to the level of the full NS product.  This
ought to be easily patchable, and I can't imagine that HP would want to
continue to differentiate NS and the free VT since: so many things are
dependent on Posix terminal functionality today, we also have the fully
functional free telnet alternative, and as DBECKER has so clearly pointed
out, the two different VT servers are now a major support headache :-)

So, mystery solved?

G.