Michael asks:
> It has been awhile since I needed to justify the purchase of
> NS/3000, back in 1996 actually.  At that time HP had more than
> one flavor of NS/3000. Inbound NSVT was a component of all
> NS/3000 packages. I think what Doug is referring to (36920B) the
> full-blown NS/3000 package, and he is correct in saying that
> 36920B is not needed for inbound NSVT. I think he is correct
> because HP sales a less expensive version of NS/3000 that will
> support inbound NSVT.
>
> Correct me if I'm wrong. I think that you'll need at least the
> *Thin* version of NS/3000 if you want to be able to accept
> inbound NSVT connections on your M.P.E. box,.
>
> I am also curious about you Java statement, because I recently
> ask myself what I would possibly need NS/3000 for in the future.
> With HTTP, FTP, SMTP, Telnet, and NETBIOS (Samba), REMESH, Inetd,
> Berkley Sockets, and much more all available on M.P.E., why would
> one want to have NS/3000?  I've noticed some performance issues
> with NSVT vs Telnet, with Telnet coming out ahead, and HP
> Advanced Telnet will even be better.  Why do I need NS/3000?

My understanding of the VT and NS situation is as follows.

There are two slightly different versions of the inbound VT service.  One
comes with the "link" products that support TCP (ThinLan Link, etc.), and
one is part of the NS/3000 Services product.

Before some release (3.x? 4.0?) you had to purchase at least a link product
in order to get the core TCP stack, NetIPC, and the basic inbound VT
service.  Starting with that release, the ThinLan Link/XL product was
bundled into FOS, meaning that everyone got at least the basic inbound VT
service.

The differences between the basic and "full" VT SERVER products include (and
may be limited to) the "subtype" used to create the virtual terminal LDEV
when you connect.  The "basic" VT uses subtype 0, and the "full" version
uses subtype 1.  The device subtype determines which "Type Manager" (driver)
gets bound to the device.  A value of 1 results in binding to tm_terminal,
the modern, native mode, Posix featured virtual terminal driver which I
believe is also used with DTC terminals and Telnet sessions.  A value of
zero unfortunately results in binding to the old (pre-Posix) type manager,
which does not support any of the enhancements done in recent years to make
Posix programs work better (among other things).

I believe that this was done originally in order to provide an incentive for
people to upgrade to the full NS SERVICES product in order to get certain
features that only the newer terminal driver supported (Typeahead?).  I
suspect that everyone forgot about this decision, and as a result it didn't
occur to anyone that there would be a problem if the newer terminal type
manager got enhanced with some critical new functionality that the old one
lacked.  And of course all the test machines at HP have the full NS product
since it probably didn't occur to anyone that not having it was a special
case that needed to be tested, so everything works great for the MPE
developers at HP.

Thus we have situations today where certain Posixish subsystems (including
Java) that have been enhanced to use new features of the terminal I/O system
turn out to not work correctly unless you have the full NS product
installed.  There may also be a resource / performance impact, but I don't
know of anyone who has investigated this yet (it's possible that this would
explain why some users find Telnet to be faster than VT even though HP
always said it should be the other way around).

Since the modern tm_terminal type manager is now a prerequisite for several
things to work correctly, I believe that the problem with the "free" VT not
binding to this type manager will be considered a bug and there will
probably be a patch soon that will enable the free VT to operate the same as
the VT that's part of NS SERVICES thus eliminating the problem and the
transient need to have the full NS in order for things to work right over
VT.  Until that time I suspect that Telnet would provide a reasonable
alternative.

As far as other reasons that you'd want to buy the NS Services product, lets
look at what NS provides.  You get:

VT:   Inbound VT.
VTL:  Local (outbound) VT (:DSLINE/:REMOTE) to other 3000s
RPM:  Remote Process Management
RFA:  Remote File Access
RDBA: Remote Database Access
NFT:  Network File Transfer a.k.a. :DSCOPY
And some other miscellaneous junk that nobody ever uses (a.k.a. stuff that I
don't really know what it does :-)

It sounds as though the full inbound VT is likely to become part of FOS, and
it turns out that RPM (the ability to do a CREATEPROCESS on another system
along with creating a programmatic session for it to run in) has also ended
up bundled into FOS as a number of HP (and a few 3rd party) products require
it.

That leaves us with VTL, RFA/RDBA and :DSCOPY.

FTP is free for both client and server, and is almost a complete replacement
for :DSCOPY, so NFT is no longer a good reason to buy NS.

RFA and RDBA allow one to programmatically access remote files and
databases.  They are little used these days since they are so slow and
limited when compared with NetBase (which came into existence primarily due
to the deficiencies in RFA/RDBA).  These days anyone who seriously wants to
do 3000-3000 distributed processing uses NetBase.  If NS is all you've got,
and you're willing to make the required changes to your application, then
RFA/RDBA certainly can be used for performance insensitive remote file and
database access, but you'd probably be better putting the money towards
NetBase if you have the choice.

While telnet is a partial replacement for VTL, it doesn't really offer the
same level of 3000 to 3000 access that :DSLINE/:REMOTE does.  The ability to
log on from one 3000 to another is probably the only compelling reason to
buy NS these days.  When the switching and multiple session features of DTCs
came out, a lot of people stopped buying NS, especially those who had
eliminated the need for RFA/RDBA and :DSCOPY with something like NetBase.

So, thinking about it, perhaps the simplest thing for HP to do would be to
bundle the rest of NS into FOS, since most of the services it provides are
already available elsewhere, and all of them are things that are expected to
be part of any modern OS in the age of the Internet.  Of course the support
revenue from everyone who has the product and keeps paying for it whether
they need it or not probably means this won't happen :-)

G.