[Info-vax] VSI and Process Software announcement

[Craig A. Berry]

On 9/23/16 3:05 PM, Stephen Hoffman wrote:

> Get the configuration morass under control.   That isn't a combination
> of a command-line tool, a DCL menu, and a plethora of rustic, artisanal
> configuration files.   Pick one, preferably a replacement for the
> command line tool.

Or how about an API with the existing command interface re-implemented
(plus completed, cleaned up, and otherwise fixed) on top of that?

> Don't use RMS indexed files for TCP/IP Services configuration data.

Anything's possible in the absence of real information, but given the
rather ad hoc list of utilities mentioned in the announcement, I'd
expect an equally ad hoc collection of data stores. After all, Multinet
uses DCL as a data store for some features, and configuration files for
others, IIRC. End users won't care much about the data store as long as
it works and they don't have to edit umpteen different text file formats
by hand.

Overall the announcement raises more questions than it answers. Will the
interface(s) look more like Multinet or more like TCP/IP Services, or
something entirely new? That applies to both management interfaces and
end user interfaces (such as all the qualifiers on TELNET).

Will there be ways of converting existing configurations or will people
have to start over from scratch to configure the new stack? What random
number generator came up with 10.5 as the version number for an initial
release? Why is OpenSSL 1.0.2 on the list of "major updates" in the new
stack when VSI already has that and has 1.1.x on the roadmap (and it
couldn't be licensed from Process anyway since Process doesn't own it)?

Just a WAG, but perhaps VSI and Process were both facing a lot of work
to take advantage of VCI 2.0:

<http://www.vmsconsultancy.com/download/NL-VMSUpdate-2015/Vienna%20LAN%20Performance%20Improvements.pdf>

and decided to pool their resources to do so. That would make a lot of
sense, but VCI 2.0 is not on the current roadmap, so it's equally
possible that was abandoned or put on the back burner and another path
toward improving the stack chosen. If the latter, then we may be stuck
with TCP/IP that can only do 12.5% of line rate for longer than we'd hoped.

If anybody finds out anything interesting at Boot Camp, do post what you
can here.