modern ssh on the old stack (VSI) versus new VSI stack (documentation)

[gérard Calliet]

Hello,

Because I think you have a lot of time at home now, I have a question.

With VSI tcpip new stack, I have a lot of information in the SPD about
what can be done with ssh, for example:

"""SSH functionality has been extended to include the following:
• Diffie-Hellman-group14-sha256 (RFC 4250). This addition improves
security of the key exchange by using a hash with more bits.
• Elliptic curve Diffie-Hellman (ECDH) key agreement [RFC 5656]. Curves
are: nistp256, nistp384, nistp521. The curve chosen will be sufficient
to support the hash for the host keys involved. For example: o If the
host key is ECDSA-nistp521, only the curve nistp521 will be available. o
If the host key is ECDSA-nistp384, the curves nistp384 and nistp521 will
be available. o If the host key is ECDSA-nistp256, the curves nistp256,
nistp384 and nistp521 will be available.
• Elliptic curve digital signature algorithm (ECDSA) [RFC 5656]. Public
keys are written in a format close to what is used by OpenSSH; OpenSSH
public keys can be read as-is. The "Subject" and "Comment" lines in the
key may need to be removed to make the keys readable by OpenSSH. ECDSA
supports curves nistp256, nistp384, nistp521.
..... """

I cannot find something precise like that for the last versions of the
old tcpip stack delivered by VSI, including all good ECOs.

It is important for me to know about that to be able to determine if the
last versions of tcpip/ssh on the old stack (for itanium and for alpha)
are reasonably usable in the modern world, before being able to use the
new stack. Another reason behind that is knowing if is worth it to go to
VSI and tcpip (old stack) only to have more functionalities on ssh.

Take care

Gérard Calliet

[Jim]

I can't tell you which key exchange algorithms are present in the older VMS
SSH implementations nor if those are well documented, but if you have one
installed you can use DEBUG level 3 on an SSH connection to localhost and
observe what is offered. With MultiNet's SSH I would do this:

$ ssh/debug=3 localhost.

and observe something like the following right near the beginning of the
SSH conversation.

[...]
debug: (10:42:53)Ssh2Trans/SSHTRANS.C;1:65: kex_algorithms = ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug: (10:42:53)Ssh2Trans/SSHTRANS.C;1:66: host_key_algorithms = x509v3-ecdsa-sha2-nistp521,x509v3-ecdsa-sha2-nistp384,x509v3-ecdsa-sha2-nistp256,x509v3-ssh-dss,x509v3-ssh-rsa,x509v3-rsa2048-sha256,x509v3-sign-dss,x509v3-sign-rsa,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa2048-sha256,ssh-dss,ssh-rsa

debug: (10:42:53)Ssh2Trans/SSHTRANS.C;1:67: ciphers_c_to_s = aes12...@openssh.com,aes25...@openssh.com,aes128-ctr,aes128-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc,3des-ctr,3des-cbc,blowfish-ctr,blowfish-cbc,none

debug: (10:42:53)Ssh2Trans/SSHTRANS.C;1:68: ciphers_s_to_c = aes12...@openssh.com,aes25...@openssh.com,aes128-ctr,aes128-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc,3des-ctr,3des-cbc,blowfish-ctr,blowfish-cbc,none

debug: (10:42:53)Ssh2Trans/SSHTRANS.C;1:69: macs_c_to_s = hmac-sha2-256,hmac-sha2-512,hmac-sha256,hmac-sha1,hmac-md5,none

debug: (10:42:53)Ssh2Trans/SSHTRANS.C;1:70: macs_s_to_c = hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5,none

debug: (10:42:53)Ssh2Client/SSHCLIENT.C;1:1765: Creating transport protocol.

debug: (10:42:53)Ssh2Transport/TRCOMMON.C;1:4238: available kex algorithms:ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug: (10:42:53)Ssh2Transport/TRCOMMON.C;1:4256: guessed kex ecdh-sha2-nistp256, host key x509v3-ecdsa-sha2-nistp521

[Craig A. Berry]

Doing ssh -vvv to the following system:

$ tcpip show vers

HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5
on an HP rx2660 (1.67GHz/9.0MB) running OpenVMS V8.4-2L1

$ prod show hist *tcp*
------------------------------------ ----------- ----------- --- -----------
PRODUCT KIT TYPE OPERATION VAL DATE
------------------------------------ ----------- ----------- --- -----------
VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 09-MAR-2018
VSI I64VMS TCPIP_NFS_PAT V5.7-ECO5C Patch Install Val 21-DEC-2017
VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D Patch Install Val 21-DEC-2017
VSI I64VMS TCPIP V5.7-13ECO5F Full LP Install Val 21-DEC-2017
VSI I64VMS TCPIP V5.7-13ECO5 Full LP Remove - 21-DEC-2017
VSI I64VMS TCPIP V5.7-13ECO5 Full LP Reg Product (U) 21-DEC-2017
------------------------------------ ----------- ----------- --- -----------
6 items found

I see the following algorithms and ciphers listed:

debug2: KEX algorithms:
curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms:
ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ssh-ed2551...@openssh.com,rsa-sha2-5...@openssh.com,rsa-sha2-2...@openssh.com,ssh-rsa-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos:
chacha20...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com
debug2: ciphers stoc:
chacha20...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com

[gérard Calliet]

Thanks Jim, thanks Creg

I think I missed the "VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D" ECO, which is
not included in the general "VSI I64VMS TCPIP V5.7-13ECO5F" ECO, as
staded in anothe thread.

I have'nt an VSI Alpha up to date TCPIP.

So I cannot do the same test now on Alpha. And it seems there is not
anywhere the same good documentation on TCPIP "old" stack as for the
"new". But VSI sells the two, and could perhaps give same level of
information for the two.

Gérard Calliet

[gérard Calliet]

Le 25/03/2020 à 19:49, Craig A. Berry a écrit :

> I see the following algorithms and ciphers listed:
>
> debug2: KEX algorithms:
> curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c

Hello,

How do you get this output? I have the same patches,
and I tried a $ ssh -d 2 localhost
and I don't get the "debug2" lines.

Where am I wrong?

Gérard Calliet

[Richard Whalen]

On Wednesday, March 25, 2020 at 1:02:21 PM UTC-4, gérard Calliet wrote:

You may have to go up to a higher debug level. I had to use debug 3 with MultiNet SSH (which the VSI SSH is based on) to get the algorithms displayed.

[Craig A. Berry]

I did "ssh -vvv" from the shell of a non-VMS system. Someone has posted
elsewhere in the thread that ssh/debug=3 might be the equivalent on VMS.

[gérard Calliet]

Thanks.
You are a lucky man, Craig, because you get all the new KEX algorithms,
and not me.

I confirmed that using >>ssh -vvv from windows, and I don't get them.

(Perhaps I have another issue because from the CMD of windows I get also
that:
"""Unable to negotiate with 10.0.10.70 port 22: no matching host key
type found. Their offer: ssh-dss"""

Perhaps this type of key (which is supported by Putty, and not by
Windows ssh form cmd) involve restriction on the set of KEX algorithms
but I doubt.)

I had an exchange with VSI support, and it seems the maintenance of the
"old" stack is a minima, and they don't garanty to have the new
algorithms. Perhaps you have got them passing throught a narrow window
with a good installation of the patches by specific times and order (I
have got the same, but without the algorithms).

Gérard Calliet

[Stephen Hoffman]

On 2020-04-05 16:10:27 +0000, g 駻ard Calliet said:

> You are a lucky man, Craig, because you get all the new KEX algorithms,
> and not me.

All HPE and VSI TCP/IP Services new patches will end this year. If we
haven't already seen the last new patch for ssh and otherwise.

You're apparently still on an OpenVMS version from the vendor that's
exiting the platform, and with all new patches ending this year. An
end to new patches which should be a surprise to exactly nobody.

Which means you're here either off support, or soon falling off HPE
new-patch support, or you're acquiring VSI licenses and upgrading to
supported VSI OpenVMS versions.

Which means you're either going to downgrade your connections, or *try*
to perpetually isolate the OpenVMS systems, or find or port an ssh
client and/or server to OpenVMS, or use intermediate hosts or VPNs to
upgrade or downgrade connections.

How long you can manage to maintain connectivity (with or without ssh
downgrades) is not predictable. That depends on what flaws might be
identified, and on which systems these OpenVMS servers are
interoperating with.

I'm already routinely downgrading connections to access HPE OpenVMS and
HPE Integrity iLO management. That's only going to become more common,
for those that haven't upgraded OpenVMS.

Many sites are also using iLO management hardware and with known
security issues, and that cannot be upgraded to modern security.

Hopefully with the VSI IP version for OpenVMS Alpha (still) arriving
2020H2, and that migration is going to be a bit of a scramble for some
folks that want or need to maintain support.



#!/bin/bash
# sethost script to connect to remote systems, using whatever
# connection protocol and command is appropriate for the
# target server. ssh, telnet, whatever.
#
# with ssh, this script can be substituted for an entry added into
# the ssh configuration file to downgrade the connection. When
# connecting into HPE OpenVMS servers:
#
#Host server.example.com
# HostKeyAlgorithms ssh-dss
# KexAlgorithms diffie-hellman-group1-sha1
#
# This as most HPE OpenVMS systems and iLO have too-old
# ssh servers.
#
# The related ssh downgrade command follows:
#
# ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 Us...@Server.Example.Com
#
if [ "$1" = "-h" ]
then
echo "Issues the ssh command to the specified host"
echo "usage: $0 [option] [host]"
echo " -h display this help text"
exit
fi

host=`echo $1 | tr a-z A-Z`
case "${host}" in
FOO)
ssh -q hof...@foo.example.net
;;
CLUSTER | VMS1 | VMS2 )
ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 Hof...@Example.Org
;;
* )
echo "Unrecognized destination host $1 specified"
;;
esac
echo " "


--
Pure Personal Opinion | HoffmanLabs LLC

[Craig A. Berry]

On 4/5/20 12:08 PM, Stephen Hoffman wrote:

> On 2020-04-05 16:10:27 +0000, g érard Calliet said:
>
>> You are a lucky man, Craig, because you get all the new KEX
>> algorithms, and not me.
>
> All HPE and VSI TCP/IP Services new patches will end this year. If we
> haven't already seen the last new patch for ssh and otherwise.
>
> You're apparently still on an OpenVMS version from the vendor that's
> exiting the platform, and with all new patches ending this year.  An end
> to new patches which should be a surprise to exactly nobody.

No, he confirmed up-thread that he has the VSI version of TCP/IP
Services, but did say:

[I think I missed the "VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D" ECO, which

is not included in the general "VSI I64VMS TCPIP V5.7-13ECO5F" ECO, as

staded in anothe thread.]

It was not clear to me whether g érard ever managed to locate and
install that. Since he opened a support call with VSI, it would be
their fault if he didn't. Unless I have it confused with something
else, I think this patch kit is located in its own directory on the
system install image, unlike any other TCP/IP ECO (which have generally
been full install kits) or really any other ECO I can remember. It is
not listed in the VSI_MASTER_KIT_LIST.TXT and I could not find it
anywhere in the VSI ECO download area just now.

The OS release notes here:

<https://www.vmssoftware.com/pdfs/VSI_OpenVMS_V842L1_CLRN.pdf>

say:

"The VSI TCP/IP V5.7 product includes the SSH patch kit VSI-I64VMS-
TCPIP_SSH_PAT-V0507-ECO5D-4 which is an optional kit that can be
selected during the VSI TCP/IP kit installation."

So you may have to reinstall TCP/IP services to get it. I thought I
remembered seeing it as an installation option when I booted from the OS
DVD, but can't say for sure.

> # with ssh, this script can be substituted for an entry added into
> # the ssh configuration file to downgrade the connection.  When
> # connecting into HPE OpenVMS servers:
> #
> #Host server.example.com
> #    HostKeyAlgorithms ssh-dss
> #    KexAlgorithms diffie-hellman-group1-sha1

That's a good tip, unfortunate that it is that it's necessary.

[Stephen Hoffman]

On 2020-04-05 19:32:48 +0000, Craig A. Berry said:

> On 4/5/20 12:08 PM, Stephen Hoffman wrote:

>> On 2020-04-05 16:10:27 +0000, g ้rard Calliet said:
>>
>>> You are a lucky man, Craig, because you get all the new KEX algorithms,
>>> and not me.
>>
>> All HPE and VSI TCP/IP Services new patches will end this year. If we
>> haven't already seen the last new patch for ssh and otherwise.
>>
>> You're apparently still on an OpenVMS version from the vendor that's
>> exiting the platform, and with all new patches ending this year.  An
>> end to new patches which should be a surprise to exactly nobody.
>

> No, he confirmed up-thread that he has the VSI version of TCP/IP Services...

My understanding of all this...

That's (still) the HPE TCP/IP Services stack.

VSI reportedly doesn't have source code to that stack.

The TCP/IP Services stack will seemingly be out of support by 2021,
unless VSI has some sort of extended-support deal with HPE.

This being the entirety of why we are and will be migrating to the VSI
IP stack.

[erga...@gmail.com]

On Sunday, 5 April 2020 20:46:30 UTC+1, Stephen Hoffman wrote:

> This being the entirety of why we are and will be migrating to the VSI
> IP stack.

The model of making a shim for the (now unmaintained) Tru64 code didn't appear to be a sustainable one, whether VSI has access to the HPE code or not.

[Stephen Hoffman]

The idea that an operating system in 2020 has an add-on,
layered-product, optionally-installed implementation of IP networking
with grafted-on security is unfathomable. But here we are.

[Craig A. Berry]

On 4/5/20 2:46 PM, Stephen Hoffman wrote:
> On 2020-04-05 19:32:48 +0000, Craig A. Berry said:
>
>> On 4/5/20 12:08 PM, Stephen Hoffman wrote:

>>> You're apparently still on an OpenVMS version from the vendor that's
>>> exiting the platform, and with all new patches ending this year.  An
>>> end to new patches which should be a surprise to exactly nobody.
>>
>> No, he confirmed up-thread that he has the VSI version of TCP/IP
>> Services...
>
> My understanding of all this...
>
> That's (still) the HPE TCP/IP Services stack.

Now I get what you mean, but most of VMS is still the DEC/Compaq/HP/HPE
operating system, yet we refer to the VSI-branded versions as VSI
OpenVMS, not HPE OpenVMS, so I find it confusing to refer to the
VSI-branded TCP/IP Services as "from the vendor that's exiting the
platform." Everything that hasn't been written or rewritten by VSI is
from the old vendor.

> VSI reportedly doesn't have source code to that stack.
>
> The TCP/IP Services stack will seemingly be out of support by 2021,
> unless VSI has some sort of extended-support deal with HPE.

> This being the entirety of why we are and will be migrating to the VSI
> IP stack.

Oh. I thought it was because it sucked, not because VSI didn't even
have the necessary access to maintain it. I assumed the old stack would
be maintained until the new one was ready for prime time just like all
the other old stuff. One more thing about the transition that was even
more precarious than I realized.

[gérard Calliet]

It's all about general transition here in France. And being able to help
customers to find interests (immediate and more long term). And helping
them building sustainable transition strategies.

I am testing installations (Itanium, Alpha) from scratch with all I
could get from VSI. And testing IF it could be of interest for customers
to begin a transition using the inherited TCPIP stack, before going at
their pace to the new stack.

It seems that it is a bit chaotic regarding kits and patches contents,
regarding things like Kew algorithms.

I had to discover something best known, it seems, that the inherited
stack, which comes part of a VSI bundle, is not exactly maintained by
VSI, and has got a end of life at the end of the year.

[[In france we say about such a situation "nous avons le pistolet sur la
tempe" (we have the gun on the temple). French people like westerns.]]

It seems we MUST go to VSI bundle, and in this bundle we MUST choose the
new TCPIP stack, and for Alpha users we have to do that between the 31
of december 2020 (and of inherited stack) and the 1 january 2021
(getting the new stack).

It is not at all a smooth transition. Very difficult to market that. And
in my opinion the contrary of the general way of doing things with VMS
(long term sustainability). Perhaps Stephen will teach me about the
brave new world users and I have to accept. Perhaps the users will make
more radical solutions: going out of VMS, being so completely integrated
in the brave new world.

(And thanks to all, information and discution).

Gérard Calliet

[gérard Calliet]

Le 06/04/2020 à 11:15, gérard Calliet a écrit :
>
> It seems that it is a bit chaotic regarding kits and patches contents,
> regarding things like Kew algorithms.

Here a more thecnical approach.

*First*, what I have installed:

$ product sho his *tcp*

------------------------------------ ----------- ----------- --- -----------
PRODUCT KIT TYPE OPERATION VAL DATE
------------------------------------ ----------- ----------- --- -----------

VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 31-MAR-2020
VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D Patch Install Val 31-MAR-2020
VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 31-MAR-2020
VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 31-MAR-2020
VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D Patch Install Val 30-MAR-2020
VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 13-MAR-2020
VSI I64VMS TCPIP V5.7-13ECO5F Full LP Install Val 12-MAR-2020

------------------------------------ ----------- ----------- --- -----------

7 items found

*Second*, the version I see:
debug( 6-APR-2020 10:42:46.94): Remote version: SSH-2.0-3.2.0 SSH
OpenVMS V5.5 VMS_sftp_version 3

*Third*, what kex algo I get:

debug( 6-APR-2020 10:54:46.99): Ssh2Transport/TRCOMMON.C:3631: local
kexinit:
kex algs =
diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

*Fourth*, ana/ima of my .exe:
Image name: "TCPIP$SSH_SSH2"
Global Symbol Table name: "TCPIP$SSH_SSH2"
Image file identification: "DHG14-SHA256"
Link identification: "Linker I02-31"
Link Date/Time: 8-NOV-2018 22:08:25.45

Image name: "TCPIP$SSH_SSHD2"
Global Symbol Table name: "TCPIP$SSH_SSHD2"
Image file identification: "DHG14-SHA256"
Link identification: "Linker I02-31"
Link Date/Time: 8-NOV-2018 22:08:26.23


Perhaps you could compare with what you have got.

Gérard Calliet

[Jim]

On Sunday, April 5, 2020 at 12:10:30 PM UTC-4, gérard Calliet wrote:
> Le 04/04/2020 à 14:40, Craig A. Berry a écrit :
> >
> > On 3/30/20 12:13 PM, gérard Calliet wrote:
> >> Le 25/03/2020 à 19:49, Craig A. Berry a écrit :
> >>> I see the following algorithms and ciphers listed:
> >>>
> >>> debug2: KEX algorithms:
> >>> curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
> >>>
> >> Hello,
> >>
> >> How do you get this output? I have the same patches,
> >> and I tried a $ ssh -d 2 localhost
> >> and I don't get the "debug2" lines.
> >>
> >> Where am I wrong?
> >
> > I did "ssh -vvv" from the shell of a non-VMS system.  Someone has posted
> > elsewhere in the thread that ssh/debug=3 might be the equivalent on VMS.
> Thanks.
> You are a lucky man, Craig, because you get all the new KEX algorithms,
> and not me.
>
> I confirmed that using >>ssh -vvv from windows, and I don't get them.
>
> (Perhaps I have another issue because from the CMD of windows I get also
> that:
> """Unable to negotiate with 10.0.10.70 port 22: no matching host key
> type found. Their offer: ssh-dss"""
>

OpenSSH deprecated default interaction with hosts having DSA (ssh-dss)
hostkeys a few years back. If this VMS systems is just for testing you
might just regenerate the hostkey pair using key type of RSA if DSA becomes
a problem. Also, many current systems that will converse with a host with a
DSA key will only do so if that key is exactly 1024 bits.

[gérard Calliet]

yes, done, and it resolves the problem of access from cmd windows, but
no change in the set of kex algorithms.

[Jim]

On Monday, April 6, 2020 at 10:20:21 AM UTC-4, gérard Calliet wrote:
> Le 06/04/2020 à 15:53, Jim a écrit :
> >
> > OpenSSH deprecated default interaction with hosts having DSA (ssh-dss)
> > hostkeys a few years back. If this VMS systems is just for testing you
> > might just regenerate the hostkey pair using key type of RSA if DSA becomes
> > a problem. Also, many current systems that will converse with a host with a
> > DSA key will only do so if that key is exactly 1024 bits.
> yes, done, and it resolves the problem of access from cmd windows, but
> no change in the set of kex algorithms.

The key exchange algorithms are compiled into the SSH client/server software
so what you're seeing is what you can use until you've upgraded to something
newer.

[Dave Froble]

On 4/6/2020 5:15 AM, gérard Calliet wrote:
> Le 05/04/2020 à 23:40, Craig A. Berry a écrit :
>>
>> On 4/5/20 2:46 PM, Stephen Hoffman wrote:
>>> On 2020-04-05 19:32:48 +0000, Craig A. Berry said:
>>>
>>>> On 4/5/20 12:08 PM, Stephen Hoffman wrote:
>>
>>>>> You're apparently still on an OpenVMS version from the vendor
>>>>> that's exiting the platform, and with all new patches ending this
>>>>> year. An end to new patches which should be a surprise to exactly
>>>>> nobody.
>>>>
>>>> No, he confirmed up-thread that he has the VSI version of TCP/IP
>>>> Services...
>>>
>>> My understanding of all this...
>>>
>>> That's (still) the HPE TCP/IP Services stack.
>>
>> Now I get what you mean, but most of VMS is still the DEC/Compaq/HP/HPE
>> operating system, yet we refer to the VSI-branded versions as VSI
>> OpenVMS, not HPE OpenVMS, so I find it confusing to refer to the
>> VSI-branded TCP/IP Services as "from the vendor that's exiting the
>> platform." Everything that hasn't been written or rewritten by VSI is
>> from the old vendor.
>>
>>> VSI reportedly doesn't have source code to that stack.
>>>
>>> The TCP/IP Services stack will seemingly be out of support by 2021,
>>> unless VSI has some sort of extended-support deal with HPE.
>>
>>> This being the entirety of why we are and will be migrating to the
>>> VSI IP stack.

This is your only rational choice. Don't count on HP for anything.
There is nobody home. Nobody to provide anything, at least that you can
count on.

>> Oh. I thought it was because it sucked, not because VSI didn't even
>> have the necessary access to maintain it. I assumed the old stack would
>> be maintained until the new one was ready for prime time just like all
>> the other old stuff. One more thing about the transition that was even
>> more precarious than I realized.
>>
> It's all about general transition here in France. And being able to help
> customers to find interests (immediate and more long term). And helping
> them building sustainable transition strategies.
>
> I am testing installations (Itanium, Alpha) from scratch with all I
> could get from VSI. And testing IF it could be of interest for customers
> to begin a transition using the inherited TCPIP stack, before going at
> their pace to the new stack.
>
> It seems that it is a bit chaotic regarding kits and patches contents,
> regarding things like Kew algorithms.
>
> I had to discover something best known, it seems, that the inherited
> stack, which comes part of a VSI bundle, is not exactly maintained by
> VSI, and has got a end of life at the end of the year.
>
> [[In france we say about such a situation "nous avons le pistolet sur la
> tempe" (we have the gun on the temple). French people like westerns.]]

You understand it real well ....

> It seems we MUST go to VSI bundle, and in this bundle we MUST choose the
> new TCPIP stack, and for Alpha users we have to do that between the 31
> of december 2020 (and of inherited stack) and the 1 january 2021
> (getting the new stack).

That is my problem. I want to test and learn the new TCP/IP. I don't
have, nor do I want, one of those itanic thingies. Not sure I'm going
to have much choice.

> It is not at all a smooth transition. Very difficult to market that. And
> in my opinion the contrary of the general way of doing things with VMS
> (long term sustainability). Perhaps Stephen will teach me about the
> brave new world users and I have to accept. Perhaps the users will make
> more radical solutions: going out of VMS, being so completely integrated
> in the brave new world.
>
> (And thanks to all, information and discution).
>
> Gérard Calliet
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Craig A. Berry]

$ product show hist *tcp*

------------------------------------ ----------- ----------- --- -----------
PRODUCT KIT TYPE OPERATION VAL DATE
------------------------------------ ----------- ----------- --- -----------

VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 09-MAR-2018
VSI I64VMS TCPIP_NFS_PAT V5.7-ECO5C Patch Install Val 21-DEC-2017
VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D Patch Install Val 21-DEC-2017
VSI I64VMS TCPIP V5.7-13ECO5F Full LP Install Val 21-DEC-2017
VSI I64VMS TCPIP V5.7-13ECO5 Full LP Remove - 21-DEC-2017
VSI I64VMS TCPIP V5.7-13ECO5 Full LP Reg Product (U) 21-DEC-2017

------------------------------------ ----------- ----------- --- -----------

6 items found

> *Second*, the version I see:
> debug( 6-APR-2020 10:42:46.94): Remote version: SSH-2.0-3.2.0 SSH
> OpenVMS V5.5 VMS_sftp_version 3

same here

> *Third*, what kex algo I get:
>
> debug( 6-APR-2020 10:54:46.99): Ssh2Transport/TRCOMMON.C:3631: local
> kexinit:
> kex algs =
> diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

KEX algorithms:
curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c

> *Fourth*, ana/ima of my .exe:
>     Image name:                                 "TCPIP$SSH_SSH2"
>     Global Symbol Table name:                   "TCPIP$SSH_SSH2"
>     Image file identification:                  "DHG14-SHA256"
>     Link identification:                        "Linker I02-31"
>     Link Date/Time:                              8-NOV-2018 22:08:25.45
>
>     Image name:                                 "TCPIP$SSH_SSHD2"
>     Global Symbol Table name:                   "TCPIP$SSH_SSHD2"
>     Image file identification:                  "DHG14-SHA256"
>     Link identification:                        "Linker I02-31"
>     Link Date/Time:                              8-NOV-2018 22:08:26.23
>
>
> Perhaps you could compare with what you have got.

Image name: "TCPIP$SSH_SSH2"
Global Symbol Table name: "TCPIP$SSH_SSH2"

Image file identification: "V5.7-ECO5O"
Link identification: "Linker I02-31"
Link Date/Time: 9-OCT-2017 11:33:11.44

Image name: "TCPIP$SSH_SSHD2"
Global Symbol Table name: "TCPIP$SSH_SSHD2"

Image file identification: "V5.7-ECO5O"
Link identification: "Linker I02-31"
Link Date/Time: 9-OCT-2017 11:33:12.20

[Craig A. Berry]

On 4/7/20 5:47 PM, Craig A. Berry wrote:
> On 4/6/20 7:42 AM, gérard Calliet wrote:


>
>> *Third*, what kex algo I get:
>>
>> debug( 6-APR-2020 10:54:46.99): Ssh2Transport/TRCOMMON.C:3631: local
>> kexinit:
>> kex algs =
>> diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>
>
> KEX algorithms:
> curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
>

Hmm. Those may be the client's capabilities, not the server's. There
is another line further down that looks like this:

KEX algorithms: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

but nothing indicates whether it's server or client that has these
capabilities.

[gérard Calliet]

You got it. I was running for nothing. I had information yesterday which
confirms there will not anything more stack kex algo with (hpe) tcpip
than the 3 you mentionned. The others seen are from the client side.

It's a very bad situation. The solution for users is downgrading the
users or buying the process software solution, for users who cannot go
today to itanium new stack (or who cannot do anything in alpha, waiting
for the new stack). How can I market that, saying VMS is ""persistent,
for long time sustainable"", I don't know.

Gérard Calliet

[Stephen Hoffman]

On 2020-04-06 09:15:56 +0000, g 駻ard Calliet said:

> It seems we MUST go to VSI bundle, and in this bundle we MUST choose
> the new TCPIP stack, and for Alpha users we have to do that between the
> 31 of december 2020 (and of inherited stack) and the 1 january 2021
> (getting the new stack).

For folks that wonder, contact VSI support around the TCP/IP Services
patches and plans. That's what folks pay support for.

The ECO-number kits are seemingly cumulative, and ECO5 looks to be the
end of the ECO line for the HPE-lineage IP stack, but the
ECO-number-letter kits atop those ECO-number kits do not appear to be
cumulative.

Little of this is documented, whether from HPE or from VSI. I'd expect
VSI wants rid of TCP/IP Services too, and just as soon as they can roll
out VSI IP (VSI TCPIP) and get that accepted and installed.

All of us will want to be migrating to the VSI IP stack and spending
the next hunk of our available schedule time and test server access
time preparing for and testing our apps for that transition.

Here are the KEX algorithms available from a different and
not-exactly-current operating system client and its integrated ssh
support:
curve25519-sha256,
curve255...@libssh.org,
ecdh-sha2-nistp256,
ecdh-sha2-nistp384,
ecdh-sha2-nistp521,
diffie-hellman-group-exchange-sha256,
diffie-hellman-group16-sha512,
diffie-hellman-group18-sha512,
diffie-hellman-group14-sha256,
diffie-hellman-group14-sha1,
ext-info-c

These are from the "debug2: local client KEXINIT proposal" section of
the local client debug, with the server capabilities listed in the
subsequent "debug2: peer server KEXINIT proposal" section.

Note the priority order shown here, too. The
diffie-hellman-group14-sha1 algorithm is near the end of the KEX list
here, and at the top of the OpenVMS list.

> It is not at all a smooth transition. Very difficult to market that.
> And in my opinion the contrary of the general way of doing things with
> VMS (long term sustainability).

We aren't in the old long-term-support world. Not any more. Not at
prices that most of us are willing to pay, and with what the vendors
can afford to provide. And not with security vulnerabilities being
identified and exploited ever more quickly.

As for OpenVMS marketing, there have been so, so, so very many missed
opportunities. There will be more.

As for VSI, getting a viable x86-64 port out the door soonest is the
make-or-break goal for VSI, as a business.

> Perhaps Stephen will teach me about the brave new world users and I
> have to accept.

There's a pandemic clobbering schedules and plans everywhere, and
sickening and killing quite a few folks. That's one problem we're
contending with. With a recession- or depression-scale unemployment and
business downturn, too. Few of us being idle at home, BTW.

And most of us are now increasingly familiar with cases where we won't
have access to folks available on-site for OpenVMS software- and for
hardware-related maintenance, too.

And we're headed onto a five to maybe seven year hardware replacement
cycle, with ~five years between long-term software upgrades.

And we're also in an era when we have to accept and roll out some
patches very quickly and particularly around important and exposed
servers, and where there will be the occasional breaking changes
arising in software upgrades.

> Perhaps the users will make more radical solutions: going out of VMS,
> being so completely integrated in the brave new world.

I'm aware of various sites porting off of OpenVMS, yes. The rates of
arriving requests and arriving discussions involving ports off of
OpenVMS have slowed, but have not stopped.



On 2020-04-08 07:14:20 +0000, g 駻ard Calliet said:

> ...I had information yesterday which confirms there will not anything

> more stack kex algo with (hpe) tcpip than the 3 you mentionned. The
> others seen are from the client side.
>
> It's a very bad situation. The solution for users is downgrading the
> users or buying the process software solution, for users who cannot go
> today to itanium new stack (or who cannot do anything in alpha, waiting
> for the new stack). How can I market that, saying VMS is ""persistent,
> for long time sustainable"", I don't know.

The vendor y'all have been using here is exiting the OpenVMS market and
has been telling everybody that for ~five years, and any of this is a
surprise?

I've been pointing at ssh, TLS, and related security issues for a ~dozen years.

OpenVMS has been at the trailing edge for a while, in terms of its
system and network security implementation. KEX and cipher and other
changes have been happening when they have to, and seldom any earlier.
We didn't get the "new" KEX until ssh all over was failing to
interoperate with OpenVMS.

VSI is clearly working to change that approach and is better tracking
security updates with OpenSSL ports, but there's vastly more work
waiting ahead. BTW: VSI SSL111 V0101-1EA-1/V1.1-1EA was just
announced. But I digress. And the patches and updates are arriving
faster than VSI can port and ship changes, such as with the Apache
port. Which means they pick and choose. And means more work for VSI,
and more work for the rest of us. (This is also where better frameworks
are interesting as a developer, as none of us would prefer to have to
shift our TLS code to new APIs, as the OpenSSL APIs are changed. So far
those API changes have been minor, at least around here. But I'd rather
not have to revisit that code at all.)

And this ride isn't ever going to slow down. And if y'all think the
pandemic has been a wake-up call, wait until more of us start getting
clobbered by the changes to our climate.

[gérard Calliet]

Le 08/04/2020 à 23:34, Stephen Hoffman a écrit :

> On 2020-04-06 09:15:56 +0000, g érard Calliet said:
>
>> It seems we MUST go to VSI bundle, and in this bundle we MUST choose
>> the new TCPIP stack, and for Alpha users we have to do that between
>> the 31 of december 2020 (and of inherited stack) and the 1 january
>> 2021 (getting the new stack).
>
> For folks that wonder, contact VSI support around the TCP/IP Services
> patches and plans. That's what folks pay support for.
>
> The ECO-number kits are seemingly cumulative, and ECO5 looks to be the
> end of the ECO line for the HPE-lineage IP stack, but the
> ECO-number-letter kits atop those ECO-number kits do not appear to be
> cumulative.
>
> Little of this is documented, whether from HPE or from VSI. I'd expect
> VSI wants rid of TCP/IP Services too, and just as soon as they can roll
> out VSI IP (VSI TCPIP) and get that accepted and installed.

Indeed.

>
> All of us will want to be migrating to the VSI IP stack and spending the
> next hunk of our available schedule time and test server access time
> preparing for and testing our apps for that transition.

When/If we get time. When/if customers get time.

>
> Here are the KEX algorithms available from a different and
> not-exactly-current operating system client and its integrated ssh support:
> curve25519-sha256,
> curve255...@libssh.org,
> ecdh-sha2-nistp256,
> ecdh-sha2-nistp384,
> ecdh-sha2-nistp521,
> diffie-hellman-group-exchange-sha256,
> diffie-hellman-group16-sha512,
> diffie-hellman-group18-sha512,
> diffie-hellman-group14-sha256,
> diffie-hellman-group14-sha1,
> ext-info-c
>
> These are from the "debug2: local client KEXINIT proposal" section of
> the local client debug, with the server capabilities listed in the
> subsequent "debug2: peer server KEXINIT proposal" section.
>
> Note the priority order shown here, too. The diffie-hellman-group14-sha1
> algorithm is near the end of the KEX list here, and at the top of the
> OpenVMS list.

Right.

>
>> It is not at all a smooth transition. Very difficult to market that.
>> And in my opinion the contrary of the general way of doing things with
>> VMS (long term sustainability).
>
> We aren't in the old long-term-support world. Not any more. Not at
> prices that most of us are willing to pay, and with what the vendors can
> afford to provide. And not with security vulnerabilities being
> identified and exploited ever more quickly.

But - perhaps you don't agree on that - VMS was good for that and could
be choosed fot that.

>
> As for OpenVMS marketing, there have been so, so, so very many missed
> opportunities. There will be more.
>
> As for VSI, getting a viable x86-64 port out the door soonest is the
> make-or-break goal for VSI, as a business.

From the beginning it's The Big Mistake of VSI. It was sure there will
be a gap between promising x86 and giving it, and large probabilities
the gap would be larger than expected.

So the good idea would have to be very very good for the old customers
base, permitting them to survive with ease during the gap. Proving VSI
was exceptionally trustable. And by these ways getting back the more old
users as customers. And so being able to convince the customers to take
time and money to organize a port to x86.

On the contrary we are losing every month desperate users for whom the
gap is too long, who don't want to pay just to change the supplier. And
with the no-hope old tcpip, having to spare time to get standard security.

The survivors will be a little bit tired, and it's very difficult to
think they'll enjoy doing another port for x86. Everybody knows we lost
customer at each hardware port, in much easier period.

Compared to people here I know I am just a very young :) newbie.

But I can remember discussions of my mentors twenty or thirty years ago,
when they were speaking about the way Digital was going to fail. Very
good technical projects, but making the game just an hypothetic dream,
because of a sort of suicidal business strategy, based on a too great
trust on the (real) quality of the products.

I'm not surprised of the facts because I read you for years :)

I don't understand the way VSI don't address that, or the way they
address that.

I'm sure it would be a lot better for everyone to have 6 more months
waiting for x86, but getting more easily now security for existant
environments, or smoother transition of the support between HPE to VSI.

Because all are able to differ for 6 months a complicate migration port
to x86, IF they can go on living on VMS. But to be able to port from VMS
(Itanium or Alpha) to x86 VMS it is necessary to BE on VMS.

>
> I've been pointing at ssh, TLS, and related security issues for a ~dozen
> years.
>
> OpenVMS has been at the trailing edge for a while, in terms of its
> system and network security implementation. KEX and cipher and other
> changes have been happening when they have to, and seldom any earlier.
> We didn't get the "new" KEX until ssh all over was failing to
> interoperate with OpenVMS.
>
> VSI is clearly working to change that approach and is better tracking
> security updates with OpenSSL ports, but there's vastly more work
> waiting ahead.  BTW: VSI SSL111 V0101-1EA-1/V1.1-1EA was just announced.
> But I digress. And the patches and updates are arriving faster than VSI
> can port and ship changes, such as with the Apache port. Which means
> they pick and choose.  And means more work for VSI, and more work for
> the rest of us. (This is also where better frameworks are interesting as
> a developer, as none of us would prefer to have to shift our TLS code to
> new APIs, as the OpenSSL APIs are changed. So far those API changes have
> been minor, at least around here. But I'd rather not have to revisit
> that code at all.)
>
> And this ride isn't ever going to slow down. And if y'all think the
> pandemic has been a wake-up call, wait until more of us start getting
> clobbered by the changes to our climate.

Right.
I didn't kow you were not a climatosceptic :)
>
>
Impossible now to prophetize for the after Covid. I hope all the actors
will be more concerned about usefullness. And because VMS is very
usefull I think we'll get a lot of good work to do :)
>
>
>
>
>
>

[Craig A. Berry]

On 4/12/20 11:57 AM, gérard Calliet wrote:

> So the good idea would have to be very very good for the old customers
> base, permitting them to survive with ease during the gap.

They have actually done a lot of this, and doing so is probably one of
the major reasons the x86_64 port has been delayed. They came out with
Alpha support after saying they wouldn't. They provided C99 support in
the CRTL. They have updated Java and Apache and a bunch of other
layered products and open source packages and added new device support.
They actually produce bug fix ECOs when the bugs get fixed, rather than
requiring each customer that encounters the bug to open a support ticket
and download custom images as HPE has been doing. So there's really no
argument that existing customers are in worse shape with VSI than with HPE.

> On the contrary we are losing every month desperate users for whom the
> gap is too long, who don't want to pay just to change the supplier. And
> with the no-hope old tcpip, having to spare time to get standard security.

I agree the transition to a new IP stack poses a number of problems. In
your particular case of inadequate ciphers in the old stack, from what
others have said in this thread, that's not within VSI's power to fix.
So install VSI TCPIP 10.6 on a test system now and start getting ready
for 10.7 later this year.

[Dave Froble]

On 4/12/2020 12:57 PM, gérard Calliet wrote:
> Le 08/04/2020 à 23:34, Stephen Hoffman a écrit :
>> On 2020-04-06 09:15:56 +0000, g érard Calliet said:
>>
>>> It seems we MUST go to VSI bundle, and in this bundle we MUST choose
>>> the new TCPIP stack, and for Alpha users we have to do that between
>>> the 31 of december 2020 (and of inherited stack) and the 1 january
>>> 2021 (getting the new stack).
>>
>> For folks that wonder, contact VSI support around the TCP/IP Services
>> patches and plans. That's what folks pay support for.
>>
>> The ECO-number kits are seemingly cumulative, and ECO5 looks to be the
>> end of the ECO line for the HPE-lineage IP stack, but the
>> ECO-number-letter kits atop those ECO-number kits do not appear to be
>> cumulative.
>>
>> Little of this is documented, whether from HPE or from VSI. I'd expect
>> VSI wants rid of TCP/IP Services too, and just as soon as they can
>> roll out VSI IP (VSI TCPIP) and get that accepted and installed.
> Indeed.
>>
>> All of us will want to be migrating to the VSI IP stack and spending
>> the next hunk of our available schedule time and test server access
>> time preparing for and testing our apps for that transition.
> When/If we get time. When/if customers get time.

This makes no sense to me. What other option might there be that would
be quicker? Nothing that I can imagine. Perhaps it's not a perfect
solution, but what else is?

In my opinion VSI is doing a rather decent job. They can not please
everyone immediately. Just will not happen. They are doing what they
promised, and to me that is "reliable" and "trustable".

> On the contrary we are losing every month desperate users for whom the
> gap is too long,

Please explain this. I cannot believe that any customer still on VMS is
going to decide to do a port elsewhere, and I'm real sure anything like
that would take much longer then waiting on VSI.

> who don't want to pay just to change the supplier.

The future for VMS users is VSI. If there are those who do not want to
support VSI, then there is no future on VMS for them.

> And
> with the no-hope old tcpip, having to spare time to get standard security.

It is what it is. VSI has devoted the time, as you've asked above, to
provide a better TCP/IP product. It's running on itanic. Looks like I
have to bring in an (gag, hawk, spit) itanic to learn the new product.
Sometimes we all have to suffer a bit.

> The survivors will be a little bit tired, and it's very difficult to
> think they'll enjoy doing another port for x86. Everybody knows we lost
> customer at each hardware port, in much easier period.

Most still using VMS will not have any good options for a port off VMS.
Those users are mostly already long gone.

> Compared to people here I know I am just a very young :) newbie.
>
> But I can remember discussions of my mentors twenty or thirty years ago,
> when they were speaking about the way Digital was going to fail. Very
> good technical projects, but making the game just an hypothetic dream,
> because of a sort of suicidal business strategy, based on a too great
> trust on the (real) quality of the products.

I do not subscribe to that concept. While mistakes were made, what
killed DEC was the inability to move from a business model where HW was
very expensive, and HW income supported other activity. When the price
of HW dropped, DEC had way too many employees to support.

What would you suggest?

> I'm sure it would be a lot better for everyone to have 6 more months
> waiting for x86, but getting more easily now security for existant
> environments, or smoother transition of the support between HPE to VSI.

VSI is working on the new TCP/IP.

[gérard Calliet]

Le 13/04/2020 à 03:15, Dave Froble a écrit :

I'll take a big challenge here, because I do know VMS community are in
majority an for-hyper-legitimation community. The Mother World Company
is always right. Proprietary rights are holy rights. And everything
happening cannot be changed, because It's the Real (muslims say it's
"mektoub" (written)).

I remember the way in 2013 I was said that nothing at all could be done,
because of The Real.

My opinion is that The Real is made by actors, and the actors are not
only on a Holy center about which the only way of intervene is to pray.

But I think we have now a sort of truce, where it is possible to think
about things.

My opinion is The Mother World Company is no more a world company, the
world incoutered a lot of changes, and the VMS renew project being very
very brittle, it deserves more than prayers or "business as usual" or "I
was always thinking that..." quick sentences.

First: the case is not about a peculiar customer. It is about thinking
how a majority of customers could be motivated to go on with VMS, in a
time a lot of them are planning to go out or just waiting for the death
of their VMS specific applications.

I do agree with Craig that VSI did a lot of things. And that they cannot
do everything.

The point is the way they are "business-packaging" their offer is a
nightmare. The way they are not doing anything to leverage VMS renew on
an acting and a renewing community is suicidal.

And now you know you have a lot of motivations to desagree, the details:

>>> All of us will want to be migrating to the VSI IP stack and spending
>>> the next hunk of our available schedule time and test server access
>>> time preparing for and testing our apps for that transition.
>> When/If we get time. When/if customers get time.
>
> This makes no sense to me.  What other option might there be that would
> be quicker?  Nothing that I can imagine.  Perhaps it's not a perfect
> solution, but what else is?

Why VSI don't maintain 2 or 3 years more the inherited stack? When I buy
an OS license I buy it, and I could hope getting what i bought
maintained. [[Same thing more generaly about the global transfert of
support from HPE to VSI: now it's VSI you pay for that support... which
is not a real one, "please" just go today to VSI. Not so fairfull.]]

Don't say it is too technically complicated, or you have to say VSI is
totally unable to support the product. And that the inherited stack is
so bad that it is impossible to add algorithms they are able to
implement for the new stack.

>
> In my opinion VSI is doing a rather decent job.  They can not please
> everyone immediately.  Just will not happen.  They are doing what they
> promised, and to me that is "reliable" and "trustable".

I don't think getting an EAK 0 in 2020 was the promise. Yes they do
everything the can and it is
hard job. But my opinion is that this situation was totally predictable,
and that
the business plan had to play with that.

>

>> On the contrary we are losing every month desperate users for whom the
>> gap is too long,
>
> Please explain this.  I cannot believe that any customer still on VMS is
> going to decide to do a port elsewhere, and I'm real sure anything like
> that would take much longer then waiting on VSI.

In perhaps all the cases, the customers are wrong to imagine it could be
better to port out of VMS.

But we don't speak about rational decisions. We speak about management
decisions made by people not knowing anything about VMS, about lack of
VMS professionals, about too specific system in
an heaven of "everything is virtual".

You go and speak to these people, and you say: "please pay for a no-more
functionnality bundle", "no more immediate security", and in about 2 or
3 years you will be able to port that on x86. How do you feel about the
probable answer?

>
>> who don't want to pay just to change the supplier.
>
> The future for VMS users is VSI.  If there are those who do not want to
> support VSI, then there is no future on VMS for them.
>

Right. But the question is not yes or not. Yes we have to. But the
question is "how" and "when". The users of VMS have a very specific
pace, because of very specific contexts (which often explains why there
are still on VMS). Play with them like microsoft , they'll go out.

>> And
>> with the no-hope old tcpip, having to spare time to get standard
>> security.
>
> It is what it is.  VSI has devoted the time, as you've asked above, to
> provide a better TCP/IP product.  It's running on itanic.  Looks like I
> have to bring in an (gag, hawk, spit) itanic to learn the new product.
> Sometimes we all have to suffer a bit.

Here we are. Mektoub.

By the way here is another controversy about Itanium with you. Another
day perhaps :)

> I do not subscribe to that concept.  While mistakes were made, what
> killed DEC was the inability to move from a business model where HW was
> very expensive, and HW income supported other activity.  When the price
> of HW dropped, DEC had way too many employees to support.

I didn't think about that. I don't think however there are been only one
cause. Here in france we could see the big difference between the real
care for customers with Big Blue (we hated them), and also anyone can
say that the internet and Open Source models have been the big weeners
last decades, 2 domains where VMS company and comunity have been very late.

>>>>
>>>> It's a very bad situation. The solution for users is downgrading the
>>>> users or buying the process software solution, for users who cannot
>>>> go today to itanium new stack (or who cannot do anything in alpha,
>>>> waiting for the new stack). How can I market that, saying VMS is
>>>> ""persistent, for long time sustainable"", I don't know.
>>>
>>> The vendor y'all have been using here is exiting the OpenVMS market
>>> and has been telling everybody that for ~five years, and any of this
>>> is a surprise?
>> I'm not surprised of the facts because I read you for years :)
>>
>> I don't understand the way VSI don't address that, or the way they
>> address that.
>
> What would you suggest?

Giving a real support for the inherited stack (and in general).

[Richard Whalen]

From what I have heard/understand:
There are parts of the existing/old TCP/IP Stack that could be licensed to VSI.
There are parts of the existing/old TCP/IP Stack that could not be licensed to VSI. I've heard that this list includes DHCP and SSH (I don't know if there is more).

So, the problem is not a technical one, but a legal one.

[Dave Froble]

I'm in no position to know anything, but, I've read that VSI may not
have the sources for the HP TCP/IP product. If that is true, then how
could you expect them to maintain the product? That just is not possible.

[Kerry Main]

It was functional for the times, but the OpenVMS TCPIP stack needed a change in direction.

Especially when, other than security and/or priority bug fixes, HP/HPE has not added any real new functionality to the TCPIP stack in the last 10-15 years.

Especially when all of the old TCPIP stack contains 3rd party licensing stuff that even HPE was not willing to address.

Asking VSI to now do this, when even HP/HPE was not willing is just not realistic.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[gérard Calliet]

Ok. And so buy the process software solution when you are on Alpha, or
buy today the VSI package, and port tomorow to the VSI new stack if you
are on Itanium. Another way of being un-realistic.
If we were in a such problematic situation it was perhaps possible that
VSI should have communicate a little bit sooner and a little bit more
loudly.

[gérard Calliet]

Thanks. Why can we just "have heard" about all that? And so, which other
parts we buy in the VSI bundle (OS, LPS) is not licensed to VSI?

[Craig A. Berry]

C++. Or maybe it is licensed but royalties to Intel are brutal. Dunno.

I knew the SSH implementation came from a different company, but I did
not know the license to develop it further never made its way to VSI
until this thread. Yes, it is rather alarming.

[Arne Vajhøj]

Company A acquiring a commercial license for product XYZ from company B
to be used in product suite SuperDuper is quite common and relative
straight forward - A pays B some money and get the right to use XYZ for
N years or forever - SuperDuper then ships with XYZ. Done.

But it is notoriously complicated if A many years later wants to hand
over SuperDuper to a third party C (does not matter if C is a
commercial entity or an open source project). Likely the original
commercial license acquisition does not allow that. If company
B is still selling XYZ then the problem can be solved by C paying
for XYZ again. But sometimes B is not selling XYZ any longer.
And it can be even worse: company B may have been merged into
company D and nobody in D even know what XYZ is and have absolutely
no intention of selling a license. Or B's assets has
been split among companies E and F and they don't even know
which of them own the rights to XYZ.

Arne

[gérard Calliet]

Thanks a lot Arne. And now I know why Open Source has been The salvation
:) (just for fun, I know it is not the solution for VMS)

[Simon Clubley]

I wonder what happens if someone comes along with a security vulnerability
in one of those components and then asks VSI for a patch ?

Are VSI allowed to fix security issues but not add any further features
or do they really not have the source code for some TCP/IP Services
components at all ?

The thing that doesn't make sense here is, if VSI really don't have
the source code to those components, then how did they build binaries
for those components on VSI VMS in the first place ?

The only way I could see around that is if HPE simply give VSI the
binaries for those components without also giving VSI the source code
or if VSI supplied their own replacements for those components.

That's why I am wondering if this is just a licence issue instead of
VSI simply not having the source code for those components at all.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Stephen Hoffman]

On 2020-04-12 16:57:19 +0000, g érard Calliet said:

> Le 08/04/2020 à 23:34, Stephen Hoffman a écrit :
>>
>> We aren't in the old long-term-support world. Not any more. Not at
>> prices that most of us are willing to pay, and with what the vendors
>> can afford to provide. And not with security vulnerabilities being
>> identified and exploited ever more quickly.
> But - perhaps you don't agree on that - VMS was good for that and could
> be choosed fot that.

Tomorrow is not yesterday.

VAX/VMS and MicroVMS and OpenVMS were all good choices in years past.
Variously the best choice.

OpenVMS can still be a good choice for existing app deployments, and
for various incremental new work where OpenVMS is already present.

But VSI and third-party vendors all have a whole pile of work before
OpenVMS seems a good choice for wholly new apps and the associated
new-app deployments, and for new-to-OpenVMS developers.

Looking backward is certainly interesting. And can be illuminating. And
confounding†. But environments that once worked for then-new apps and
products and businesses very seldom repeat‡.

But it's revenues from today and particularly tomorrow that keeps any
commercial vendor afloat. Which means subscription services and/or
support sales and/or software update sales, for software vendors.

>> As for OpenVMS marketing, there have been so, so, so very many missed
>> opportunities. There will be more.
>>
>> As for VSI, getting a viable x86-64 port out the door soonest is the
>> make-or-break goal for VSI, as a business.
> From the beginning it's The Big Mistake of VSI. It was sure there will
> be a gap between promising x86 and giving it, and large probabilities
> the gap would be larger than expected.

The folks at VSI do appear to have some slight room for a few
improvements around customer communications, staffing, scheduling,
budgets, and the rest of the usual pile of issues and trade-offs that
inevitably arise within any startup, yes.

> So the good idea would have to be very very good for the old customers base,...

VSI TCPIP / VSI IP was discussed at the boot camp. Doesn't seem to
have had much posted here, nor communications to existing VSI customers
about the related plans, though.

There's been comparatively little IP-related integration in OpenVMS
work after OpenVMS V6.2, and the issues have been drifting to the
forefront for a while now.

VSI TCPIP / VSI IP hauls what's available forward quite a ways. Or not
far enough. That depending on who you chat with.

Per discussions at a VSI event (you were in attendance at it, too) VSI
had the choice of retrofitting into the old stack and replacing parts
of the old, or writing a wholly new stack and incrementally replacing
parts of the stack, or acquiring existing and newer and then using it
as the replacement. None of these are great choices. All would cause
disruption, too.

And as for the too-fast-for-our-preferences around the arrivals of
software patches, exploit mitigations, updates, and upgrades, well,
that's the world we're in now. It's only going to get faster. I've
previously mentioned suggestions around easing parts of that for app
developers and for those administering OpenVMS servers, but isolating
and abstracting the changes itself will absolutely be disruptive. And
there are some changes that simply cannot be mitigated without app
source code changes. Either the fix or the security update is added and
the change made, or the security is not upgraded. You can't fit a 16-
or 32-byte hash into an 8-byte buffer in your app source code. (This is
one of the places where OO really helps, but that too will be
disruptive, and that too will require app source code changes.)

If you can't get to VSI TCPIP / VSI IP later this year and migrate off
of TCP/IP Services expeditiously, well, you'll run without new-patch
support and with the obvious and associated incentive and additional
motivation to complete the migration to the VSI TCPIP / VSI IP stack.

And if you can't move quickly with patches and upgrades and certainly
some sites cannot, then some introspection into your processes and
hardware and expectations seems warranted, and with consideration
around how fast you can (or cannot) deploy critical patches, when (not
if) that becomes required. What are you going to do about these issues
when they arise. When. Not if.

As for contending with ssh connectivity as the rest of the internet
upgrades ssh security, that's previously been discussed. Connection
downgrades, third-party ssh client and/or server, or an intermediate
gateway host, etc., pending the VSI TCPIP / VSI IP migration.

On 2020-04-13 10:39:51 +0000, g érard Calliet said:

> I'll take a big challenge here, because I do know VMS community are in
> majority an for-hyper-legitimation community. The Mother World Company
> is always right. Proprietary rights are holy rights. And everything
> happening cannot be changed, because It's the Real (muslims say it's
> "mektoub" (written)).
>
> I remember the way in 2013 I was said that nothing at all could be
> done, because of The Real.
>
> My opinion is that The Real is made by actors, and the actors are not
> only on a Holy center about which the only way of intervene is to pray.
>
> But I think we have now a sort of truce, where it is possible to think
> about things.
>
> My opinion is The Mother World Company is no more a world company, the
> world incoutered a lot of changes, and the VMS renew project being very
> very brittle, it deserves more than prayers or "business as usual" or
> "I was always thinking that..." quick sentences.

My erudition buffer has seemingly underflowed.


† ~Twenty years on, I'm still boggled by the feedback from the 1999
Providence DECUS audience, around the DEC offer about open-sourcing
OpenVMS. That audience was seriously opposed to open-sourcing of
OpenVMS itself.

‡ If you're interested in seeing how some other folks are building and
maintaining reliable and secure systems now, here's some (free)
reading: https://landing.google.com/sre/books/

[Phillip Helbig (undress to reply)]

In article <r778f0$efr$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> ~Twenty years on, I'm still boggled by the feedback from the 1999
> Providence DECUS audience, around the DEC offer about open-sourcing
> OpenVMS. That audience was seriously opposed to open-sourcing of
> OpenVMS itself.

My guess is that today most VMS users would be opposed to open-sourcing
it.

[Scott Dorsey]

VMS was sort of the best of both worlds... the source was available if you
wanted it, but it was locked down and charged for so you couldn't just
make random system changes and release them into the world.

I think it's important for source to be available to users. I think it's
bad to hand out source to everyone in the world who might want to look at
it and modify it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

My guess is that:
* a lot of the old VMS users would oppose
* a lot of the future new VMS users would agree

I know that the impact of open sourcing VMS today would be
relative small short term - the VMS communities open source
code writing willingness/capability is extremely small.

Arne

[Arne Vajhøj]

Is that really a problem?

Sure everyone could modify it, but nobody would be forced to
take the modifications!

Arne

[Phillip Helbig (undress to reply)]

In article <r7832q$1sk3$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

<ar...@vajhoej.dk> writes:

> >> ~Twenty years on, I'm still boggled by the feedback from the 1999
> >> Providence DECUS audience, around the DEC offer about open-sourcing
> >> OpenVMS. That audience was seriously opposed to open-sourcing of
> >> OpenVMS itself.
> >
> > My guess is that today most VMS users would be opposed to open-sourcing
> > it.
>

> My guess is that:
> * a lot of the old VMS users would oppose
> * a lot of the future new VMS users would agree

But there are also probably many more old VMS users than new VMS users.

And would the new VMS users have any idea how to write BLISS code? :-)

> I know that the impact of open sourcing VMS today would be
> relative small short term - the VMS communities open source
> code writing willingness/capability is extremely small.

And I doubt that that would change if it were open source, certainly not
because of being open source.

[gérard Calliet]

Le 15/04/2020 à 17:15, Stephen Hoffman a écrit :
> Tomorrow is not yesterday.
Totally right.

If I unsderstand your point,
because tomorrow is not yesterday,
because VMS is of yesterday,
and not will be just immediatly tomorow,
the good choice is to abandon the users of yesterday,
to get profit today

Hum, don't you see there is a sort of flaw in your rationale.

In my humble opinion,
if VMS is of yesterday (right)
and not will be immediatly tomorow (right)
help today those are on yesterday to go to tomorow.

Gérard Calliet

[gérard Calliet]

I didn't propose anything like Open Sourcing VMS.
Total Open Source is good.
VMS, proprietary is good.

Twenty years you had to choose between Open Source and VMS.
Now you can and you have to use the best of the both.

The best of VMS (proprietary): long time cycles of evolution, stability,
easy maintenance, backward compatibility. My point here: do go on with
the specific qualities of VMS and don't play with us as microsoft.

The best of Open Source: up to date with internet, dynamic communities,
"agile" applications. My point here: if you want to play with Open
Source respect the rules: publishing the sources, communicating with the
community.

Gérard Calliet

[gérard Calliet]

My question.

[Stephen Hoffman]

On 2020-04-16 21:35:44 +0000, g érard Calliet said:

> Le 15/04/2020 à 17:15, Stephen Hoffman a écrit :
>> Tomorrow is not yesterday.
> Totally right.
>
> If I unsderstand your point, because tomorrow is not yesterday, because
> VMS is of yesterday, and not will be just immediatly tomorow, the good
> choice is to abandon the users of yesterday,
> to get profit today

Existing users that aren't upgrading (and that aren't staying on
support) aren't profitable.

They might eventually upgrade (which would be good for VSI), or they
might eventually migrate elsewhere (which is common).

Those users that do upgrade will tell you—understandably—that they want
complete and total upward API/ABI compatibility.

Which is fundamentally impossible to achieve, while also fixing old
limitations and old issues.

Upward-compatibility which both leaves customers with unfixable issues,
and it leaves developers (both existing and potential new) with limited
and absurd interfaces.

Which discourages new customers and new adoption. Development
difficulties which also makes existing development more costly, and
more problematic.

Sufficient new adoptions and new deployments are necessary to offset
those apps inevitably departing. And those existing sites that are
paying for support and that are maintaining their apps want fixes and
updates.

It's all a balance. But that balance has been skewed toward no-changes
for too many decades. And even where the old designs are still
working, they're routinely reaching design limits. Two TiB storage
addressing, for instance.

> Hum, don't you see there is a sort of flaw in your rationale.

I'm referring to ideas and approaches and concepts.

There are bad trade-offs either way. With preserving compatibility. And
with breaking compatibility. Neither is preferable. And neither works.
And neither will be popular.

Keep the best of the designs and implementations. Reject and replace
the worst, where and when appropriate.

But again, there's this recurring belief it's possible to have both
upward-compatibility and to fix fundamental errors, and that's just not
the case.

You cannot put sixteen or thirty-two bytes into an eight-byte buffer.
That just fundamentally doesn't work.

Upgrades can and will and must break specific APIs, where that's
necessary, and which'll send some sites into agony around upgrades.

> In my humble opinion, if VMS is of yesterday (right) and not will be
> immediatly tomorow (right) help today those are on yesterday to go to
> tomorow.

The last twenty years of the keep-mostly-doing-what-we've-done strategy
have been a roaring success for OpenVMS, and OpenVMS is clearly
everywhere and massively popular, eh?

A few things to ponder:

...How do you fit sixteen or thirty-two bytes of data into an eight
byte buffer? Explain how that works.

...How easy was it to write a non-trivial 64-bit native app on OpenVMS?
Go try it.

...How can a developer isolate their app code and their system against
untrusted data, or against a remote attacker that might gain execute
access? Attacks are only improving.

...And of course, everybody here has secure, encrypted, robust, and
easy-to-use secrets (passwords, private keys, etc) storage, and robust
mechanisms for secrets deployment, right?

We aren't in the last millennium (yesterday), even of some of our
designs and approaches and thinking and apps might still be.

[Dave Froble]

On 4/16/2020 6:26 PM, Stephen Hoffman wrote:
> On 2020-04-16 21:35:44 +0000, g érard Calliet said:
>
>> Le 15/04/2020 à 17:15, Stephen Hoffman a écrit :
>>> Tomorrow is not yesterday.
>> Totally right.
>>
>> If I unsderstand your point, because tomorrow is not yesterday,
>> because VMS is of yesterday, and not will be just immediatly tomorow,
>> the good choice is to abandon the users of yesterday,
>> to get profit today
>
> Existing users that aren't upgrading (and that aren't staying on
> support) aren't profitable.

For VSI. The users may be very profitable.

> They might eventually upgrade (which would be good for VSI), or they
> might eventually migrate elsewhere (which is common).

Embracing VSI would be my choice.

> Those users that do upgrade will tell you—understandably—that they want
> complete and total upward API/ABI compatibility.

Perhaps, and perhaps not. Not sure just what "total upward
compatibility" is. This may not be an easy concept.

> Which is fundamentally impossible to achieve, while also fixing old
> limitations and old issues.

I'm going to disagree. It will depend heavily on just what is meant by
"fixing". Myself, I'd say "add new capabilities".

> Upward-compatibility which both leaves customers with unfixable issues,
> and it leaves developers (both existing and potential new) with limited
> and absurd interfaces.

Ok, if the "old" leave users with problems, then they either implement
solutions to the problems, or, they live with the problems. Some will
live with the problems. Others will recognize that modifications are
needed, and implement the modifications. Either option is acceptable,
depending on customer's needs.

> Which discourages new customers and new adoption. Development
> difficulties which also makes existing development more costly, and more
> problematic.

Addressing that problem will solve the issues.

> Sufficient new adoptions and new deployments are necessary to offset
> those apps inevitably departing. And those existing sites that are
> paying for support and that are maintaining their apps want fixes and
> updates.

So, do so.

> It's all a balance. But that balance has been skewed toward no-changes
> for too many decades. And even where the old designs are still working,
> they're routinely reaching design limits. Two TiB storage addressing,
> for instance.

Perhaps I don't need greater than 2 TB. While some might. Seems to me
that the new file system will address the 2 TB issue, while some like me
will continue to use ODS2. Do not other OSs allow more than one file
system? VMS already does so.

>> Hum, don't you see there is a sort of flaw in your rationale.
>
> I'm referring to ideas and approaches and concepts.

Most definitely.

> There are bad trade-offs either way. With preserving compatibility. And
> with breaking compatibility. Neither is preferable. And neither works.
> And neither will be popular.

Why not do both?

> Keep the best of the designs and implementations. Reject and replace the
> worst, where and when appropriate.

No need to wield the knife so heavily.

> But again, there's this recurring belief it's possible to have both
> upward-compatibility and to fix fundamental errors, and that's just not
> the case.

Strictly speaking, no. But what about fixing the fundamental errors (as
in implementing new capabilities) and not chopping out the old. LEaving
the issues, if the old is the chosen path for some users?

> You cannot put sixteen or thirty-two bytes into an eight-byte buffer.
> That just fundamentally doesn't work.

Nope. But you can provide new functionality that solves that problem.
Ues it, or not, as each user chooses.

> Upgrades can and will and must break specific APIs, where that's
> necessary, and which'll send some sites into agony around upgrades.

"Could", but not "must". Allow a choice.

>> In my humble opinion, if VMS is of yesterday (right) and not will be
>> immediatly tomorow (right) help today those are on yesterday to go to
>> tomorow.
>
> The last twenty years of the keep-mostly-doing-what-we've-done strategy
> have been a roaring success for OpenVMS, and OpenVMS is clearly
> everywhere and massively popular, eh?

I'd suggest most of the blame of that lies with DEC/Compaq/HP not
maintaining the OS over those 20 years, not doing a decent job of
marketing, telling people to migrate elsewhere, and all the rest of the
mis-handling of the OS.

> A few things to ponder:
>
> ...How do you fit sixteen or thirty-two bytes of data into an eight byte
> buffer? Explain how that works.

A new routine with adequate buffer size.

> ...How easy was it to write a non-trivial 64-bit native app on OpenVMS?
> Go try it.

Make it easier.

> ...How can a developer isolate their app code and their system against
> untrusted data, or against a remote attacker that might gain execute
> access? Attacks are only improving.

If this is needed, then use the tools that do so. The need may not be
universal. Leave the decision to the users.

> ...And of course, everybody here has secure, encrypted, robust, and
> easy-to-use secrets (passwords, private keys, etc) storage, and robust
> mechanisms for secrets deployment, right?

No, we don't. Some of this is being addressed by VSI.

> We aren't in the last millennium (yesterday), even of some of our
> designs and approaches and thinking and apps might still be.

Rarely been a good idea to "re-invent the wheel". If it ain't broke,
don't fix it. If something new is needed, implement it.

[Alex Rubens]

On Wednesday, March 25, 2020 at 1:02:21 PM UTC-4, gérard Calliet wrote:
> Hello,
>
> Because I think you have a lot of time at home now, I have a question.
>
> With VSI tcpip new stack, I have a lot of information in the SPD about
> what can be done with ssh, for example:
>
> """SSH functionality has been extended to include the following:
> • Diffie-Hellman-group14-sha256 (RFC 4250). This addition improves
> security of the key exchange by using a hash with more bits.
> • Elliptic curve Diffie-Hellman (ECDH) key agreement [RFC 5656]. Curves
> are: nistp256, nistp384, nistp521. The curve chosen will be sufficient
> to support the hash for the host keys involved. For example: o If the
> host key is ECDSA-nistp521, only the curve nistp521 will be available. o
> If the host key is ECDSA-nistp384, the curves nistp384 and nistp521 will
> be available. o If the host key is ECDSA-nistp256, the curves nistp256,
> nistp384 and nistp521 will be available.
> • Elliptic curve digital signature algorithm (ECDSA) [RFC 5656]. Public
> keys are written in a format close to what is used by OpenSSH; OpenSSH
> public keys can be read as-is. The "Subject" and "Comment" lines in the
> key may need to be removed to make the keys readable by OpenSSH. ECDSA
> supports curves nistp256, nistp384, nistp521.
> ..... """
>
> I cannot find something precise like that for the last versions of the
> old tcpip stack delivered by VSI, including all good ECOs.
>
> It is important for me to know about that to be able to determine if the
> last versions of tcpip/ssh on the old stack (for itanium and for alpha)
> are reasonably usable in the modern world, before being able to use the
> new stack. Another reason behind that is knowing if is worth it to go to
> VSI and tcpip (old stack) only to have more functionalities on ssh.
>
> Take care
>
> Gérard Calliet

[gérard Calliet]

Le 17/04/2020 à 00:26, Stephen Hoffman a écrit :
> On 2020-04-16 21:35:44 +0000, g érard Calliet said:
>
>> Le 15/04/2020 à 17:15, Stephen Hoffman a écrit :
>>> Tomorrow is not yesterday.
>> Totally right.
>>
>> If I unsderstand your point, because tomorrow is not yesterday,
>> because VMS is of yesterday, and not will be just immediatly tomorow,
>> the good choice is to abandon the users of yesterday,
>> to get profit today
>
> Existing users that aren't upgrading (and that aren't staying on
> support) aren't profitable.

The question is not about upgrading or not upgrading. The question is
about the pace of it. And yes there is a pure business trade-off about
when and how getting profit. If you do now the maximum of profit because
it's possible with desperate ones, they cannot do now anything else, you
get now profit and you destroy profits in the future.

Because they were not upgrading, often, because they thought it was a
no-future environment. And it could take time for they b=change thier
mind. If you appear to them as taking off the last profit to prepare a
solution they now think as utopic, you destroy your business.

And yes it is a here the pure business aspect of the situation. I'm not
arguing here around your analysis about technical trade-off about upward
compatibility, necessity of change, which are ery important topics,
complex, and I'm not thinking they can get simple solutions. Thanks to
all people here, we have the eternity to speak about that (thanks Dave,
thanks Stephen, thanks... :) ).

And more than that I'm speaking about business *and* about community
responsivness. My "Cassandre way" (you have got anothers :) ) is: if we
redo an agressive and closed business with a totally passive community,
we'll fail.

[Stephen Hoffman]

On 2020-04-16 23:34:25 +0000, Dave Froble said:

> On 4/16/2020 6:26 PM, Stephen Hoffman wrote:
>> On 2020-04-16 21:35:44 +0000, g érard Calliet said:
>>

>>> Le 15/04/2020 à 17:15, Stephen Hoffman a écrit :

>>>> Tomorrow is not yesterday.
>>> Totally right.
>>>
>>> If I unsderstand your point, because tomorrow is not yesterday, because
>>> VMS is of yesterday, and not will be just immediatly tomorow, the good
>>> choice is to abandon the users of yesterday, to get profit today
>>
>> Existing users that aren't upgrading (and that aren't staying on
>> support) aren't profitable.
>
> For VSI. The users may be very profitable.

If the users are very profitable and are no not keeping OpenVMS current
and supported, they probably aren't the best long-term prospect for
VSI, but whatevers.

>> They might eventually upgrade (which would be good for VSI), or they
>> might eventually migrate elsewhere (which is common).
>
> Embracing VSI would be my choice.
>

>> Those users that do upgrade will tell you—understandably—that they

>> want complete and total upward API/ABI compatibility.
>
> Perhaps, and perhaps not. Not sure just what "total upward
> compatibility" is. This may not be an easy concept.
>
>> Which is fundamentally impossible to achieve, while also fixing old
>> limitations and old issues.
>
> I'm going to disagree. It will depend heavily on just what is meant by
> "fixing". Myself, I'd say "add new capabilities".

There are bits of OpenVMS that are just broken. Not the least of which
are parts of system security.

>> Upward-compatibility which both leaves customers with unfixable issues,
>> and it leaves developers (both existing and potential new) with limited
>> and absurd interfaces.
>
> Ok, if the "old" leave users with problems, then they either implement
> solutions to the problems, or, they live with the problems. Some will
> live with the problems. Others will recognize that modifications are
> needed, and implement the modifications. Either option is acceptable,
> depending on customer's needs.

Downside is now VSI has to maintain both, document both, developers
have to understand and check for and maintain one or more, and some
choices are known vulnerable, and new apps and new developers get to
wade through the defaults, and—classically—the defaults are bad
choices. Preserving the old is not without costs. Those costs might
well be acceptable to some. They won't be to others.

...

>> It's all a balance. But that balance has been skewed toward no-changes
>> for too many decades. And even where the old designs are still
>> working, they're routinely reaching design limits. Two TiB storage
>> addressing, for instance.
>
> Perhaps I don't need greater than 2 TB. While some might. Seems to me
> that the new file system will address the 2 TB issue, while some like
> me will continue to use ODS2. Do not other OSs allow more than one
> file system? VMS already does so.

This isn't limited to the file systems. There's a whole lot of other
code that'll break, due to 32-bit values scattered around within the
RMS data structures, XQP data structures, device drivers, and in $qio
and $io_perform storage I/O calls.

As for file systems, ExFAT (read-write) and maybe NTFS (read, or
read-write) would be nice to see added, maybe also UDF and a few other
choices later. But I digress.

...

>
>> But again, there's this recurring belief it's possible to have both
>> upward-compatibility and to fix fundamental errors, and that's just not
>> the case.
>
> Strictly speaking, no. But what about fixing the fundamental errors
> (as in implementing new capabilities) and not chopping out the old.
> LEaving the issues, if the old is the chosen path for some users?

Great idea! Why didn't I think of that! Oh, wait, it's because that
cannot be done. Because we cannot fit 16 or 32 bytes of data into an
existing 8-byte buffer. Among other limits.

>
>> You cannot put sixteen or thirty-two bytes into an eight-byte buffer.
>> That just fundamentally doesn't work.
>
> Nope. But you can provide new functionality that solves that problem.
> Ues it, or not, as each user chooses.

Which now means VSI has both secured code and insecure code, and has to
maintain both.
The developers and third-party vendors now have the scintillating joy
of having to correctly adapt to both, too.

>> Upgrades can and will and must break specific APIs, where that's
>> necessary, and which'll send some sites into agony around upgrades.
>
> "Could", but not "must". Allow a choice.

Other than being fundamentally impossible, sure.

>
>>> In my humble opinion, if VMS is of yesterday (right) and not will be
>>> immediatly tomorow (right) help today those are on yesterday to go to
>>> tomorow.
>>
>> The last twenty years of the keep-mostly-doing-what-we've-done strategy
>> have been a roaring success for OpenVMS, and OpenVMS is clearly
>> everywhere and massively popular, eh?
>
> I'd suggest most of the blame of that lies with DEC/Compaq/HP not
> maintaining the OS over those 20 years, not doing a decent job of
> marketing, telling people to migrate elsewhere, and all the rest of the
> mis-handling of the OS.

~25 years, if we're counting Windows Affinity and the rest of 1990s
DEC. And now the "fun" of trying to catch up with selected parts of
what's happened over the last ~25 or so awaits VSI.

>> A few things to ponder:
>>
>> ...How do you fit sixteen or thirty-two bytes of data into an eight
>> byte buffer? Explain how that works.
>
> A new routine with adequate buffer size.

Which breaks ABI and API and upward-compatibility.

>> ...How easy was it to write a non-trivial 64-bit native app on OpenVMS?
>> Go try it.
>
> Make it easier.

Which again breaks ABI and API and upward-compatibility. And some
cranky folks, if (when?) the 32-/64-bit design gets deprecated.

>
>> ...How can a developer isolate their app code and their system against
>> untrusted data, or against a remote attacker that might gain execute
>> access? Attacks are only improving.
>
> If this is needed, then use the tools that do so. The need may not be
> universal. Leave the decision to the users.

Which is how we get into messes.

>> ...And of course, everybody here has secure, encrypted, robust, and
>> easy-to-use secrets (passwords, private keys, etc) storage, and robust
>> mechanisms for secrets deployment, right?
>
> No, we don't. Some of this is being addressed by VSI.

Not that I've heard about a key store...

>
>> We aren't in the last millennium (yesterday), even of some of our
>> designs and approaches and thinking and apps might still be.
>
> Rarely been a good idea to "re-invent the wheel". If it ain't broke,
> don't fix it. If something new is needed, implement it.

With a whole lot of code, it works, leave it alone.

But with some parts of existing code, if it ain't broke, you're
probably ignoring some deeper issues awaiting within.

We all have to make the trade-offs inherent here, too.

But getting back to an earlier comment up-thread, don't expect folks
looking at OpenVMS for overhauled and new deployments to be interested
in these trade-offs, save as these trade-offs might or do increase the
cost and complexity of selecting OpenVMS.

[Craig A. Berry]

On 4/17/20 2:47 PM, Stephen Hoffman wrote:
> On 2020-04-16 23:34:25 +0000, Dave Froble said:

>> Ok, if the "old" leave users with problems, then they either implement
>> solutions to the problems, or, they live with the problems.  Some will
>> live with the problems.  Others will recognize that modifications are
>> needed, and implement the modifications.  Either option is acceptable,
>> depending on customer's needs.
>
> Downside is now VSI has to maintain both, document both, developers have
> to understand and check for and maintain one or more, and some choices
> are known vulnerable, and new apps and new developers get to wade
> through the defaults, and—classically—the defaults are bad choices.
> Preserving the old is not without costs. Those costs might well be
> acceptable to some. They won't be to others.

Yes, there are costs to staying with the old stack. There are costs to
moving to the new stack as well. In no particular order, while doing a
basic installation of 10.6 and configuring nothing but SSH, I
encountered the following annoyances.

The first thing the installation guide has you do is edit modparams.dat
and run autogen. Ouch. Just lost anyone who is new to VMS system
management (or rusty).

A significant portion of the release notes for 10.6 describe known
problems and things that don't work yet, such as jumbo frames and DECnet
over IP. Maybe that will all get sorted out in 10.7, due during the
last half of this year, right around when the old stack goes out of support.

The installation does walk you through configuring an interface.
Everything else involves learning a new command-line interface that is
utterly unlike either the TCP/IP Services command-line interface or the
Multinet command-line interface. There does not appear to be a
menu-based configuration capability, and I could not find a way to list
what services are configured or what services are available to be
configured.

IP SHOW bizarrely takes no parameters but uses qualifiers for all of the
objects of the verb "show." So, for example, the straightforward

$ IP SHOW VERSION

doesn't work; you have to say:

$ IP SHOW/VERSION

None of the familiar commands for viewing and modifying network status
is available (ping, netstat, nslookup, dig, traceroute, etc.). No doubt
there are native equivalents for some if one spends enough time poring
over the documentation to find them. HELP IP DIG does say:

DIG can be used with the Unix-style syntax by defining it as a foreign
command:

$ DIG :== $IP$SYSTEM:DIG

so maybe there are others scattered about that you can set up for
yourself, but there is no equivalent to
sys$startup:tcpip$define_commands.com.

Setting up SSH involves manually copying configuration files from
templates as well as executing commands to select and enable the
service. It works, and does have more key exchange algorithms and
ciphers than the old stack. Sometimes it asks for a passphrase when
connecting and sometimes it doesn't. It never did before. No idea
what's going on there.

There are several new test failures in the Perl test suite on
socket-related tests. These are most likely due to differences between
reported capabilities and actual capabilities in the CRTL and/or how the
new stack implements what's underneath the CRTL calls, such as the fact
that SO_REUSEPORT is defined in socket.h but doesn't work when passed to
setsockopt(). Each of these cases would take an hour or three to boil
down into a simple reproducer in C that could be reported. Not sure
I'll ever get to it.

Lord help me if I ever have to set up a print queue or define key
mappings for TN3270 emulation. In any case, I just wanted to give a few
examples of why folks need to budget a lot of time for this transition.

[Paul Anderson]

On 4/17/20 6:08 PM, Craig A. Berry wrote:

> The first thing the installation guide has you do is edit modparams.dat
> and run autogen.  Ouch.  Just lost anyone who is new to VMS system
> management (or rusty).

We automatically update MODPARAMS.DAT in the forthcoming V10.7.

> A significant portion of the release notes for 10.6 describe known
> problems and things that don't work yet, such as jumbo frames and DECnet
> over IP.  Maybe that will all get sorted out in 10.7, due during the
> last half of this year, right around when the old stack goes out of
> support.

Jumbo frames support not added yet. DECnet-over-IP works just fine in
V10.5 and V10.6.

> The installation does walk you through configuring an interface.
> Everything else involves learning a new command-line interface that is
> utterly unlike either the TCP/IP Services command-line interface or the
> Multinet command-line interface.  There does not appear to be a
> menu-based configuration capability, and I could not find a way to list
> what services are configured or what services are available to be
> configured.

$ IP CONFIGURE /SERVERS and type SHOW at the SERVER-CONFIG> prompt to
see all services and which ones are configured.

If you like the TCP/IP Services menu style, there is
SYS$ETC:IP$SETUP.COM that, although officially unsupported, works well
at simplifying some of the most common configuration tasks.

> IP SHOW bizarrely takes no parameters but uses qualifiers for all of the
> objects of the verb "show."  So, for example, the straightforward
>
> $ IP SHOW VERSION
>
> doesn't work; you have to say:
>
> $ IP SHOW/VERSION

Sorry.

> None of the familiar commands for viewing and modifying network status
> is available (ping, netstat, nslookup, dig, traceroute, etc.).  No doubt
> there are native equivalents for some if one spends enough time poring
> over the documentation to find them.

They're there--use the IP PING command for ping; not unlike TCP/IP
Services, where you have to define a symbol for ping.

>  HELP IP DIG does say:
>
>   DIG can be used with the Unix-style syntax by defining it as a foreign
>     command:
>
>       $ DIG :== $IP$SYSTEM:DIG
>
> so maybe there are others scattered about that you can set up for
> yourself, but there is no equivalent to
> sys$startup:tcpip$define_commands.com.

There is a procedure SYS$MANAGER:IP$COMMANDS.COM that defines symbols
for some popular utilities, similar to TCPIP$DEFINE_COMMANDS.COM.

> Setting up SSH involves manually copying configuration files from
> templates as well as executing commands to select and enable the
> service.  It works, and does have more key exchange algorithms and
> ciphers than the old stack.  Sometimes it asks for a passphrase when
> connecting and sometimes it doesn't.  It never did before.  No idea
> what's going on there.

See IP$SETUP.COM mentioned above.

>
> There are several new test failures in the Perl test suite on
> socket-related tests.  These are most likely due to differences between
> reported capabilities and actual capabilities in the CRTL and/or how the
> new stack implements what's underneath the CRTL calls, such as the fact
> that SO_REUSEPORT is defined in socket.h but doesn't work when passed to
> setsockopt().

Have you called VSI support? They could probably help you with this.

Paul

[Dave Froble]

Ya know, it finally dawned on idiot Dave that the topic is TCP/IP, not
all of VMS.

As far as TCP/IP is concerned, yes, totally get rid of the old stuff.
VSI most likely got the Multinet stuff because they determined for
various reasons that the HP TCP/IP just wasn't going to work.

But why stop a good conversation? As for VMS ....

On 4/17/2020 3:47 PM, Stephen Hoffman wrote:
> On 2020-04-16 23:34:25 +0000, Dave Froble said:
>
>> On 4/16/2020 6:26 PM, Stephen Hoffman wrote:
>>> On 2020-04-16 21:35:44 +0000, g érard Calliet said:
>>>
>>>> Le 15/04/2020 à 17:15, Stephen Hoffman a écrit :
>>>>> Tomorrow is not yesterday.
>>>> Totally right.
>>>>
>>>> If I unsderstand your point, because tomorrow is not yesterday,
>>>> because VMS is of yesterday, and not will be just immediatly
>>>> tomorow, the good choice is to abandon the users of yesterday, to
>>>> get profit today
>>>
>>> Existing users that aren't upgrading (and that aren't staying on
>>> support) aren't profitable.
>>
>> For VSI. The users may be very profitable.

A profitable user on VMS is a good candidate for support revenue in the
future.

> If the users are very profitable and are no not keeping OpenVMS current
> and supported, they probably aren't the best long-term prospect for VSI,
> but whatevers.

Just need to find a way into their wallets ...

>>> They might eventually upgrade (which would be good for VSI), or they
>>> might eventually migrate elsewhere (which is common).
>>
>> Embracing VSI would be my choice.
>>
>>> Those users that do upgrade will tell you—understandably—that
>>> they want complete and total upward API/ABI compatibility.
>>
>> Perhaps, and perhaps not. Not sure just what "total upward
>> compatibility" is. This may not be an easy concept.

Now, maybe I'm not mainstream, but, I believe firmly in keeping
different levels separate. The OS is the OS, user apps should keep
hands off. The concept holds for other levels of apps.

If the concept is observed, then VSI could make changes to OS pieces and
not affect people's apps. Might be a dubious "IF".

>>> Which is fundamentally impossible to achieve, while also fixing old
>>> limitations and old issues.
>>
>> I'm going to disagree. It will depend heavily on just what is meant
>> by "fixing". Myself, I'd say "add new capabilities".
>
> There are bits of OpenVMS that are just broken. Not the least of which
> are parts of system security.

See above about segregation. Should be able to fix much without greatly
affecting user apps.

>>> Upward-compatibility which both leaves customers with unfixable
>>> issues, and it leaves developers (both existing and potential new)
>>> with limited and absurd interfaces.
>>
>> Ok, if the "old" leave users with problems, then they either implement
>> solutions to the problems, or, they live with the problems. Some will
>> live with the problems. Others will recognize that modifications are
>> needed, and implement the modifications. Either option is acceptable,
>> depending on customer's needs.
>
> Downside is now VSI has to maintain both, document both, developers have
> to understand and check for and maintain one or more, and some choices
> are known vulnerable, and new apps and new developers get to wade
> through the defaults, and—classically—the defaults are bad choices.
> Preserving the old is not without costs. Those costs might well be
> acceptable to some. They won't be to others.

What's to maintain? It already exists. Spend time on the "new stuff".

Consider having a system wide option, old or new. Then people using
"new" won't have to know a thing about "old". Note, not sure if this is
a good idea, just thinking random thoughts.

Consider VAX/VMS V7.3. This is it. No new stuff. Perhaps some of "old
VMS" could be treated in a similar manner.

Not saying the above have been thought out. Just attempting to come up
with ideas of how to avoid either/or which will always leave someone
unhappy. Unhappy as in no support revenue.

> ...
>
>>> It's all a balance. But that balance has been skewed toward
>>> no-changes for too many decades. And even where the old designs are
>>> still working, they're routinely reaching design limits. Two TiB
>>> storage addressing, for instance.
>>
>> Perhaps I don't need greater than 2 TB. While some might. Seems to
>> me that the new file system will address the 2 TB issue, while some
>> like me will continue to use ODS2. Do not other OSs allow more than
>> one file system? VMS already does so.
>
> This isn't limited to the file systems. There's a whole lot of other
> code that'll break, due to 32-bit values scattered around within the RMS
> data structures, XQP data structures, device drivers, and in $qio and
> $io_perform storage I/O calls.

If there are things to address such issues, then if used there would be
no problems.

While I hate "wrappers", they can be easy solutions. Perhaps implement
new solutions, with a wrapper that takes the old parameters. That does
get to be a problem when using RMS data structures. But hey, VSI has a
lot of smart people. Perhaps they will devise some good solutions.

> As for file systems, ExFAT (read-write) and maybe NTFS (read, or
> read-write) would be nice to see added, maybe also UDF and a few other
> choices later. But I digress.
>
> ...
>
>>
>>> But again, there's this recurring belief it's possible to have both
>>> upward-compatibility and to fix fundamental errors, and that's just

^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
Actually, two different subjects. Could have one without the other.
Will be exceptions.

>>> not the case.
>>
>> Strictly speaking, no. But what about fixing the fundamental errors
>> (as in implementing new capabilities) and not chopping out the old.
>> LEaving the issues, if the old is the chosen path for some users?
>
> Great idea! Why didn't I think of that! Oh, wait, it's because that
> cannot be done. Because we cannot fit 16 or 32 bytes of data into an
> existing 8-byte buffer. Among other limits.

But one can implement new routines ....

>>> You cannot put sixteen or thirty-two bytes into an eight-byte buffer.
>>> That just fundamentally doesn't work.
>>
>> Nope. But you can provide new functionality that solves that problem.
>> Ues it, or not, as each user chooses.
>
> Which now means VSI has both secured code and insecure code, and has to
> maintain both.
> The developers and third-party vendors now have the scintillating joy of
> having to correctly adapt to both, too.

It's not clear to me that one would have to adapt to both.

>>> Upgrades can and will and must break specific APIs, where that's
>>> necessary, and which'll send some sites into agony around upgrades.
>>
>> "Could", but not "must". Allow a choice.
>
> Other than being fundamentally impossible, sure.

Impossible only lasts until something is done.

>>>> In my humble opinion, if VMS is of yesterday (right) and not will be
>>>> immediatly tomorow (right) help today those are on yesterday to go
>>>> to tomorow.
>>>
>>> The last twenty years of the keep-mostly-doing-what-we've-done
>>> strategy have been a roaring success for OpenVMS, and OpenVMS is
>>> clearly everywhere and massively popular, eh?
>>
>> I'd suggest most of the blame of that lies with DEC/Compaq/HP not
>> maintaining the OS over those 20 years, not doing a decent job of
>> marketing, telling people to migrate elsewhere, and all the rest of
>> the mis-handling of the OS.
>
> ~25 years, if we're counting Windows Affinity and the rest of 1990s DEC.
> And now the "fun" of trying to catch up with selected parts of what's
> happened over the last ~25 or so awaits VSI.
>
>>> A few things to ponder:
>>>
>>> ...How do you fit sixteen or thirty-two bytes of data into an eight
>>> byte buffer? Explain how that works.
>>
>> A new routine with adequate buffer size.
>
> Which breaks ABI and API and upward-compatibility.

Not if the old routine is still around, and users only need 8 bytes.

>>> ...How easy was it to write a non-trivial 64-bit native app on OpenVMS?
>>> Go try it.
>>
>> Make it easier.
>
> Which again breaks ABI and API and upward-compatibility. And some cranky
> folks, if (when?) the 32-/64-bit design gets deprecated.

There are no perfect solutions.

>>> ...How can a developer isolate their app code and their system
>>> against untrusted data, or against a remote attacker that might gain
>>> execute access? Attacks are only improving.
>>
>> If this is needed, then use the tools that do so. The need may not be
>> universal. Leave the decision to the users.
>
> Which is how we get into messes.
>
>>> ...And of course, everybody here has secure, encrypted, robust, and
>>> easy-to-use secrets (passwords, private keys, etc) storage, and
>>> robust mechanisms for secrets deployment, right?
>>
>> No, we don't. Some of this is being addressed by VSI.
>
> Not that I've heard about a key store...

Nor have I, and one would be nice. If easy to use.

>>> We aren't in the last millennium (yesterday), even of some of our
>>> designs and approaches and thinking and apps might still be.
>>
>> Rarely been a good idea to "re-invent the wheel". If it ain't broke,
>> don't fix it. If something new is needed, implement it.
>
> With a whole lot of code, it works, leave it alone.
>
> But with some parts of existing code, if it ain't broke, you're probably
> ignoring some deeper issues awaiting within.
>
> We all have to make the trade-offs inherent here, too.
>
> But getting back to an earlier comment up-thread, don't expect folks
> looking at OpenVMS for overhauled and new deployments to be interested
> in these trade-offs, save as these trade-offs might or do increase the
> cost and complexity of selecting OpenVMS.
>
>
>
>


--

[Craig A. Berry]

On 4/17/20 6:53 PM, Paul Anderson wrote:
> On 4/17/20 6:08 PM, Craig A. Berry wrote:
>
>> The first thing the installation guide has you do is edit modparams.dat
>> and run autogen.  Ouch.  Just lost anyone who is new to VMS system
>> management (or rusty).
>
> We automatically update MODPARAMS.DAT in the forthcoming V10.7.

Sounds like progress.

>> A significant portion of the release notes for 10.6 describe known
>> problems and things that don't work yet, such as jumbo frames and DECnet
>> over IP.  Maybe that will all get sorted out in 10.7, due during the
>> last half of this year, right around when the old stack goes out of
>> support.
>
> Jumbo frames support not added yet.  DECnet-over-IP works just fine in
> V10.5 and V10.6.

Oops. I had it confused with clusters over IP.

>> The installation does walk you through configuring an interface.
>> Everything else involves learning a new command-line interface that is
>> utterly unlike either the TCP/IP Services command-line interface or the
>> Multinet command-line interface.  There does not appear to be a
>> menu-based configuration capability, and I could not find a way to list
>> what services are configured or what services are available to be
>> configured.
>
> $ IP CONFIGURE /SERVERS and type SHOW at the SERVER-CONFIG> prompt to
> see all services and which ones are configured.
>
> If you like the TCP/IP Services menu style, there is
> SYS$ETC:IP$SETUP.COM that, although officially unsupported, works well
> at simplifying some of the most common configuration tasks.

Thanks, looks promising. I hope it becomes supported at some point.

>> IP SHOW bizarrely takes no parameters but uses qualifiers for all of the
>> objects of the verb "show."  So, for example, the straightforward
>>
>> $ IP SHOW VERSION
>>
>> doesn't work; you have to say:
>>
>> $ IP SHOW/VERSION
>
> Sorry.

It's just bad grammar. Nouns should be parameters. Qualifiers are like
adverbs when they modify the verb, or adjectives when they modify a noun
(i.e., positional qualifiers). When you break that paradigm, anyone who
knows how DCL commands are supposed to work is surprised and confused.

> There is a procedure SYS$MANAGER:IP$COMMANDS.COM that defines symbols
> for some popular utilities, similar to TCPIP$DEFINE_COMMANDS.COM.

Thanks. It's in my sylogin.com now. I didn't see it mentioned in the
installation guide.

>> There are several new test failures in the Perl test suite on
>> socket-related tests.  These are most likely due to differences between
>> reported capabilities and actual capabilities in the CRTL and/or how the
>> new stack implements what's underneath the CRTL calls, such as the fact
>> that SO_REUSEPORT is defined in socket.h but doesn't work when passed to
>> setsockopt().
>
> Have you called VSI support?  They could probably help you with this.

I have e-mailed them the one about SO_REUSEPORT with a small C program
reproducing the bug; it works with setsockopt() but fails with
getsockopt(). It works for both with TCP/IP Services.

[Simon Clubley]

On 2020-04-15, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> ? ~Twenty years on, I'm still boggled by the feedback from the 1999

> Providence DECUS audience, around the DEC offer about open-sourcing
> OpenVMS. That audience was seriously opposed to open-sourcing of
> OpenVMS itself.
>

Was the plan for Open Source, as in you could take bits of VMS and
implement those bits in other operating systems, or was the plan
for Open Viewing, where you can freely view the source code, but not
be allowed to redistribute it or include bits of it in other operating
systems ?

[Simon Clubley]

On 2020-04-16, Dave Froble <da...@tsoft-inc.com> wrote:
> On 4/16/2020 6:26 PM, Stephen Hoffman wrote:
>
>> It's all a balance. But that balance has been skewed toward no-changes
>> for too many decades. And even where the old designs are still working,
>> they're routinely reaching design limits. Two TiB storage addressing,
>> for instance.
>
> Perhaps I don't need greater than 2 TB. While some might. Seems to me
> that the new file system will address the 2 TB issue, while some like me
> will continue to use ODS2. Do not other OSs allow more than one file
> system? VMS already does so.
>

Outside of the operating system neutral work of designing and writing the
new filesystem itself, adding a new filesystem to Linux is a relativel
easy operation on Linux for an experienced person or team.

That is not the case on VMS, and _especially _not for end user sites.
(It ranges from incredibly difficult to impossible for an end user site).

>
>> ...How easy was it to write a non-trivial 64-bit native app on OpenVMS?
>> Go try it.
>
> Make it easier.
>

As discussed recently, that's a limitation of how 64-bit mode was
implemented in VMS.

>> ...How can a developer isolate their app code and their system against
>> untrusted data, or against a remote attacker that might gain execute
>> access? Attacks are only improving.
>
> If this is needed, then use the tools that do so. The need may not be
> universal. Leave the decision to the users.
>

The tools to do this on VMS are very limited compared to what is available
in Linux (for example).

For example, Linux has MAC security, ASLR, KASLR, compilers with stack
smashing protection, etc.

VMS has none of these (although John is talking about adding stack
smashing protection to the compilers for x86-64 VMS).

>
>> We aren't in the last millennium (yesterday), even of some of our
>> designs and approaches and thinking and apps might still be.
>
> Rarely been a good idea to "re-invent the wheel". If it ain't broke,
> don't fix it. If something new is needed, implement it.
>

Something that was working can become broken through advances in
technology. For example, MD5 hashes were once considered to be
secure, but advancing technology changed that.

[Simon Clubley]

On 2020-04-17, Craig A. Berry <craig...@nospam.mac.com> wrote:
>
> IP SHOW bizarrely takes no parameters but uses qualifiers for all of the
> objects of the verb "show." So, for example, the straightforward
>
> $ IP SHOW VERSION
>
> doesn't work; you have to say:
>
> $ IP SHOW/VERSION
>

_Ouch!_ :-( That is horrible and really needs changing IMHO.

That is _not_ the VMS style.

[Simon Clubley]

Maybe 20 years ago some people might have felt like that, but why would
they still feel like that today ?

[Dave Froble]

On 4/20/2020 1:58 PM, Simon Clubley wrote:
> On 2020-04-15, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>> In article <r778f0$efr$1...@dont-email.me>, Stephen Hoffman
>> <seao...@hoffmanlabs.invalid> writes:
>>
>>> ~Twenty years on, I'm still boggled by the feedback from the 1999
>>> Providence DECUS audience, around the DEC offer about open-sourcing
>>> OpenVMS. That audience was seriously opposed to open-sourcing of
>>> OpenVMS itself.
>>
>> My guess is that today most VMS users would be opposed to open-sourcing
>> it.
>>
>
> Maybe 20 years ago some people might have felt like that, but why would
> they still feel like that today ?
>
> Simon.
>

Perhaps not as simple of a question as it might seem.

Now, one could use whatever restrictions one choose, however the ideas
of that idiot, forget his name, about if any part is used, the entire
app must become open source. And perhaps other silly stuff.

The objective of open source VMS must be considered. Could someone take
it, modify it, and then sell/distribute is as VMS? I sure would not
want that.

Not sure what the intentions were back in 1999. That would be Compaq I
believe. Would it have been possible for them to open source the entire
OS? What about proprietary stuff DEC purchased and included? Might
have been just bits and pieces.

I'd like to see the sources/listings available for free download, with
the restriction that one could modify things for private purposes, but
not distribute. That would lead to the dark side.

Being able to come up with useful modifications and suggest them to VSI
sounds good, but would VSI want to look at all the submissions?

[Jan-Erik Söderholm]

Den 2020-04-20 kl. 19:56, skrev Simon Clubley:
> On 2020-04-17, Craig A. Berry <craig...@nospam.mac.com> wrote:
>>
>> IP SHOW bizarrely takes no parameters but uses qualifiers for all of the
>> objects of the verb "show." So, for example, the straightforward
>>
>> $ IP SHOW VERSION
>>
>> doesn't work; you have to say:
>>
>> $ IP SHOW/VERSION
>>
>
> _Ouch!_ :-( That is horrible and really needs changing IMHO.
>
> That is _not_ the VMS style.
>
> Simon.
>

Is this a better syntax?


$ rmu /show version
Executing RMU for Oracle Rdb V7.3-300 on OpenVMS Alpha V8.4-2L2
$

I have lived with that for 25 years and never thought about
is as not being the VMS style...

I really can't see that rmu command, or the IP example, is "horrible"...

Maybe slightly different, but still very much VMS like.

Jan-Erik.

[Craig A. Berry]

As I explained up-thread:

[Stephen Hoffman]

On 2020-04-18 03:13:50 +0000, Dave Froble said:

> On 4/17/2020 3:47 PM, Stephen Hoffman wrote:
>>
>> There are bits of OpenVMS that are just broken. Not the least of which
>> are parts of system security.
>

> Should be able to fix much without greatly affecting user apps.

Other than "no", sure.

If VSI should plan to keep the old and insecure and broken APIs and
ABIs around, then there also becomes less reason to change the code; to
fix and to secure OpenVMS.

As for wrappers? OpenVMS has its share of ill-documented add-ons and wrappers.

And wrappers cannot address certain sorts of fundamental errors.

You just can't fit 16 or 32 bytes of data into an 8-byte app-defined,
app-declared, app-allocated buffer.

Not without rebuilding the app.