VSI and Process Software announcement

[clairg...@gmail.com]

http://www.prweb.com/releases/2016/09/prweb13699173.htm

VSI has licensed the intellectual property from Process Software to
be the foundation for our own TCPIP stack moving forward.

[Dirk Munk]

Excellent news!

[erga...@gmail.com]

I assumed and hoped that's what was going to happen. Meaning no disrespect but the idea of VSI knocking out a complete TCPIP stack in their spare time didn't exactly appeal. Good news for both parties (and their customers)!

[Jan-Erik Soderholm]

Absolutely good news. But also raises some "interesting" Q's... :-)

Such as, if the Hobbyist program continues, what IP stack will
be included? If any at all, of course...

Will MultiNet from Process be different (as in "better") than
the default "MultiNet-based" stack on VMS? Will parts of the
MultiNet suite be removed from the "native" VMS stack? And if
not, why would Process continue to sell Multinet?

Is this an x64-only change?

But things will be sorted out in due time, I'm sure... :-)

It does seems absolutely logical to use something that is regarded
to work well instead of inventing *that* specific wheel again.

Jan-Erik.

[Kerry Main]

Indeed .. as a long time Multinet user, this is great news!

Richard M should also be happy: (IPSEC full support)

extract from link:
"Some of the major updates include: OpenSSL 1.0.2, SSH (V1 & V2),
DHCP v3, IPv6 (complete application protocols supported), IPSEC
(full support), Bind 9.9, Kerberos 5, and advanced features such
as IPS, paired network interface support, and improved
performance monitoring capabilities."

:-)

Btw, a sleeper feature that may not be all that well known is the
embedded IPS (intrusion prevention system) Multinet feature
mentioned above:

A whitepaper from 2009 -
http://www.process.com/psc/fileadmin/user_upload/whitepapers/mult
inet/using_ips.pdf


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Robert A. Brooks]

On 9/21/2016 10:09 AM, Jan-Erik Soderholm wrote:

> Is this an x64-only change?

No, it's for IA64, also.

The expectation is that we'll release an implementation some time in 2017
(likely late spring/early summer).

In late 2017, we plan to release another version of VMS, where the
IP stack will be completely integrated into the OS, such that there will
be no questions about "do you want to install . . .", for TCP/IP; it'll be
automatically installed.

At least, that's the plan as of today.

--

-- Rob

[Jan-Erik Soderholm]

Right, here is one very simple question... :-)

I have browsed the Multinet documention, but could not
find the answer (maybe becuse the answer is "no" :-) ).

We create a lot of TNAnnnn: devices by doing like:

$ telnet /create nn.nn.nn.nn pppp nnnn -
/prot=none -
/time=(noidle,recon=00:00:02)

This creates a TNAnnnn: device pointing to the IP
address nn.nn.nn.nn and port pppp. Usually a port
on a Lantronix terminal server, or some port that
a PLC (with embedded ethernet) is listening to.

Then our applications communicate over that device
using the usual QIOW calls. Or in some cases (like
label printers) by COPY commands from DCL routines.

This works very well and is very stable. The whole
issues around network reconnects after an network
outage or a restart of the equipment is handled by
the TCPIP stack, the applications doesn't care.

Anyway, I could not find a way to create similar
network devices using Multinet. At least not using
the telnet part of Multinet.

Of course they can have other names than TNAnnnn,
but it would sure be nice to have the same function.

So, is this possible using Multinet?

Jan-Erik.

[Paul Sture]

On 2016-09-21, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> Den 2016-09-21 kl. 15:16, skrev Dirk Munk:
>> clairg...@gmail.com wrote:
>>> http://www.prweb.com/releases/2016/09/prweb13699173.htm
>>>
>>> VSI has licensed the intellectual property from Process Software to
>>> be the foundation for our own TCPIP stack moving forward.
>>>
>>
>> Excellent news!
>
> Absolutely good news. But also raises some "interesting" Q's... :-)
>
> Such as, if the Hobbyist program continues, what IP stack will
> be included? If any at all, of course...
>

Multinet has a Hobbyist licence.

Hobbyist License Terms:

<http://www.multinet.process.com/license.html>

where clicking on YES takes you to the the registration page.

--
It was untidy, so got unplugged.
It was unplugged, so got thrown away.

[Baldrick]

> On 2016-09-21, Jan-Erik Soderholm <jan-erik> wrote:
> > Den 2016-09-21 kl. 15:16, skrev Dirk Munk:

> >> clairgrant71 wrote:
> >>> http://www.prweb.com/releases/2016/09/prweb13699173.htm
> >>>
> >>> VSI has licensed the intellectual property from Process Software to
> >>> be the foundation for our own TCPIP stack moving forward.
> >>>
> >>
> >> Excellent news!
> >

I like MULTINET, you can unload / reload WITHOUT having to reboot, it was one of my wishes for UCX/TCPIP.

Good choice!

[Hunter Goatley]

On 9/21/2016 9:47 AM, Jan-Erik Soderholm wrote:
> Anyway, I could not find a way to create similar
> network devices using Multinet. At least not using
> the telnet part of Multinet.

From the online help for MultiNet:

$ TELNET /CREATE_NTY[=([PERMANENT] -
[,NAME=logical_name] -
[,TABLE=logical_name_table] -
[,MODE={EXECUTIVE|SUPERVISOR}] -
[/PORT=target-TCP-port] -
host

It should work the same way as what you're used to, albeit with NTY
devices instead of TNA devices.

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goath...@goatley.com http://hunter.goatley.com/

[Jan-Erik Soderholm]

Den 2016-09-21 kl. 18:33, skrev Hunter Goatley:
> On 9/21/2016 9:47 AM, Jan-Erik Soderholm wrote:
>> Anyway, I could not find a way to create similar
>> network devices using Multinet. At least not using
>> the telnet part of Multinet.
>
> From the online help for MultiNet:
>
> $ TELNET /CREATE_NTY[=([PERMANENT] -
> [,NAME=logical_name] -
> [,TABLE=logical_name_table] -
> [,MODE={EXECUTIVE|SUPERVISOR}] -
> [/PORT=target-TCP-port] -
> host
>
> It should work the same way as what you're used to, albeit with NTY devices
> instead of TNA devices.
>

OK, right. Found it. Page 152 in the "user guide". :-)

Looks promissing. I do not see any equivalent switch for
/PROTOCOL=NONE that disables all telnet handling and makes
it into a "raw" communication line with nothing but the actuall
data sent by the application code on both ends of the line.

We expect a "clean" line with no other data then "our" data.

Except from that, it does seem to do the same thing.

So it doesn't seem to be a fully replacement of TELNET /CREATE in
TCPIP Services. Maybe there is some other device type (than NTY)?

[corbettatpr...@gmail.com]

The NTY deice does not do any telnet negotiations and just passes the data it gets from the connection to the reader and passes anything written to it to the connection.

Devices can also be created and maintained using the Network Terminal Device Control Program (NTYCP).

http://www.process.com/docs/multinet5_5/admin_ref/chapter_6.htm


regards
Mike

--
Michael Corbett
Process Software
Cor...@process.com
(508) 879-6994 x369 / (800) 722-7770 x369

[David Froble]

Well, I didn't see anything that said they were just going to replace TCP/IP
with the Multinet product. I did see "license IP", which for me sort of
indicates a modified or new TCP/IP. Perhaps what you need will be in the new
product. Note that "early 2017" sort of implies that it's not done yet.

[Jan-Erik Soderholm]

But it still seems to intercept telnet-escape characters and it also
tries 3270 negotiations, if I did not misread the manual. I probably
did... :-)

> Devices can also be created and maintained using the Network Terminal
> Device Control Program (NTYCP).
>
> http://www.process.com/docs/multinet5_5/admin_ref/chapter_6.htm
>

Yep, that also looks promising. Only practical test can show
how it handles network outages and similar. Questions like if
the devices reconnects automaticly and similar.

It also has to stay connected even if the data is idle since
it is usually the "other" side (like an handheld barcode
scanner or a PLC) that sends first.

Thanks.

>
> regards Mike
>

[Jan-Erik Soderholm]

Yes, I thought of that. We do not know how rellevant the current
Multinet docs are for the "new TCPIP" for VMS... :-)

[Dirk Munk]

I hope VSI will also build NIC drivers with off-load engines for TCP,
IPsec, iSCSI etc.
At least I assume Multinet has no such drivers.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Jan-Erik Soderholm via Info-vax
> Sent: 21-Sep-16 1:28 PM
> To: info...@rbnsn.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

[snip..]

> >> Anyway, I could not find a way to create similar network
> devices
> >> using Multinet. At least not using the telnet part of
Multinet.
> >>
> >> Of course they can have other names than TNAnnnn, but it
> would sure
> >> be nice to have the same function.
> >>
> >> So, is this possible using Multinet?
> >>
> >> Jan-Erik.
> >
> > Well, I didn't see anything that said they were just going to
> replace
> > TCP/IP with the Multinet product. I did see "license IP",
which
> for
> > me sort of indicates a modified or new TCP/IP. Perhaps what
> you need
> > will be in the new product. Note that "early 2017" sort of
> implies
> > that it's not done yet.
>
> Yes, I thought of that. We do not know how rellevant the
current
> Multinet docs are for the "new TCPIP" for VMS... :-)
>

Re: testing -

In terms of ease of testing, I currently have installed both
Multinet V5.5 and TCPIP V5.7 stacks on my VSI OpenVMS V8.4-2L1
rx2600 lab system. While I cannot speak to how the VSI product
will behave or what it will look like, today, I can flip from one
stack to the other by simply enabling /disabling the appropriate
startup file in the systartup_vms.com file and then reboot.

Hence, assuming the new VSI TCPIP stack will be similar to
Multinet, testing should be easy to do. With both stacks
installed on the same system, and once config/script/app changes
are done, measure how things work with one stack, flip startup
file, reboot and then measure performance and/or test
functionality with the other stack.

[Phillip Helbig (undress to reply)]

In article <nru4bh$bv0$1...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> writes:

> Such as, if the Hobbyist program continues, what IP stack will
> be included? If any at all, of course...

For a while now, the hobbyist program has provided CD images containing
the basic stuff, including of course TCPIP. VSI said they would have a
hobbyist programme. So it will contain their IP stack.

[David Froble]

I'd guess that unless someone says that it is, that it is not.

It doesn't sound like VSI is just replacing TCP/IP with Multinet.

[IanD]

From the prweb release...

http://www.prweb.com/releases/2016/09/prweb13699173.htm

Quote: "VSI intends to release the new TCP/IP stack as VSI TCP/IP V10.5. The timing of the release is still being determined, but we intend to accelerate time-to-market, by first distributing V10.5 as an independent installation kit. Customers will have the option to keep using the existing stack or install V10.5. However, the older stack will be phased out within the next 2 years."

I assume when they mean 'older stack' they are meaning TCPIP Services?

That to me says that the old will be going and it's got 2 years (+ time taken before V10.5 is knocked out). 2 years means sites out there wanting to stay current are going to have to get moving - sort of brings an air of excitement and urgency with it actually :-).

No more sleepy OpenVMS if this sort of time-frame for change spills over to the rest of OpenVMS!

[Bob Koehler]

In article <mailman.9.1474490123.2...@rbnsn.com>, "Kerry Main" <kemain...@gmail.com> writes:
>
> In terms of ease of testing, I currently have installed both
> Multinet V5.5 and TCPIP V5.7 stacks on my VSI OpenVMS V8.4-2L1
> rx2600 lab system. While I cannot speak to how the VSI product
> will behave or what it will look like, today, I can flip from one
> stack to the other by simply enabling /disabling the appropriate
> startup file in the systartup_vms.com file and then reboot.

Is it that simple if you're clustering over IP? Clustering means
the IP stack gets loaded before the startup scripts are run.

[Bob Koehler]

In article <32d1c9c9-97a7-45ca...@googlegroups.com>, IanD <iloveo...@gmail.com> writes:
>
> I assume when they mean 'older stack' they are meaning TCPIP Services?
>

Yes, the one many of us still stubbornly refer to as UCX, is what I
assumed, too. What other 'older stack' would VSI have, that they
could plan its demise?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Bob Koehler via Info-vax
> Sent: 23-Sep-16 10:31 AM
> To: info...@rbnsn.com
> Cc: Bob Koehler <koe...@eisner.nospam.decuserve.org>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

> In article <mailman.9.1474490123.24380.info-
> vax_rb...@rbnsn.com>, "Kerry Main"

While Multinet supports multi-site clustering over IP, I have not
tested this aspect as any clustering I occasionally do is local.

[Hans Bachner]

I don't think so - afaik IP as a cluster interconnect is only supported
with the HP TCP/IP stack.

This will certainly change with the arrival of VSI TCP/IP; but I doubt
that third party stacks will be supported in the foreseeable future.

But without IP as a cluster interconnect I don't see why this
configuration should give you problems.

Hans.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Hans Bachner via Info-vax
> Sent: 23-Sep-16 11:01 AM
> To: info...@rbnsn.com
> Cc: Hans Bachner <ha...@bachner.priv.at>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

> Bob Koehler schrieb am 23.09.2016 um 16:31:

> > In article <mailman.9.1474490123.24380.info-
> vax_rb...@rbnsn.com>, "Kerry Main"

Reference:
http://www.process.com/docs/multinet5_4/MULTINET054_RELEASE_NOTES
.txt (sect 2.1)
"MultiNet V5.4 can be used to provide transport services for an
OpenVMS IP cluster on Integrity systems running VMS V8.4. The
user of this should first familiarize themselves with the section
on Cluster over IP in the OpenVMS Guidelines for Cluster
Configurations manual."

While we will need to wait until the VSI TCPIP stack docs are
available to see what differences there might be, here is a
pointer to the latest Multinet V5.5 (and V5.4) docs:
http://www.process.com/psc/service-support/multinet-support/multi
net-documentation/

[Bob Koehler]

In article <e4kudc...@mid.individual.net>, Hans Bachner <ha...@bachner.priv.at> writes:
> Bob Koehler schrieb am 23.09.2016 um 16:31:
>> In article <mailman.9.1474490123.2...@rbnsn.com>, "Kerry Main" <kemain...@gmail.com> writes:
>>>
>>> In terms of ease of testing, I currently have installed both
>>> Multinet V5.5 and TCPIP V5.7 stacks on my VSI OpenVMS V8.4-2L1
>>> rx2600 lab system. While I cannot speak to how the VSI product
>>> will behave or what it will look like, today, I can flip from one
>>> stack to the other by simply enabling /disabling the appropriate
>>> startup file in the systartup_vms.com file and then reboot.
>>
>> Is it that simple if you're clustering over IP? Clustering means
>> the IP stack gets loaded before the startup scripts are run.
>
> I don't think so - afaik IP as a cluster interconnect is only supported
> with the HP TCP/IP stack.

Multinet suppports it and I have it running in my hobbyist cluster.

[David Froble]

Got to wonder why you are stubborn. UCX was the product prior to TCP/IP V5.
The TCP/IP V5 stuff came from the T64 product. Not UCX.

[Paul Sture]

The user interface stayed much the same as UCX V4 though.

When I first heard that the Tru64 version was being "imported" I was kind of
hoping for a better interface, albeit not one "too Unixy", but that didn't
happen.

[Stephen Hoffman]

On 2016-09-23 18:49:54 +0000, Paul Sture said:

> On 2016-09-23, David Froble <da...@tsoft-inc.com> wrote:
>> Bob Koehler wrote:
>>> In article <32d1c9c9-97a7-45ca...@googlegroups.com>,
>>> IanD <iloveo...@gmail.com> writes:
>>>> I assume when they mean 'older stack' they are meaning TCPIP Services?
>>>>
>>> Yes, the one many of us still stubbornly refer to as UCX, is what I
>>> assumed, too. What other 'older stack' would VSI have, that they could
>>> plan its demise?
>>
>> Got to wonder why you are stubborn. UCX was the product prior to TCP/IP V5.
>> The TCP/IP V5 stuff came from the T64 product. Not UCX.

UCX was the prefix. The product name has been TCP/IP Services for a
very long time. There's all sorts of history and baggage here, too —
both organizational and technical...

We're probably also going to get to go through yet another facility
prefix change with this new VSI work, but that's fodder for some future
discussion...

> The user interface stayed much the same as UCX V4 though.
>
> When I first heard that the Tru64 version was being "imported" I was
> kind of hoping for a better interface, albeit not one "too Unixy", but
> that didn't happen.

Looking forward to 2020 and beyond, rather than looking at back...

Get DHCP working out of the box. OpenVMS boots up, requests a DHCP
address, and allows (only) remote-management connections, and an ssh
server. Generate a system password based on the server serial number.
That's available on Itanium. Maybe use the MAC address if there's
no serial number set or if the x86 box has no serial number, but that
ends up being far too obvious. This to allow full remote management
on first boot, right after installing the bits. Get SNMPv3 working,
and also certificate-protected TNT/Argus, and ssh as part of this
configuration. (Want to play in the cloud, or in a VM or a hosted
data center or such? You can't always assume and can't depend on
having a hardware console, and remote access to same...)

Load common root certificates as part of the install. Mozilla via
curl or however y'all choose to do that. Preferably also one set of
directories for certificates, and not having them scattered around
Apache and SSL and SSL1 and who-knows-where-else...

Always create all server directories, using consistent and reserved
UICs. Offer to migrate the existing morass over to consistent users
and UICs during an OpenVMS upgrade. There's no point in not creating
all of this stuff, and no reason not to load templates or whatever
other pieces are needed. Allow the system manager the choice of which
services to start or not, via a consistent command interface and also
available via a callable API. But don't add all the complexity of
checking for directories and users and the rest, both for the VSI folks
and services, and for the ISVs and developers. It's always there,
it's always consistent. We aren't on VAX boxes and we aren't on 456MB
disks, after all.

(This UIC mess shouldn't even exist. It's a throwback to RSX-11M and
a very old and very limited world-view. Use UUIDs here. This avoids
most of the messes of UICs, including collisions. Allow users and
applications and application bundles to have associated UUIDs. UUIDs
and work toward containers properly applied also get away from the mess
that is facility prefixes. Obviously out of scope for IP work. This
is part of the authentication overhaul, and toward more modern and
modular application management.)

Install Apache as part of the base distro.

Install LDAP and particularly LDAP server as part of the base distro.
This in preparation of hauling the whole cluster management and
authentication morass forward to this millennium.

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. The menu morass is for a variety of reasons, but
then there's also no in-built menu-generation tools. Allowing OpenVMS
users to avoid having to roll their own and wildly inconsistent menus —
some use ^Z, some use QUIT, some EXIT, some use 9 or 99, some others
use who-knows-what-else. I don't care if this is DCL — well, I'd
prefer it not be or not require DCL — or some other scripting language,
or some other tool. But the lack of this interface means that
everybody does configuration tools differently...

Get ftp and telnet out of the default configurations and menus, and
make folks work to enable those, and any other insecure transports,
services or tools. Lead folks to ssh, sftp, and related. Get DECnet
out of the default install path, and for the same reasons. Don't
enable stupid choices.

Disable all network services that are incompatible with DHCP, whenever
DHCP is enabled.

Make IP cluster aware, such that you're really configuring the cluster
akin to one host — there are still some advantages to clustering on
OpenVMS, but the scatter-shot cluster management stinks and definitely
makes the whole clustering implementation far less desirable —
including automatically finding and sharing configuration data. (This
likely ties into LDAP, though there are other ways to do this.)

Don't use RMS indexed files for TCP/IP Services configuration data.
Use SQLite databases or something that makes particularly rolling
upgrades less complex, less constrained, and less hack-ish. Preferably
use one file, not the usual blizzard of files. Maybe give OpenVMS
directories that specifically store configuration data for
cluster-wide, system-wide, application-specific and user-specific
activities, but that's quite possibly out of scope of any IP stack work.

That's off the top... There's rather more work here, to bring OpenVMS
up to what's increasingly expected, and what will be expected 2020 and
beyond...


--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

On 2016-09-23 20:05:55 +0000, Stephen Hoffman said:

> Looking forward to 2020 and beyond, rather than looking at back...
>

> Get DHCP working out of the box. ...

Full native IPv6 would be nice here, too.

[David Froble]

You just want to take all the "fun" out of running a VMS system ....

:-)

[IanD]

On Saturday, September 24, 2016 at 6:05:59 AM UTC+10, Stephen Hoffman wrote:
> On 2016-09-23 18:49:54 +0000, Paul Sture said:
>

<snip>

and...

> On 2016-09-23 20:05:55 +0000, Stephen Hoffman said:
>

> > Looking forward to 2020 and beyond, rather than looking at back...
> >

> > Get DHCP working out of the box. ...
>
> Full native IPv6 would be nice here, too.
>
>

> --
> Pure Personal Opinion | HoffmanLabs LLC

+100000000000000000000000000000

How can I inject 'Hear, hear' in HUGE Massive flashing, glowing, exploding, nasal hair grabbing actioning letters?...

How about we frame this post at the same time and anyone buying OpenVMS going forward gets flogged mercilessly for accepting anything less

</Now lets watch the 'forever backwards folk chime in *sigh*'...>

[IanD]

lol

I see no fun in it at all having ground my teeth a number of times doing this

I ended up having to redo a number of the installs too, partly because I didn't know what I was doing and partly because it's just too easy to make mistakes or miss something

Security and stability is enhanced by boiler plating what is known to work rather than choosing from a myriad of options

I'd eventually like to see standard hardware with options selected as a ready-made package install with all the configuration already done - like what you can buy on Amazon when you buy a pre-configured OS + package install. Much much easier to do when OpenVMS will be on a VM host because hardware options will be more uniform

We might even get to the stage where OpenVMS is run from a single distribution file and unpacked and run in memory as a turn-key. No more having to update EXE's or code in myriads of directories and scan for security breaches and/or corruption. Updates would be simply a matter of download a single file. Checksumming an entire system then becomes much easier as it's just one single file. We could then finally move towards separating the OS from user data totally and could then lock down the OS even further. It's much easier to ring-fence a static or near static area than a dynamic one

OpenVMS needs to pick up the security mantle it once had and forge ahead with new ideas to attract people back to it - security going forward is going to become a major issue. Performance gains will slow, storage will get faster but security IMO will become more important than ever and a big diffirentitor

[David Froble]

IanD wrote:
> On Saturday, September 24, 2016 at 7:08:18 AM UTC+10, David Froble wrote:

>> You just want to take all the "fun" out of running a VMS system ....
>>
>> :-)
>
> lol
>
> I see no fun in it at all having ground my teeth a number of times doing this

Maybe you just don't know how to have fun ???

Ok, I'll get serious for just a few minutes. That's my limit.

> I ended up having to redo a number of the installs too, partly because I
> didn't know what I was doing and partly because it's just too easy to make
> mistakes or miss something

I recently set up a weendoze 10 system. I think I could have done 2 VMS
installs in the same time, and been more sure of what I was doing.

Maybe it's in what you know ....

> Security and stability is enhanced by boiler plating what is known to work
> rather than choosing from a myriad of options

Yes, and I have plenty from past VMS systems to "just move over", and that
usually works just fine. At least for me, that concept doesn't exist on
weendoze. It's all new every time. Lots of customization work, each and every
time. And re-learning.

Oh, and I don't care what anyone says, options are GOOD!

> I'd eventually like to see standard hardware with options selected as a
> ready-made package install with all the configuration already done - like
> what you can buy on Amazon when you buy a pre-configured OS + package
> install. Much much easier to do when OpenVMS will be on a VM host because
> hardware options will be more uniform
>
> We might even get to the stage where OpenVMS is run from a single
> distribution file and unpacked and run in memory as a turn-key. No more
> having to update EXE's or code in myriads of directories and scan for
> security breaches and/or corruption. Updates would be simply a matter of
> download a single file. Checksumming an entire system then becomes much
> easier as it's just one single file. We could then finally move towards
> separating the OS from user data totally and could then lock down the OS even
> further. It's much easier to ring-fence a static or near static area than a
> dynamic one
>
> OpenVMS needs to pick up the security mantle it once had and forge ahead with
> new ideas to attract people back to it - security going forward is going to
> become a major issue. Performance gains will slow, storage will get faster
> but security IMO will become more important than ever and a big diffirentitor

I'm not going to argue with much of that. More intelligence in the installation
will always be good. I sure would not like things to be hidden from me. Just
makes more work for me to dig them out. That also can be a bad thing.

Should VMS be improved, sure it should. But I have to say, for me right now, if
I have something more complex than point and click here and here, VMS is the
easiest and best choice. Even SSL, cause certificates are OS agnostic, and
always a PITA for me.

[David Froble]

I don't use DHCP ....

Not saying it cannot be useful for some people ....

[Dirk Munk]

SLAAC or DHCPv6 is the recommended way to assign an IPv6 address. Now of
course with IPv6 you can have lots and lots of addresses. Before I tamed
by Windows PC in assigning IPv6 addresses, opening a new tab in
Seamonkey caused a new IPv6 address to appear, so within a short while I
had dozens and dozens of IPv6 addresses.

> and allows (only) remote-management connections, and an ssh
> server. Generate a system password based on the server serial number.
> That's available on Itanium. Maybe use the MAC address if there's no
> serial number set or if the x86 box has no serial number, but that ends
> up being far too obvious. This to allow full remote management on
> first boot, right after installing the bits.

Why not use a built-in web interface on a chip? That is the default way
for any modern x86 system.

Why Apache? Why not WASD? Because "everybody is using Apache"? If VSI
can use Multinet components, then they can also use WASD. Instead of
porting every new version of Apache to VMS, they can just add new
functionality to WASD. After all WASD has a far better performance, and
is more then properly documented.

>
> Install LDAP and particularly LDAP server as part of the base
> distro.

It seems there is a tendency to go to full blown X.500, instead of the
smaller LDAP. Hey, we already have that on VMS!!!

> This in preparation of hauling the whole cluster management and
> authentication morass forward to this millennium.
>
> 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. The menu morass is for a variety of reasons, but
> then there's also no in-built menu-generation tools. Allowing
> OpenVMS
> users to avoid having to roll their own and wildly inconsistent menus > —
> some use ^Z, some use QUIT, some EXIT, some use 9 or 99, some others > use
> who-knows-what-else. I don't care if this is DCL — well, I'd prefer > it
> not be or not require DCL — or some other scripting language, or some
> other tool. But the lack of this interface means that everybody does
> configuration tools differently...
>
> Get ftp and telnet out of the default configurations and menus, and
> make
> folks work to enable those, and any other insecure transports,
> services
> or tools.

For some odd reason you don't want to use IPsec so it seems. But if you
do, and make your IP network secure on the place where it should be done
(the network stack), the suddenly all those insecure protocols become
secure. And your IP cluster communication is also secure. That would be
a really modern approach instead of antiquated protocols like SSH, or
would you like IP clustering to use SSH???

> Lead folks to ssh, sftp, and related. Get DECnet out of > the
> default install path, and for the same reasons. Don't enable stupid
> choices.
>
> Disable all network services that are incompatible with DHCP, whenever
> DHCP is enabled.

Which services do you mean? The list of DHCP options is almost endless.

>
> Make IP cluster aware, such that you're really configuring the cluster
> akin to one host — there are still some advantages to clustering on
> OpenVMS, but the scatter-shot cluster management stinks and definitely
> makes the whole clustering implementation far less desirable —
> including
> automatically finding and sharing configuration data. (This likely
> ties into LDAP, though there are other ways to do this.)
>
> Don't use RMS indexed files for TCP/IP Services configuration data.
> Use SQLite databases or something that makes particularly rolling
> upgrades less complex, less constrained, and less hack-ish.

Why not add RdB again? A long time ago RdB runtime was added to VMS to
the dissatisfaction of Oracle. Negotiate with Oracle. Why spend precious
time in porting SQLlite if VSI can make a deal with Oracle to add a real
VMS database?

[Stephen Hoffman]

On 2016-09-24 00:11:09 +0000, IanD said:

> I ended up having to redo a number of the installs too, partly because
> I didn't know what I was doing and partly because it's just too easy to
> make mistakes or miss something

I work with servers that are trivial to reinstall, while preserving
add-on applications, users, and settings. Sure, you can wipe and
reinstall, or you can install the OS over itself if there's been a disk
error or an accidental or malicious file corruption somewhere, or other
oddity.

> Security and stability is enhanced by boiler plating what is known to
> work rather than choosing from a myriad of options

Leading folks to proper choices, and making it harder to make bad
choices, and scheduling and deprecating and then entirely removing
known-insecure mechanisms and implementations.

Sitting on broken code or broken designs for reasons of compatibility
is a Really Bad Idea. But I'm being polite.

> I'd eventually like to see standard hardware with options selected as a
> ready-made package install with all the configuration already done -
> like what you can buy on Amazon when you buy a pre-configured OS +
> package install. Much much easier to do when OpenVMS will be on a VM
> host because hardware options will be more uniform

That's system and application profiles, and provisioning portals.
That's something I've commented on and requested before, but too far
out of scope for an IP overhaul. I work with other platforms that
support these capabilities, and the ability to tailor an install or a
user environment is exceedingly useful. To see just the tip of what's
available here on other platforms, search for MDM; mobile device
management. This is rapidly spreading beyond mobile devices and
client computers into servers and application management, too.

> We might even get to the stage where OpenVMS is run from a single
> distribution file and unpacked and run in memory as a turn-key. No more
> having to update EXE's or code in myriads of directories and scan for
> security breaches and/or corruption. Updates would be simply a matter
> of download a single file. Checksumming an entire system then becomes
> much easier as it's just one single file. We could then finally move
> towards separating the OS from user data totally and could then lock
> down the OS even further. It's much easier to ring-fence a static or
> near static area than a dynamic one

There's still going to need to be an incremental update mechanism, at
least until the trade-off between update size and network bandwidth
tilts.

> OpenVMS needs to pick up the security mantle it once had and forge
> ahead with new ideas to attract people back to it - security going
> forward is going to become a major issue. Performance gains will slow,
> storage will get faster but security IMO will become more important
> than ever and a big diffirentitor

That also includes application security — OpenVMS stinks at that, in
terms of what's offered, in terms of how the applications are isolated,
and in terms of the application security I've encountered — and better
and faster handling of patches and crashes.

Again, there's more than a little work here.

[Stephen Hoffman]

On 2016-09-24 02:37:42 +0000, David Froble said:

> I don't use DHCP ....
>
> Not saying it cannot be useful for some people ....

DHCP Is useful — and ubiquitous — for IPv4 clients and mobile devices,
and for cases when you're just getting a server going and need to
connect into and configure it. Particularly unattended or remote
servers, and that's something becoming increasingly common. Not all
systems have or can have a remotely-accessible and properly-configured
iLO, after all.

Between dynamic DNS, mDNS and other such tools, it's becoming
increasingly common to not even need to know the IPv4 address — and
nobody wants to type the IPv6 address — of the target system. Not all
network services can or do correctly deal with IP address changes, but
we're headed that way, too.

The less I need somebody on-site to know and do and deal with — and
connected to the console port or whatever — when working on an OpenVMS
installation or troubleshooting, the better things work out.

Having a new server boot to USB stick — DVD drives are failure-prone,
and are becoming less common, and don't and won't exist in some
environments — or from local network boot services such as InfoServer
or otherwise, and having the OpenVMS installation environment support
DHCP networking and mDNS would be really nice, for instance. (Yes,
there are boot-time security implications, of course.)

[Stephen Hoffman]

On 2016-09-24 09:43:56 +0000, Dirk Munk said:

> Stephen Hoffman wrote:
>>>
>>
>> Looking forward to 2020 and beyond, rather than looking at back...
>>
>> Get DHCP working out of the box. OpenVMS boots up, requests a DHCP address,
>
> SLAAC or DHCPv6 is the recommended way to assign an IPv6 address. Now
> of course with IPv6 you can have lots and lots of addresses. Before I
> tamed by Windows PC in assigning IPv6 addresses, opening a new tab in
> Seamonkey caused a new IPv6 address to appear, so within a short while
> I had dozens and dozens of IPv6 addresses.

Not where I'm going with that. As I stated, this to allow full remote
management on first boot, right after installing the bits onto the
disk. This before the installation and configuration script can be
invoked.

>> and allows (only) remote-management connections, and an ssh server.
>> Generate a system password based on the server serial number. That's
>> available on Itanium. Maybe use the MAC address if there's no serial
>> number set or if the x86 box has no serial number, but that ends up
>> being far too obvious. This to allow full remote management on first
>> boot, right after installing the bits.
>
> Why not use a built-in web interface on a chip? That is the default way
> for any modern x86 system.

Not where I'm going with that. either. I was referring to determining
credentials for access control, and preferably something that wasn't
going to be immediately easy to guess. That's a tough problem though,
and even using a hardware serial number isn't great security even for
first-boot.

>> Install Apache as part of the base distro.
>
> Why Apache? Why not WASD? Because "everybody is using Apache"? If VSI
> can use Multinet components, then they can also use WASD. Instead of
> porting every new version of Apache to VMS, they can just add new
> functionality to WASD. After all WASD has a far better performance, and
> is more then properly documented.

Two reasons: Because folks new to the platform aren't going to want to
learn another web server. My longer-term end-user goal is to get out
of managing as much of the web server as I can, too. Other platforms
make that easier, though those use Apache. Secondly, if y'all want
to fund and/or acquihire and/or quite possibly have VSI take over all
future WASD development if (when?) that becomes necessary, or to spend
and start and maintain an nginx port, or whatever else, so be it.

VSI doesn't strike me as a bunch that really wants to take the lead on
updating and maintaining a competitive web server right now.

And if I happened to have acqui-hired the WASD team, I'd probably still
roll out Apache and put the team to work overhauling and updating the
OpenVMS integration with that server, and the rest of the web
integration within the platform, too.

Note: none of this is intended to cast any aspersions toward the
quality or capabilities or skills of the WASD software or team.

>> Install LDAP and particularly LDAP server as part of the base distro.
>
> It seems there is a tendency to go to full blown X.500, instead of the
> smaller LDAP. Hey, we already have that on VMS!!!

Please show me the LDAP server in the base distro, and where it's
automatically installed and available, and show me where LDAP is
integrated into the base environment beyond passwords and account
status.

I've used the existing LDAP client bits and the associated password
authentication, and it's not something I consider easy to configure,
integrate or troubleshoot, either.

>> Get ftp and telnet out of the default configurations and menus, and
>> make folks work to enable those, and any other insecure transports,
>> services or tools.
>
> For some odd reason you don't want to use IPsec so it seems. But if you
> do, and make your IP network secure on the place where it should be
> done (the network stack), the suddenly all those insecure protocols
> become secure. And your IP cluster communication is also secure. That
> would be a really modern approach instead of antiquated protocols like
> SSH, or would you like IP clustering to use SSH???

Not where I'm going with that comment. I'm referring to removing
those from the default configuration menu and related tools. If
somebody wants to use VPN and use telnet, or just use telnet, give'm a
out-of-band path to enable that. Don't make that easy, as telnet and
ftp are insecure and problematic.

>> Disable all network services that are incompatible with DHCP, whenever
>> DHCP is enabled.
>
> Which services do you mean? The list of DHCP options is almost endless.

Not where I'm going with that, either. I'm referring to other network
services that can get tangled up if the host IP address changes.

>> Don't use RMS indexed files for TCP/IP Services configuration data.
>> Use SQLite databases or something that makes particularly rolling
>> upgrades less complex, less constrained, and less hack-ish.
>
> Why not add RdB again? A long time ago RdB runtime was added to VMS to
> the dissatisfaction of Oracle. Negotiate with Oracle. Why spend
> precious time in porting SQLlite if VSI can make a deal with Oracle to
> add a real VMS database?

Rdb is a nice database. If Oracle wants to give it away to folks, or
if VSI wants to eat the licensing costs, I'm interested.

Or as one wag referred to a particular Rdb-dependent package on the
OpenVMS Freeware, it was the most expensive piece of Freeware on the
whole distro.

Otherwise, Oracle has to compete with the costs of SQLite or other
database alternatives, both to developers and to end-users.

There are more than a few cases where I'd use SQLite in preference to
Rdb, and that's given more than a little experience with managing and
developing and troubleshooting Rdb applications and databases over the
years.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 24-Sep-16 9:50 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

> On 2016-09-24 02:37:42 +0000, David Froble said:
>
> > I don't use DHCP ....
> >
> > Not saying it cannot be useful for some people ....
>
> DHCP Is useful — and ubiquitous — for IPv4 clients and mobile
> devices, and for cases when you're just getting a server going and
> need to
> connect into and configure it. Particularly unattended or remote
> servers, and that's something becoming increasingly common.
> Not all
> systems have or can have a remotely-accessible and properly-
> configured iLO, after all.
>
> Between dynamic DNS, mDNS and other such tools, it's becoming
> increasingly common to not even need to know the IPv4 address
> — and nobody wants to type the IPv6 address — of the target
> system. Not all network services can or do correctly deal with IP
> address changes, but we're headed that way, too.
>
> The less I need somebody on-site to know and do and deal with
> — and connected to the console port or whatever — when
> working on an OpenVMS installation or troubleshooting, the
> better things work out.
>

Most customers on all platforms are adopting "lights out" DC environments and have been moving in that direction for the last 15+ years. That is all part of the massive server consolidation projects that have been so widely adopted.

Hence, remote AND secure multi-platform console management strategies is an IT best practice that should be in place for all med-large shops.

Examples include such as those from TDI ConsoleWorks (has hobbyist program btw)
https://www.tditechnologies.com/products/consoleworks-server

> Having a new server boot to USB stick — DVD drives are failure-
> prone, and are becoming less common, and don't and won't exist
> in some environments — or from local network boot services
> such as InfoServer or otherwise, and having the OpenVMS
> installation environment support DHCP networking and mDNS
> would be really nice, for instance. (Yes, there are boot-time
> security implications, of course.)
>

If you are talking about new OpenVMS installs on SMB sites, then yes, you are correct. I would also mention that every relatively modern server I have seen has a local DVD, but that could change in the future.

A more established OpenVMS site with config standards would either:
1. - conversational boot from a different root on the local common cluster system disk. Then make minor system specific changes and reboot or-
2. - local boot via DVD, then restore a backup to the target disk with a previously built gold system image with all local customizations embedded. Then, do conversational boot, make system specific changes and reboot. The gold image might even be a LD container for quicker fixes in the gold image.

Multinet supports IPV6 (including IPsec) and DHCP4, so both are likely part of the new VSI stack. See points 1 and 2 for new installs.

Note - With DHCP enabled on the various server LAN interfaces in the gold / LD image (usually with long TTL values), the number of steps required for each OS config is reduced. In larger sites, each OS may have 4 or more different LAN interfaces and each would have a different subnet address (e.g. PROD, CLUS, BACKUP, MGMT)

Larger sites will also be adopting IPAM (IP address mgmt.) solutions, but that is a different discussion. As example:
http://www.solarwinds.com/ip-address-manager/

[Stephen Hoffman]

On 2016-09-24 15:49:14 +0000, Kerry Main said:

>> Having a new server boot to USB stick — DVD drives are failure-prone,
>> and are becoming less common, and don't and won't exist in some
>> environments — or from local network boot services such as InfoServer
>> or otherwise, and having the OpenVMS installation environment support
>> DHCP networking and mDNS would be really nice, for instance. (Yes,
>> there are boot-time security implications, of course.)
>
> If you are talking about new OpenVMS installs on SMB sites, then yes,
> you are correct. I would also mention that every relatively modern
> server I have seen has a local DVD, but that could change in the future.

There's likely a DVD drive in every one you've seen because of past
expectations and — particularly in the case of OpenVMS — the operating
system can't (yet) deal what I'm discussing and what I'm suggesting
here.

> A more established OpenVMS site with config standards would either:
> 1. - conversational boot from a different root on the local common
> cluster system disk. Then make minor system specific changes and reboot
> or-

No, thanks. Remote management and remote profiling works far better
than that approach.

> 2. - local boot via DVD, then restore a backup to the target disk with
> a previously built gold system image with all local customizations
> embedded. Then, do conversational boot, make system specific changes
> and reboot. The gold image might even be a LD container for quicker
> fixes in the gold image.

Again, no. I really don't want to take several steps backward here.

The approach you describe is what (some) folks are doing now, and — for
not the first time — not an approach that's reasonable or maintainable
or even (hopefully) necessary going forward.

For where this is headed, I'd rather have the server get its
configuration and criteria from a central server automatically, and not
involve people at all — the less I have to touch the server or the rack
or the data center, the better. The ability to remotely manage and
provision systems is already commonplace on other systems — the low-end
gear I deal with from Apple provides this and rather more — though this
is certainly not something that most OpenVMS folks have dealt with.
Yet. But either OpenVMS gets dragged forward, or it gets dragged out
back.

> Multinet supports IPV6 (including IPsec) and DHCP4, so both are likely
> part of the new VSI stack. See points 1 and 2 for new installs.

Multinet does not support what I was referring to. If Multinet were
integrated into the distro and custom configured, a custom install can
be tweaked to deal with this. But so can TCP/IP Services. As I keep
writing here, I do not want to write or extend an operating system,
implement a network stack, a web server, a remote server configuration
tool and remote management and profile management and the rest of what
I expect from the platform. Because while various folks here can
certainly create and maintain and deploy all of that, other folks can
go get most or all that on some other platforms, and these and other
features are only going to become much more common on other platforms
going forward. That's where I'd like to see OpenVMS. Not stuck in
the present and the past.

> Note - With DHCP enabled on the various server LAN interfaces in the
> gold / LD image (usually with long TTL values), the number of steps
> required for each OS config is reduced. In larger sites, each OS may
> have 4 or more different LAN interfaces and each would have a different
> subnet address (e.g. PROD, CLUS, BACKUP, MGMT)

If gold masters still work for you, go for it. But — again — what I'm
referring to here is a step or two past that approach — not that I'd
even prefer to use all-inclusive master images.

> Larger sites will also be adopting IPAM (IP address mgmt.) solutions,
> but that is a different discussion. As example:
> http://www.solarwinds.com/ip-address-manager/

That's part of software defined networking, which is another hole in OpenVMS.

All of what I'm describing here is already available and already
working, BTW. There's nothing revolutionary here. It's available in
the not-OpenVMS servers that I routinely manage and use.

[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.

[Stephen Hoffman]

On 2016-09-24 17:27:03 +0000, Craig A. Berry said:

> 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?

Ayup. The lack of APIs and tools on OpenVMS for general configuration
management and control means everybody — including OpenVMS development,
layered products and the rest — does everything differently, too.

Having plist files and an API and some consistency would go a long way
toward reducing the insanity.

With an IP network stack, I'd expect some complexity by necessity, and
the platforms that have adopted and integrated Apache or Postfix or
such do still have those configuration files underneath, but other
operating systems have placed consistent front-ends and better
defaults. This so that most folks can usually avoid rummaging, and so
that folks don't have to discover the sheer joy of running an open
relay when TCP/IP Services can't find its SMTP configuration file.

That's if we don't get server and application profiles and the rest of
the tools. (Some consistency here makes profiles easier, too. This
as folks are going to the common APIs to get and set configuration
data, and not via their own bespoke APIs and parsers, which means
adding profiles becomes much easier. OpenVMS itself used to be good
at this sort of abstraction, too.)

But again, I'm aimed at 2021 here, and not at what we have no, nor at
what DEC EMA and OSI and NCL had tried...

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 24-Sep-16 1:19 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

No it does not. How is remote management /profiling better than secure console management?

As an example, in your ideal scenario, how do you archive console messages, what someone has typed at the console before the OS is up and do console HW event alerting?

> > 2. - local boot via DVD, then restore a backup to the target disk
> with
> > a previously built gold system image with all local customizations
> > embedded. Then, do conversational boot, make system specific
> changes
> > and reboot. The gold image might even be a LD container for
> quicker
> > fixes in the gold image.
>
> Again, no. I really don't want to take several steps backward
> here.
>

VMware does essentially the same thing with predefined templates, but there is still OS specific customizations required.

> The approach you describe is what (some) folks are doing now,
> and — for not the first time — not an approach that's reasonable
> or maintainable or even (hopefully) necessary going forward.
>

So, other than predefined templates, gold images, common system disks, network boots, LD type devices etc, it would be appreciated if you could enlighten me with how OpenVMS, VMware, Solaris, Windows, Linux and the other platforms should handle this?

> For where this is headed, I'd rather have the server get its
> configuration and criteria from a central server automatically, and
> not involve people at all — the less I have to touch the server or
> the rack
> or the data center, the better. The ability to remotely manage
> and
> provision systems is already commonplace on other systems —
> the low-end gear I deal with from Apple provides this and rather
> more — though this is certainly not something that most
> OpenVMS folks have dealt with.
> Yet. But either OpenVMS gets dragged forward, or it gets
> dragged out
> back.
>

You seem to want to make it so easy that an end user could install an OS into a prod environment.

Imho, that is just crazy. Regardless of the method, I want experienced SysAdmins to have their hands on new OS deployments. Yes, I know there is work to be done to make it easier than it is today, but the bottom line is there are just way to many variables and landmines that could impact other OS's to let a rookie deploy a new OS to a prod environment.

> > Multinet supports IPV6 (including IPsec) and DHCP4, so both are
> likely
> > part of the new VSI stack. See points 1 and 2 for new installs.
>
> Multinet does not support what I was referring to. If Multinet
> were
> integrated into the distro and custom configured, a custom install
> can
> be tweaked to deal with this. But so can TCP/IP Services. As I
> keep
> writing here, I do not want to write or extend an operating
> system, implement a network stack, a web server, a remote
> server configuration tool and remote management and profile
> management and the rest of what
> I expect from the platform. Because while various folks here can
> certainly create and maintain and deploy all of that, other folks
> can go get most or all that on some other platforms, and these
> and other features are only going to become much more
> common on other platforms
> going forward. That's where I'd like to see OpenVMS. Not stuck
> in
> the present and the past.
>

Again, most large shops I have been in use templates (VMware), gold images, network boot, USB, DVD, LD etc. There are some commercial bare metal pkgs which might do this, but it still requires a means to install that third party pkg on the bare metal server which then integrates with a central server.

Every Cust environment is different. Some environments require custom config's and there is usually a good reason for this.

> > Note - With DHCP enabled on the various server LAN interfaces
> in the
> > gold / LD image (usually with long TTL values), the number of
> steps
> > required for each OS config is reduced. In larger sites, each OS
> may
> > have 4 or more different LAN interfaces and each would have a
> > different subnet address (e.g. PROD, CLUS, BACKUP, MGMT)
>
> If gold masters still work for you, go for it. But — again — what
> I'm
> referring to here is a step or two past that approach — not that
> I'd even prefer to use all-inclusive master images.
>
> > Larger sites will also be adopting IPAM (IP address mgmt.)
> solutions,
> > but that is a different discussion. As example:
> > http://www.solarwinds.com/ip-address-manager/
>
> That's part of software defined networking, which is another hole
> in OpenVMS.
>

No its not. IPAM has been around for 15+ years and all the bigger shops use it. IPAM solutions are almost becoming mandatory if a site begins to adopt IPV6 internally.

Popular IPAM vendors include Bluecat, SolarWinds, ManageEngine, InfoBlox, Cisco etc. More info:
https://en.wikipedia.org/wiki/IP_address_management
http://www.ipamworldwide.com/ipam/books.html

SDN is just industry hype, which like "clouds", can be defined any way you like.

As an example, what Customer in their right mind is going to throw out all their existing network infrastructure from multiple vendors in order to implement SDN from one vendor?

> All of what I'm describing here is already available and already
> working, BTW. There's nothing revolutionary here. It's available
> in the not-OpenVMS servers that I routinely manage and use.
>

I would be interested in hearing about what you are describe as "already available and already working".

[clairg...@gmail.com]

....but VCI 2.0 is not on the current roadmap...

VCI 2.0 = Increased Network Performance in V9.0

[Dirk Munk]

You're absolutely right. I've worked in an environment where everything
was set up with easy to deploy templates. etc. The result was that no
one understood what they were doing, they didn't understand all these
settings because they didn't have to think about them. If there were
problems, they didn't know where to look, or how to fix the problems.

That is the strange discrepancy. We want more and more intelligence in
the OS and tooling, requiring competent staff, and when we have to
deploy a system, any monkey must be able to do so without any insight of
what he is doing.

I remember an Alpha 8400 cluster with a 4GB memory per system, huge in
those days. It didn't perform well. The cache setting as still at the
default 3MB (afaik), many batch jobs were set for a maximum memory usage
of 2.5MB. Why? Nobody knew, "I don't know, it has always been like that"

I can give you many more examples like that, with Unix, Linux, Windows,
it doesn't matter. Incompetent staff that has no idea what they are
doing, trained to invoke scripts, not to understand what the scripts are
doing.

[Paul Sture]

On 2016-09-25, Dirk Munk <mu...@home.nl> wrote:

>
> I remember an Alpha 8400 cluster with a 4GB memory per system, huge in
> those days. It didn't perform well. The cache setting as still at the
> default 3MB (afaik), many batch jobs were set for a maximum memory usage
> of 2.5MB. Why? Nobody knew, "I don't know, it has always been like that"
>
> I can give you many more examples like that, with Unix, Linux, Windows,
> it doesn't matter. Incompetent staff that has no idea what they are
> doing, trained to invoke scripts, not to understand what the scripts are
> doing.
>

Another example of that, on the subject of OpenOffice settings:

"For 14 years I've been telling OOo* users to open up any OOo app, go to
Tools, Options, Memory, and then multiply any values they see in there
by 10. Then their OOo will run like it's been greased and dropped off a
steep hill whilst charged up with neutrinos travelling faster than the
speed of light."

<http://forums.theregister.co.uk/forum/1/2016/09/02/openoffice_retirement/#c_2962043>

P.S. the location of those settings varies by OpenOffice flavour and
host platform. For LibreOffice on OS X/macOS they are in Preferences ->
Memory)

--
It said I needed to have eight characters for my password.
So I chose Snow White and the seven dwarves.

[Dirk Munk]

I'm using 64 bit LibreOffice for Windows, and the only memory setting I
can find is for the Image Cache.

It is in Tools > Options > LibreOffice > Memory.

[Stephen Hoffman]

On 2016-09-24 20:41:29 +0000, Kerry Main said:
>
> No it does not. How is remote management /profiling better than secure
> console management?

Then you probably haven't used remote server management. What I've
used works quite well, and the ability to detect and adopt a newly
booted server is very handy. For a larger data center, I'd prefer all
that to be entirely automated. Wire up the rack and power up the box
and either the FIS or the console brings the box online to the
provisioning servers. OpenVMS isn't good at this, at all. OpenVMS is
still stuck with serial console concepts and operations, and most of
that chatter is a confusing and problem-masking mess and a complete
waste of photons.

> As an example, in your ideal scenario, how do you archive console
> messages, what someone has typed at the console before the OS is up and
> do console HW event alerting?

I'd prefer to not have anybody on the console line, even for first
boot. I regularly work with servers that don't even have serial
consoles. Or DVDs, for that matter.

> I would be interested in hearing about what you are describe as
> "already available and already working".

I'm already using what I'm describing here. As are other folks. I'd
like to be able to use and integrated with these capabilities on
OpenVMS, and — since I'm looking at 2021 and beyond — I'd like better
versions of what's available.

[Stephen Hoffman]

On 2016-09-25 11:43:29 +0000, Dirk Munk said:

> Kerry Main wrote:
>> You seem to want to make it so easy that an end user could install an
>> OS into a prod environment.

Everybody has to go through this, just because we had to walk to school
all winter long, in the snow, up hill, both ways?

>> Imho, that is just crazy. Regardless of the method, I want experienced
>> SysAdmins to have their hands on new OS deployments. Yes, I know there
>> is work to be done to make it easier than it is today, but the bottom
>> line is there are just way to many variables and landmines that could
>> impact other OS's to let a rookie deploy a new OS to a prod environment.
>
> You're absolutely right. I've worked in an environment where everything
> was set up with easy to deploy templates. etc. The result was that no
> one understood what they were doing, they didn't understand all these
> settings because they didn't have to think about them. If there were
> problems, they didn't know where to look, or how to fix the problems.

I remember the uproar over the shift to depot repairs and board
swapping, too. When the repair techs stopped using solder and a
'scope.

Welcome to modern computing technology. We each — we all — depend on
the knowledge of other folks. Of the code and the tools of others.
None of us are experts in everything. We are increasingly integrating
our servers and software with more packages and tools and platforms.
Trying to make our configurations and deployments easier, more
manageable, more repeatable, and requiring less human interaction is
the goal that most of us have.

I'm glad that OpenVMS moved forward. Part of moving forward is
keeping the best of the old ideas, and rethinking or replacing the
areas that are no longer advantageous. That includes reworking or
rethinking or replacing the console serial line, and
manually-configured, local deployments booted from DVD, among other
approaches that seem increasingly antebellum.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 25-Sep-16 3:20 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

In large shops, you want a common multi-platform console log strategy as part of the enterprise mgmt. strategy. You do not want individual OS's each with a separate or proprietary console log solution that will not fit into the enterprise strategy.

In some cases for security reasons, you want the console log strategy to be totally separate from the host OS or network device so a OS/network priv'ed person cannot change the console log files that might be stored on the local server. For audit purposes, you may even want the console log files backed up as part of your data mgmt. strategy.

What Apple has does not fit this corporate requirement, hence my earlier question about what OS/HW server are you talking about?

[Dirk Munk]

Really. This has nothing to do modern computing. These are the wet
dreams of managers and sales people. They want to hire cheap staff with
no knowledge. They rely on service level agreements with other companies
to deliver the knowledge they need. That's another aspect of modern
management, if you have the feeling you don't quite have grip on what's
happening, throw it over the wall to someone else. However those other
companies are also led my modern managers, that means spend as little
time as possible for your client, and charge as much as possible.

The result of this kind of thinking are poorly performing computer
systems overspending in hardware (too slow? Buy a bigger computer), and
many waisted hours by the people who rely on the computers.

There was a survey about what people hated most on ICT. The result? The
poor performance, the long waiting times. Is it because the computers
are too small? No, lousy applications, poor database design, poor
installations and poor if any tuning.

I have increased the performance of computer systems 10-fold by just a
bit of tuning. And these computers had a 'standard' setup, as you would
like to see.

So I'm sorry, but your ideas stink, I have seen the results, and it sucks.

[Chris]

On 09/25/16 21:57, Dirk Munk wrote:

> There was a survey about what people hated most on ICT. The result? The
> poor performance, the long waiting times. Is it because the computers
> are too small? No, lousy applications, poor database design, poor
> installations and poor if any tuning.
>
> I have increased the performance of computer systems 10-fold by just a
> bit of tuning. And these computers had a 'standard' setup, as you would
> like to see.
>
> So I'm sorry, but your ideas stink, I have seen the results, and it sucks.
>

On that, we are in complete agreement :-). There have been similar
threads on the pprune website about pilot training and deskilling
the process of flying aeroplanes. Problem there is a bit more serious
though as when the automatics give up, the crew don't have a clue
in some cases how to fly manually and prevent the thing falling out
of the sky. Have a detailed look at the AF447 incident for a classic
example...

Regards,

Chris

[Chris]

On 09/25/16 21:17, Kerry Main wrote:

>

> In large shops, you want a common multi-platform console log
> strategy
as part of the enterprise mgmt. strategy. You do not want individual
OS's each with a separate or proprietary console log solution that will
not fit into the enterprise strategy.
>
> In some cases for security reasons, you want the console log
> strategy
to be totally separate from the host OS or network device so a
OS/network priv'ed person cannot change the console log files that might
be stored on the local server. For audit purposes, you may even want the
console log files backed up as part of your data mgmt. strategy.
>
> What Apple has does not fit this corporate requirement, hence my
earlier question about what OS/HW server are you talking about?

Sun Sparc machines have this capability for years, with a
separate management embedded processor and associated network
based ilom port. That supports http or ssh access and can
monitor and control all aspects of machine operation. There is
also a serial management port offering a subset of the same
functionality.

Proliants may have some of this as well, though haven't used
it...

Regards,

Chris

[Dirk Munk]

A simple calculation tells us how silly this way of thinking is.

Suppose 100 people are using a server for 5 years. that means they are
using the server for 5 x 100 x 1800 hours = 900,000 hours. By tuning the
server its performance increases by 25%. That means you can save 225,000
hours. Compare that with the let's say 20 hours it would cost you to
tune the system.

[Scott Dorsey]

In article <ns9j15$b32$2...@gioia.aioe.org>, Chris <sys...@gfsys.co.uk> wrote:
>
>Sun Sparc machines have this capability for years, with a
>separate management embedded processor and associated network
>based ilom port. That supports http or ssh access and can
>monitor and control all aspects of machine operation. There is
>also a serial management port offering a subset of the same
>functionality.
>
>Proliants may have some of this as well, though haven't used
>it...

Proliants and Dell machines have it, using a standard ILO interface
processor from Intel. It is very, very standardized across platforms
and works well.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Chris via Info-vax
> Sent: 25-Sep-16 6:28 PM
> To: info...@rbnsn.com
> Cc: Chris <xxx.sys...@gfsys.co.uk>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

Lots of systems have dedicated ILO's, mgmt. processors (including
OpenVMS.. the Nautilus family of VAX's had separate Pro380 PC's),
but Steve's point was that these separate mgmt. functions and
serial consoles are a thing of the past. I disagree.

Even HPE's newest generation of ProLiant's have separate mgmt.
functions that include a serial console capability which provides
the capability to plug into a larger secure enterprise console
management strategy.

A secure serial console is an integral component of an overall
integrated multi-platform enterprise console management strategy.

[David Froble]

Indeed!

There should be mandatory aerobatic training as part of advanced ratings.
Paperwork may be #1 for the FAA, but it doesn't do squat in the cockpit.

[David Froble]

Customer rules:

1) The customer is always right
2) When the customer is wrong, refer to rule #1


Manager rules:

1) The manager is always right
2) When manager is wrong, refer to rule #1

See how we got to where we are today?

[Chris]

On 09/26/16 00:21, Kerry Main wrote:

>
> Lots of systems have dedicated ILO's, mgmt. processors (including
> OpenVMS.. the Nautilus family of VAX's had separate Pro380 PC's),
> but Steve's point was that these separate mgmt. functions and
> serial consoles are a thing of the past. I disagree.

The advantage of network based ilom is that it fits in well with
existing infrastructure and if it has it's own dedicated hardware
interface, is easy to aggegate and secure into an isolated
management subnet. While serial consoles are ok, some are rj45,
some are db9, which makes it difficult to find a common solution.
Also, you then need a serial to tcp server to get the whole lot onto
the network. There are still times though, when only a laptop
into the console port can get the job done...

Regards,

Chris

[Dirk Munk]

Let me give you a real world example of the results of this kind of
thinking.

An applications wasn't performing very well, it was a bit unclear why,
but there were more problems at that datacenter.

So we gave that application a brand new x86 server with 32GB of memory,
in another datacenter.

First it got a *standard* linux installation. Then the SAN luns were
added. I know how important disk alignment is, so I personally took care
of partitioning and formatting the luns, that was not a standard way of
setting up the luns.

Then the application was installed. I had told the database
administrator several times to make sure his databases got sufficient cache.

A few months later my network colleague asked me if it was normal that a
database fetch took a certain amount of time. I told him that was far
too much, and asked him about the application.

And as you can guess it was this application. First I couldn't
understand why, but then I got a suspicion.

I went to the database group, and asked how much free memory that system
had, and yes, it was 29GB.

So I asked about the database settings. Well, they had done a *standard*
Oracle install, with 1GB of cache per database, leaving 29GB wasted.

I suppressed some curses, and kindly asked them to increase the caches,
and to use the memory in the system.

That solved the problem, as you can guess.

An exception? No a *standard* problem with all those *standard*
installations. So much so that the support people now have the
*standard* reply "check your database cache and your free memory" when
they are confronted with performance problems.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Chris via Info-vax
> Sent: 26-Sep-16 12:35 PM
> To: info...@rbnsn.com
> Cc: Chris <xxx.sys...@gfsys.co.uk>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

The advantage of a serial is that, like TCPIP for networking, it
is a lowest common standard for consoles to almost every IT
device (network, storage, servers, appliances). While console
outputs might differ between DB9/RJ45, the adapters to each are
common and available in any local computer shop.

With an enterprise secure console management solution in place,
one can quickly implement a common mgmt. policy to all these
different devices. For the same reason you do not want a server
sysAdmin to have update/change access to server logs, the same
applies to VM's, network and storage devices as well.

VM console Support:
http://bit.ly/2cyEiCw

In terms of aggregation, many large shops (especially outsourcers
and cloud providers) have dedicated VLANs for specific functions
and higher levels of security. One common VLAN subnet is often
called MGMT which is the VLAN that console mgmt., ILO's, server
mgmt. access etc are all plugged into. Its often the subnet where
patches are rolled out to minimize regular net traffic impact.
The last thing one would want is to have someone crack a firewall
(internal or external) and then have direct access to a TCPIP
address for an ILO port. These need to be on a separate VLAN
with additional security at the network level applied to them.

As mentioned earlier in the thread, ConsoleWorks from TDI is a
good example of a multi-platform console mgmt. product. Btw, it
also supports OpenVMS not only as a client, but also OpenVMS as
the central hub ConsoleWorks server.

https://www.tditechnologies.com/products/consoleworks-server

Console management whitepaper from TDI:
http://bit.ly/2dbtxnv

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Dirk Munk via Info-vax
> Sent: 26-Sep-16 2:55 PM
> To: info...@rbnsn.com
> Cc: Dirk Munk <mu...@home.nl>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

And to put things into further perspective as to why one needs L2 folks to install (L1 ok to do daily admin) - things are going to get a lot more complex.

As an example - BL890 OpenVMS blade servers now support up to 1.5TB of local memory. How big is even a selective system crash dump file going to be? Would you even create one or wait for issues? What are process quota's?

And that TB number will surely be going up as cheap new non-volatile memories appear next year from Intel (3D XPoint) and others.

This is going to require a re-think of not only the server tuning but also DB and storage tuning as well. The classic "many, many small rack servers connected by slow LAN latency networks" vs "much smaller numbers of very large blade servers" is going to come up (app specific considerations).

Even with file storage - I have a local 2TB disk (mirrored 3rd party 2 TB drives- not supported but works great) on my local rx2600. Cost for 2 drives, case enclosure and LSI controller was total about CAD$400. For Cust's who struggle with disk storage, this is going to require a re-think as well. I can store 20 full system image backup files (6GB or less each) and at 180GB have not even used up 10% of the available space on that volume. With 10TB single drives now available (support in next file system on OpenVMS), one has to again, re-think how files will be managed in the future.

With a 2TB common system disk, other than app specific hot files, is there still the same push to move apps off the system disk? How to do layout the App directory structures?

[google BarraCuda Pro drives for info on 10TB drives]

Here is output from this big (and really cheap) disk "show device" on my system:
Free blocks = 3556200960 (1.65TB)
Total blocks = 3905980417

:-)

[Chris]

On 09/26/16 19:10, Kerry Main wrote:

>
> The advantage of a serial is that, like TCPIP for networking, it
> is a lowest common standard for consoles to almost every IT
> device (network, storage, servers, appliances). While console
> outputs might differ between DB9/RJ45, the adapters to each are
> common and available in any local computer shop.
>

I agree, console access is essential, but I need to have network
access. There 7 devices here with serial ports. Found a Moxa
8 port Moxa remote rs232 tcp server. The main problem was
that the Mox box rj45 are not compatible with the usual Cisco / Sun
console pinouts. Some consoles needed db9, while others needed
RJ45 Sun pinout, but wanted to use standard network pin to pin
Sun console cables. It would have been a pain to make all those
cable, so found a 16 port rj45 patch panel, half an hour wiring
it up in pairs to translate the pinouts and voila, standard cheap
cables finish the job

[Chris]

n 09/26/16 19:10, Kerry Main wrote:

Sorry, can't delete the last message, incomplete :-)...

>
> The advantage of a serial is that, like TCPIP for networking, it
> is a lowest common standard for consoles to almost every IT
> device (network, storage, servers, appliances). While console
> outputs might differ between DB9/RJ45, the adapters to each are
> common and available in any local computer shop.
>

I agree, console access is essential, but I need to have network

access. There 7 devices in the rack with serial ports. Found a
Moxa 8 port rs232 tcp server from the usual source. Listed
as "doesn't power up", which turned out to be a simple power
supply fault. The only fly in the ointment was that the Moxa
rj45 pinouts are not compatible with the usual Cisco / Sun
console pinouts. Some consoles here are db9, while others have
RJ45 Sun pinout. To keep it all neat and tidy, wanted to use
standard network pin to pin and Sun console cables. It would have
been a real pain to make them, so located a 16 port rj45 patch
panel, half an hour wiring it up idc in pairs to translate
the pinouts and voila, standard cheap cables finish the job.
We have 1 serial port spare, but Moxa make a 16 port model if we
get stuck. To access, just telnet into the Moxa (password
protected) with a port number...

Regards,

Chris

[David Froble]

It's sort of difficult for an application vendor to have one size fitting all.

Yes, they could have a tool that looks at system memory, then uses all of it,
regardless of whether other applications also need a bit of memory.

For the most part, they ship a "standard" set-up, and some might even provide
some tuning tips.

So, one size most likely won't fit all. Is there answers? Yes, to some extent.
We've had AUTOGEN since forever. It can be helpful. It can also hurt, in
some cases. Could it be improved? I'd say that the environments AUTOGEN was
developed for really don't exist anymore. An enhanced / new version might
handle GB of available memory in a different manner than there were no GB of
memory. But it still won't be "everything".

There will always be a need for more, even if the beancounters don't want to pay
for what they might need.

[Dirk Munk]

True, but this was a tailor made application, and the vendor was well
aware of the type of system he would get for his application.

>
> Yes, they could have a tool that looks at system memory, then uses all
> of it, regardless of whether other applications also need a bit of memory.

Not all of course, but when 29GB of the 32GB are not in use ..........

>
> For the most part, they ship a "standard" set-up, and some might even
> provide some tuning tips.
>

Like I mentioned before, this was a tailor made application.

> So, one size most likely won't fit all. Is there answers? Yes, to some
> extent. We've had AUTOGEN since forever. It can be helpful. It can
> also hurt, in some cases. Could it be improved? I'd say that the
> environments AUTOGEN was developed for really don't exist anymore. An
> enhanced / new version might handle GB of available memory in a
> different manner than there were no GB of memory. But it still won't be
> "everything".

Yes, we recently had that discussion in the group. Most likely many
autogen parameters are more or less obsolete, meaning that you can give
them such a high value that the OS never will need a higher value, so no
need to set them any more with a utility like autogen.


Anyway, the idea that setting up a tuned system is difficult and takes a
lot of time is ludicrous. An experienced system manager just knows what
to do, he doesn't have to try to find a solution.

One person who knows what he's doing can accomplish something in
minutes, that people without knowledge can't solve.

Managers don't like ICT, they don't understand it. They don't understand
why things have to be replaced, or updated, and so on. So if some one
comes along and tells them that they can have standard solutions for all
of their problems, and that they don't need well educated staff for
that, they just love it. Lower costs, that's what they like. That all
kind of hidden costs will skyrocket, that they don't understand.

[David Froble]

Well, isn't that what happened with weendoze and PCs?

With PCs, there was the perception that "we don't need no stinkin DP dept".

Same thing with weendoze.

Hey, it appeals to some mgt types, and to some extent, some IT staff caused the
antagonism. When users could bypass them, they were quick to do so. Took a
while, but in some cases the people paying for all this saw costs going through
the roof. In other cases, the PCs were a good fit.

There have been Codis users back thru the years that have sometimes coveted the
"greener" grass they thought they saw. Some were rather stubborn about it, but
in the end they realized who had the best solution. A bit of a roller coaster
ride, but in the end, I'm sort of glad that I don't get stupid questions
anymore. Too old for that crap ....

[IanD]

That's interesting about the survey and performance issues. We are nearing the end of simply being able to crank up CPUs faster and faster. We either go the way of parallel and/or its back to people in white coats tuning and tweaking and knowing their customers load and business again instead of half whit monkeys just saying, buy a bigger system

[Dirk Munk]

IanD wrote:
> That's interesting about the survey and performance issues. We are nearing the end of simply being able to crank up CPUs faster and faster. We either go the way of parallel and/or its back to people in white coats tuning and tweaking and knowing their customers load and business again instead of half whit monkeys just saying, buy a bigger system
>

*NO*, not people in white coats. Just people who know what they are
doing, who understand how computers work. People who can read a manual,
even to find someone who can actually find something in a manual is a
miracle these days.

Now of course this kind of people is also interested in figuring out how
you can improve performance. These are the kind of people who read about
and try out options etc.

[Bob Koehler]

In article <ns3ogl$sbq$3...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
> Bob Koehler wrote:
>> In article <32d1c9c9-97a7-45ca...@googlegroups.com>, IanD <iloveo...@gmail.com> writes:
>>> I assume when they mean 'older stack' they are meaning TCPIP Services?
>>>
>> Yes, the one many of us still stubbornly refer to as UCX, is what I
>> assumed, too. What other 'older stack' would VSI have, that they
>> could plan its demise?
>>
>
> Got to wonder why you are stubborn. UCX was the product prior to TCP/IP V5.
> The TCP/IP V5 stuff came from the T64 product. Not UCX.

It never got better, when compared to the other stacks that are
available.

[Paul Sture]

Even the humble HP(E) MicroServer has that now as part of the standard
offering (it used to be an optional extra):

<http://www8.hp.com/us/en/products/proliant-servers/product-detail.html?oid=5379860#!tab=features>

And while we are there, the Gen8 range now has 4 models, including a
couple of Xeons:

<http://www8.hp.com/us/en/products/proliant-servers/product-detail.html?oid=5379860#!tab=models>

[Jan-Erik Soderholm]

Would work well as an "OpenVMS x86-64" hobbyist system...
And besides, probably way more "power" in those then in
our current production DS20e's... :-)

[David Froble]

Bob Koehler wrote:
> In article <ns3ogl$sbq$3...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>> Bob Koehler wrote:
>>> In article <32d1c9c9-97a7-45ca...@googlegroups.com>, IanD <iloveo...@gmail.com> writes:
>>>> I assume when they mean 'older stack' they are meaning TCPIP Services?
>>>>
>>> Yes, the one many of us still stubbornly refer to as UCX, is what I
>>> assumed, too. What other 'older stack' would VSI have, that they
>>> could plan its demise?
>>>
>> Got to wonder why you are stubborn. UCX was the product prior to TCP/IP V5.
>> The TCP/IP V5 stuff came from the T64 product. Not UCX.
>
> It never got better, when compared to the other stacks that are
> available.
>

Yeah, and we know why. Someone would have to have given a damn, and HP sure didn't.

But it actually went all the way back to DEC. Perhaps some NIH ...

I've been able to "get by" with the product. But I haven't been able to get by
with SSL which should be an integral part of the product, and much easier to
use, and understand, and DECENT ERROR MESSAGES!!!

[Hans Bachner]

Bob Koehler schrieb am 23.09.2016 um 12:08:
> In article <e4kudc...@mid.individual.net>, Hans Bachner <ha...@bachner.priv.at> writes:
>> Bob Koehler schrieb am 23.09.2016 um 16:31:
>>> In article <mailman.9.1474490123.2...@rbnsn.com>, "Kerry Main" <kemain...@gmail.com> writes:
>>>>
>>>> In terms of ease of testing, I currently have installed both
>>>> Multinet V5.5 and TCPIP V5.7 stacks on my VSI OpenVMS V8.4-2L1
>>>> rx2600 lab system. While I cannot speak to how the VSI product
>>>> will behave or what it will look like, today, I can flip from one
>>>> stack to the other by simply enabling /disabling the appropriate
>>>> startup file in the systartup_vms.com file and then reboot.
>>>
>>> Is it that simple if you're clustering over IP? Clustering means
>>> the IP stack gets loaded before the startup scripts are run.
>>
>> I don't think so - afaik IP as a cluster interconnect is only supported
>> with the HP TCP/IP stack.
>
> Multinet suppports it and I have it running in my hobbyist cluster.

Thanks for the info (to Kerry as well) - learning new stuff all the time.

Question is - will HPE also support cluster communication over Multinet?

If not, you're n for lively discussions who's fault it is if something
does not work as expected.

Hans.

[IanD]

By white coat, I meant people who actually know something in-depth versus the skim readers and/or show me the command to fix the whole universe so I can go to coffee crowd :-)

I find people struggle to even read an email properly these days.

I dread dealing with IT support folk who, even though you number or bullet-point your questions and do the old quality confirmation statement such as '2 (two)', etc, all you get back is some half-arsed response to your first point only

Even simple things like the ability to concentrate on something longer than 30us is too hard for a lot of folk

Yep, the world is becoming dumber by the minute IMO

[Dirk Munk]

IanD wrote:
> On Tuesday, September 27, 2016 at 6:18:37 PM UTC+10, Dirk Munk wrote:
>> IanD wrote:
>>> That's interesting about the survey and performance issues. We are nearing the end of simply being able to crank up CPUs faster and faster. We either go the way of parallel and/or its back to people in white coats tuning and tweaking and knowing their customers load and business again instead of half whit monkeys just saying, buy a bigger system
>>>
>>
>> *NO*, not people in white coats. Just people who know what they are
>> doing, who understand how computers work. People who can read a manual,
>> even to find someone who can actually find something in a manual is a
>> miracle these days.
>>
>> Now of course this kind of people is also interested in figuring out how
>> you can improve performance. These are the kind of people who read about
>> and try out options etc.
>
> By white coat, I meant people who actually know something in-depth versus the skim readers and/or show me the command to fix the whole universe so I can go to coffee crowd :-)

Ah, I see what you mean, and of course I can agree with you.

>
> I find people struggle to even read an email properly these days.
>
> I dread dealing with IT support folk who, even though you number or bullet-point your questions and do the old quality confirmation statement such as '2 (two)', etc, all you get back is some half-arsed response to your first point only

Very true, I have the same experience. Always use bullets or numbers in
front of your questions, otherwise people don't grasp what you're
writing. The same is true for reports etc. to managers, always use bullets.

[David Froble]

IanD wrote:

> I dread dealing with IT support folk who, even though you number or
> bullet-point your questions and do the old quality confirmation statement
> such as '2 (two)', etc, all you get back is some half-arsed response to your
> first point only

This drives me crazy. I find myself fighting it by sending separate email
messages. One per question. Nor does that work, they see the same person, and
assume it's the same question.

[Bob Koehler]

In article <e50r71...@mid.individual.net>, Hans Bachner <ha...@bachner.priv.at> writes:
>
> If not, you're n for lively discussions who's fault it is if something
> does not work as expected.

I've seen that problem with other vendors, but I've never had that
problem with any of the owners of Multinet.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Dirk Munk via Info-vax
> Sent: 28-Sep-16 9:32 AM
> To: info...@rbnsn.com
> Cc: Dirk Munk <mu...@home.nl>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

> IanD wrote:
> > On Tuesday, September 27, 2016 at 6:18:37 PM UTC+10, Dirk
> Munk wrote:

[snip..]

> >
> > I find people struggle to even read an email properly these
> days.
> >
> > I dread dealing with IT support folk who, even though you
> number or
> > bullet-point your questions and do the old quality
confirmation
> > statement such as '2 (two)', etc, all you get back is some
half-
> arsed
> > response to your first point only
>
> Very true, I have the same experience. Always use bullets or
> numbers in front of your questions, otherwise people don't
grasp
> what you're writing. The same is true for reports etc. to
> managers, always use bullets.
>
> >
> > Even simple things like the ability to concentrate on
something
> longer than 30us is too hard for a lot of folk
> >
> > Yep, the world is becoming dumber by the minute IMO
> >
>

This is similar to what was discussed on one of the US news
channels yesterday.

When on-air, It was stated that News people need to use a grade 8
vocabulary in order to reach their max audience.

The analysts stated Donald Trump has been using a grade 4
vocabulary i.e. very, very simple language (I am a winner, I am
great, name calling, you are a loser, high level generalities
like NAFTA is bad without any specific references to what parts
are bad) to reach his base audience.

Interesting times.

[Jan-Erik Soderholm]

Sure is. This is in Swedish news today:

http://www.azcentral.com/story/opinion/editorial/2016/09/27/hillary-clinton-endorsement/91198668/

I can not belive that Trump will be president in the end...

[Kerry Main]

Well, from an outsider looking in, Trump's self-destruct
tendencies are now kicking in.

Fwiw, deep down I really do not think Trump wants to win. I think
he wants the fame of running, but in the end he likes his
wheeling and dealing too much to have to give up control of his
business empire to someone else. He will also not like the press
magnification when his taxes are finally released to reveal all
of his "interesting" business connections. If he loses, he does
not have to reveal his taxes and he and his media cohorts can go
off and do their next project.

Very OT, but smile for the day -
Best cartoon I saw was a Trump ad with the voice over caption "I
am Vladimir Putin and I approved this message"

:-)

[David Froble]

Yep! And every one of them has one more vote than Einstein ....

[Henry Crun]

Remember: half the electorate is below average (and 'average' isn't so smart,
either...)

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Dirk Munk]

After Donald became the Republican nominee, Bill Maher commented that
"the question if Nazi Germany could happen in the US has now been
answered". What he meant was i.m.o. is that if so many people buy the
kind of BS that Trump is selling, that a man like Hitler could also be
elected.

[David Froble]

The thing everyone needs to remember is that those supporting Trump have issues
with how things are now. Those issues are very real, and most of them are
"good" people. Some of it has been caused by "smart" people not giving a damn
as long as the next quarter numbers look good, and, it goes downhill from there.

Not saying that I agree with Donald's solutions, because I do not.

Another thing to consider, on the Democratic side there also are people who are
unhappy, and they were supporting Bernie. Too bad the Democrat leadership had
already made up their mind on "more of the same".

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Dirk Munk via Info-vax
> Sent: 28-Sep-16 4:41 PM
> To: info...@rbnsn.com
> Cc: Dirk Munk <mu...@home.nl>
> Subject: Re: [Info-vax] VSI and Process Software announcement
>

[snip ..]

Re: politics -

Different country views regarding refugees and immigrants ..
without the political hyperbole: (we all come from somewhere
else)
https://youtu.be/28fPPfx6MAA

https://www.youtube.com/watch?v=tbg0S_CVgUQ


:-)

[Dirk Munk]

Sounds like Germany in 1933

> Some of it has been caused by "smart" people
> not giving a damn as long as the next quarter numbers look good, and, it
> goes downhill from there.

And it has been caused by the people of the US itself, by electing a
Democratic president, and then electing a Republican majority in both
houses of congress, and that majority had only one agenda, blocking
everything Obama wanted. Then indeed nothing gets done.

Add to that the general idea that taxes are very bad, and the federal
government can never be trusted, and you get a very poisonous atmosphere
where it is impossible to start major projects like rebuilding the
crumbling road infrastructure of the US.

>
> Not saying that I agree with Donald's solutions, because I do not.
>
> Another thing to consider, on the Democratic side there also are people
> who are unhappy, and they were supporting Bernie. Too bad the Democrat
> leadership had already made up their mind on "more of the same".

Bernie is a great man, but that doesn't mean he would have been a great
president. Look at Jimmy Carter, also a great man, but not a very good
president. However, he certainly is the best ex-president the US ever
had, he used his position as ex-president of the US all over the world
to bring peace.

Bernie did show the Democratic party that there is an enormous group of
young enthusiast voters on the left of what was their traditional
position the last decades. That may help to redefine the Democratic party.

The Republicans however are in deep trouble. They did the most stupid
thing they could have done, they started to believe their own BS. Now
they're stuck with lots of crackpots and lunatics in their party, and
"The Donald" is the superlative of this.

A highly respectable Republican statesman like Colin Powell can only
describe Trump as "A national disgrace, and an international pariah".

[Phillip Helbig (undress to reply)]

In article <4zYGz.718697$lr2.2...@fx16.ams1>, Dirk Munk <mu...@home.nl>
writes:

> And it has been caused by the people of the US itself, by electing a
> Democratic president, and then electing a Republican majority in both
> houses of congress, and that majority had only one agenda, blocking
> everything Obama wanted. Then indeed nothing gets done.

> Bernie is a great man, but that doesn't mean he would have been a great
> president. Look at Jimmy Carter, also a great man, but not a very good
> president. However, he certainly is the best ex-president the US ever
> had, he used his position as ex-president of the US all over the world
> to bring peace.

Wasn't Carter's main problem that he didn't have a majority in Congress?

> A highly respectable Republican statesman like Colin Powell can only
> describe Trump as "A national disgrace, and an international pariah".

Colin Powell would have probably won the Republican nomination, right?

[Dirk Munk]

Phillip Helbig (undress to reply) wrote:
> In article <4zYGz.718697$lr2.2...@fx16.ams1>, Dirk Munk <mu...@home.nl>
> writes:
>
>> And it has been caused by the people of the US itself, by electing a
>> Democratic president, and then electing a Republican majority in both
>> houses of congress, and that majority had only one agenda, blocking
>> everything Obama wanted. Then indeed nothing gets done.
>
>> Bernie is a great man, but that doesn't mean he would have been a great
>> president. Look at Jimmy Carter, also a great man, but not a very good
>> president. However, he certainly is the best ex-president the US ever
>> had, he used his position as ex-president of the US all over the world
>> to bring peace.
>
> Wasn't Carter's main problem that he didn't have a majority in Congress?

It's a long time ago, but it seems to me Jimmy Carter was just to much
of a decent guy to be an effective president. That may sound strange,
but a president sometimes (often?) has to make decisions he really
doesn't like to make.

>
>> A highly respectable Republican statesman like Colin Powell can only
>> describe Trump as "A national disgrace, and an international pariah".
>
> Colin Powell would have probably won the Republican nomination, right?
>

No, the Republican party has been spreading so much BS the past years,
that a moderate and intelligent man like Colin Powell has no chance
against the bunch of extremist idiots we have seen as Republican
candidates. The Republicans have been stirring up their potential voters
to a level that they lost control all together, and so we got The Donald.

[Phillip Helbig (undress to reply)]

In article <FL3Hz.874872$VL3.8...@fx13.ams1>, Dirk Munk <mu...@home.nl>
writes:

> > Wasn't Carter's main problem that he didn't have a majority in Congress?
>

> It's a long time ago, but it seems to me Jimmy Carter was just to much
> of a decent guy to be an effective president.

Maybe, but the lack of a majority in Congress didn't help.

He also demonstrated that one can have some measure of intelligence and
still say "nucular". :-|

> >> A highly respectable Republican statesman like Colin Powell can only
> >> describe Trump as "A national disgrace, and an international pariah".
> >
> > Colin Powell would have probably won the Republican nomination, right?
>

> No, the Republican party has been spreading so much BS the past years,
> that a moderate and intelligent man like Colin Powell has no chance
> against the bunch of extremist idiots we have seen as Republican
> candidates. The Republicans have been stirring up their potential voters
> to a level that they lost control all together, and so we got The Donald.

Actually, Trump is not as extreme as some of the other Republican
candidates. Look at their policies.

[Dirk Munk]

Phillip Helbig (undress to reply) wrote:

I'm sure, Donald doesn't have any coherent plans. His points of view
change by the day. With him it's all presentation, people love the way
he talks and makes promises. None of his followers seem to ask
themselves how these plans will become reality.

[Stephen Hoffman]

On 2016-09-26 20:10:40 +0000, Kerry Main said:

>
> And to put things into further perspective as to why one needs L2 folks
> to install (L1 ok to do daily admin) - things are going to get a lot
> more complex.
>
> As an example - BL890 OpenVMS blade servers now support up to 1.5TB of
> local memory. How big is even a selective system crash dump file going
> to be? Would you even create one or wait for issues? What are process
> quota's?
> And that TB number will surely be going up as cheap new non-volatile
> memories appear next year from Intel (3D XPoint) and others.
>
> This is going to require a re-think of not only the server tuning but
> also DB and storage tuning as well. The classic "many, many small rack
> servers connected by slow LAN latency networks" vs "much smaller
> numbers of very large blade servers" is going to come up (app specific
> considerations).
>
> Even with file storage - I have a local 2TB disk (mirrored 3rd party 2
> TB drives- not supported but works great) on my local rx2600. Cost for
> 2 drives, case enclosure and LSI controller was total about CAD$400.
> For Cust's who struggle with disk storage, this is going to require a
> re-think as well. I can store 20 full system image backup files (6GB
> or less each) and at 180GB have not even used up 10% of the available
> space on that volume. With 10TB single drives now available (support in
> next file system on OpenVMS), one has to again, re-think how files will
> be managed in the future.
> With a 2TB common system disk, other than app specific hot files, is
> there still the same push to move apps off the system disk? How to do
> layout the App directory structures?
> [google BarraCuda Pro drives for info on 10TB drives]
>
> Here is output from this big (and really cheap) disk "show device" on
> my system:
> Free blocks = 3556200960 (1.65TB)Total blocks = 3905980417
> :-)


And wouldn't it be nice if none of that were relevant?

I certainly hope that VSI does not continue with the worst of the mess
that exists now— the above is a demonstration of the utterly manual and
non-self-managing state of OpenVMS — and starts looking forward.

As two examples from recent technical discussions.... Rather than a
UI that is presently problematic for color-blind users and adding a way
to alter the colors, maybe slightly alter the display colors by
default, and make the UI more legible by default? That won't address
all users, but it'll help with some of the more common cases. Maybe
rather than cryptic configuration steps of moving files around to other
directories to enable certain additional and useful features, just turn
those features on by default, and give folks a way to disable that in
the unlikely event they need that? Maybe instead of
default-cleartext transports, use and encourage and recommend
encryption and secure transports by default? There were and are may
other conversations....

If OpenVMS doesn't start looking at simplifying and streamlining the
configuration and management and troubleshooting — and all the details
you've just pointed to — it'll effectively increase in difficulty to
install, more difficult to manage, more difficult to tune, and requires
more skilled and more costly staff. I'd prefer to see OpenVMS on the
"easier to use" end of the spectrum — it once was. It likely won't
ever get entirely easy, but that's a good goal. Where OpenVMS is now
is not a particularly good place for a sales and marketing effort,
particularly against far larger and established vendors, and where some
of the vendors are getting much easier to install and use.

As for our current requirements and practices and approaches? What
we do now had damned well better look like ancient and ugly history in
ten or twenty years — and too much of what we're obligated to do to
install and configure and manage OpenVMS now is increasingly becoming
or is ancient history on other platforms — or the platform is going to
be incrementally more difficult to sell outside the installed base.
And if OpenVMS doesn't sell outside the installed base in quantities
larger than the number of folks retiring or porting existing OpenVMS
applications, that only ends in one place. We all get to port. Those
of us that don't get to retire first, that is.



--
Pure Personal Opinion | HoffmanLabs LLC

[Bob Koehler]

In article <CVVGz.628530$uE7.4...@fx14.ams1>, Dirk Munk <mu...@home.nl> writes:

> What he meant was i.m.o. is that if so many people buy the
> kind of BS that Trump is selling, that a man like Hitler could also be
> elected.

The one relavent difference being that Hitler didn't like Jews, but
Trump doesn't like Muslims.

[David Froble]

Dirk Munk wrote:
> Phillip Helbig (undress to reply) wrote:
>> In article <4zYGz.718697$lr2.2...@fx16.ams1>, Dirk Munk <mu...@home.nl>
>> writes:
>>
>>> And it has been caused by the people of the US itself, by electing a
>>> Democratic president, and then electing a Republican majority in both
>>> houses of congress, and that majority had only one agenda, blocking
>>> everything Obama wanted. Then indeed nothing gets done.
>>
>>> Bernie is a great man, but that doesn't mean he would have been a great
>>> president. Look at Jimmy Carter, also a great man, but not a very good
>>> president. However, he certainly is the best ex-president the US ever
>>> had, he used his position as ex-president of the US all over the world
>>> to bring peace.
>>
>> Wasn't Carter's main problem that he didn't have a majority in Congress?
>
> It's a long time ago, but it seems to me Jimmy Carter was just to much
> of a decent guy to be an effective president. That may sound strange,
> but a president sometimes (often?) has to make decisions he really
> doesn't like to make.

Jimmy is a decent man, that had a hard time imagining that there are some very
un-decent people in this world.

>>> A highly respectable Republican statesman like Colin Powell can only
>>> describe Trump as "A national disgrace, and an international pariah".
>>
>> Colin Powell would have probably won the Republican nomination, right?
>>
>
> No, the Republican party has been spreading so much BS the past years,
> that a moderate and intelligent man like Colin Powell has no chance
> against the bunch of extremist idiots we have seen as Republican
> candidates. The Republicans have been stirring up their potential voters
> to a level that they lost control all together, and so we got The Donald.

Yep! Donald out extremed the rest, which is exactly what they deserved, for
starting the same 30+ years ago.

I have a friend in Utah, and we sometimes discuss things. There have been
several instances where he's mentioned his "concern" to me. This year it's
"they are going to take away our guns". Now, regardless which side of this
topic you support, what I've noticed is that the republicans have been using
"scare tactics" for a long time with some people, and it's getting them the
votes they crave. This is no way to run anything.

[Bill Gunshannon]

On 9/28/16 5:25 PM, David Froble wrote:
>
>
> Another thing to consider, on the Democratic side there also are people
> who are unhappy, and they were supporting Bernie. Too bad the Democrat
> leadership had already made up their mind on "more of the same".

I really should know enough to stay out of this stuff, but what
the heck.

Bernie is a career politician. How would he have not been "more
of the same"

bill

[Bill Gunshannon]

Jews weren't trying to take over the world and impose Halakha on
everyone. They also didn't go around blowing up innocent bystanders.

bill

[Dirk Munk]

That is only a small minority. And in case you haven't noticed, Muslims
are killing far more fellow Muslims then non-Muslims.

Many Muslims hate the extremists.

[Dirk Munk]

You automatically assume a career politician is something bad so it
seems. But why, it can be a job like any other. A man like Winston
Churchill also was a career politician.

[David Froble]

Why do you always have to interject some reality?

:-)

He didn't like the banks and insurance companies. That alone says a lot.

But you are correct, and I'd have to ask, what else will we ever have to choose
between except career politicians?