I realised that today is exactly 28 years since the 10,000 day
issue in VMS. I am starting to feel old. :-(
On a more serious note, I wonder what upcoming time boundaries
we are about to hit.
The obvious one is 2038, but I also wonder how many had 2030 as
their Y2K pivot point.
Any others you know of (both VMS and non-VMS) ?
On 5/19/2025 1:18 PM, Simon Clubley wrote:
I realised that today is exactly 28 years since the 10,000 day
issue in VMS. I am starting to feel old. :-(
On a more serious note, I wonder what upcoming time boundaries
we are about to hit.
The obvious one is 2038, but I also wonder how many had 2030 as
their Y2K pivot point.
Any others you know of (both VMS and non-VMS) ?
30 years before 32 bit signed seconds since 1970 => 18-Jan-2008
10 years before 32 bit signed seconds since 1970 => 18-Jan-2028
32 bit signed seconds since 1970 => 18-Jan-2038
split 2 digits year to support 1950-2049 (*) => 01-Jan-2050
30 years before 32 bit unsigned seconds since 1970 => 07-Feb-2076
10 years before 32 bit unsigned seconds since 1970 => 07-Feb-2096
32 bit unsigned seconds since 1970 => 07-Feb-2106
everything is going to have issues at Y10K
all common 64 bit times should first break after Y10K (**)
*) Common in many databases, but it is usually configurable,
so it can be changed to like 1970-2069 when needed.
**) But in order: Windows file time, VMS time, milliseconds
since 1970, seconds since 1970.
Arne
On 19/05/2025 20:19, Arne Vajhøj wrote:
On 5/19/2025 1:18 PM, Simon Clubley wrote:
I realised that today is exactly 28 years since the 10,000 day
issue in VMS. I am starting to feel old. :-(
On a more serious note, I wonder what upcoming time boundaries
we are about to hit.
The obvious one is 2038, but I also wonder how many had 2030 as
their Y2K pivot point.
Any others you know of (both VMS and non-VMS) ?
30 years before 32 bit signed seconds since 1970 => 18-Jan-2008
10 years before 32 bit signed seconds since 1970 => 18-Jan-2028
32 bit signed seconds since 1970 => 18-Jan-2038
split 2 digits year to support 1950-2049 (*) => 01-Jan-2050
30 years before 32 bit unsigned seconds since 1970 => 07-Feb-2076
10 years before 32 bit unsigned seconds since 1970 => 07-Feb-2096
32 bit unsigned seconds since 1970 => 07-Feb-2106
everything is going to have issues at Y10K
all common 64 bit times should first break after Y10K (**)
*) Common in many databases, but it is usually configurable,
so it can be changed to like 1970-2069 when needed.
**) But in order: Windows file time, VMS time, milliseconds
since 1970, seconds since 1970.
Arne
Just looked at our old suite. The majority of dates were stored as
Julian, so we just adjusted all (and historical ones) by 25000, so it
will work into 2028.
We also set the century break at 80, so that is good for a while!
I even have the archived conversion routines from are release program,
so I could rejig them for 2028 ;)
everything is going to have issues at Y10K
all common 64 bit times should first break after Y10K (**)
I realised that today is exactly 28 years since the 10,000 day issue in
VMS. I am starting to feel old. :-(
On a more serious note, I wonder what upcoming time boundaries we are
about to hit.
The obvious one is 2038, but I also wonder how many had 2030 as their
Y2K pivot point.
Any others you know of (both VMS and non-VMS) ?
Simon.
On 2025-05-19 17:18:24 +0000, Simon Clubley said:
I realised that today is exactly 28 years since the 10,000 day issue in
VMS. I am starting to feel old. :-(
On a more serious note, I wonder what upcoming time boundaries we are
about to hit.
The obvious one is 2038, but I also wonder how many had 2030 as their
Y2K pivot point.
Any others you know of (both VMS and non-VMS) ?
Simon.
Probably-partial list of bad dates for OpenVMS:
17-Nov-1858 00:00 UTC, OpenVMS base date
1-Jan-1970 00:00:00.00 UTC, epoch
19-May-1997, the LIBRTL 10K Day limit that derailed DECwindows
1-Jan-2000 Local, Y2K, various bugs and limits found and fixed in OpenVMS 2003 Local (details of this one escape me)
31-Dec-2028, HPE root certificate expires, leading to PCSI and
VMSINSTAL errors at install
7-Feb-2036 06:28:16 UTC NTP overflow
19-Jan-2038 03:14:07 UTC, signed 32-bit time_t overflow
20-Nov-2038 23:59:37UTC third GPS rollover.
2057 Local, OpenVMS pivot date (and DEC Centennial)
7-Feb-2106 06:28:15 UTC unsigned 32-bit time_t overflow
1-Jan-10000 00:00:00.00 Local, four digit year overflows
31-Jul-31086 02:48:05.47 UTC, end of the OpenVMS epoch
DEC ended the Y2K evaluation range prior to 2038, though at least 2038
bug was identified and resolved within OpenVMS.
VSI has their own signing certificate, and that'll be another bad date
to add to this list.
The details are vague since it's been several years since I looked at
DECnet Phase IV, but there's a signed integer delta date field somewhere
in DECnet Phase IV (from a base date offset) that overflowed, at least
if you followed the spec, in 2021 (IIRC). I do remember that VMS treated
it as an unsigned integer, hence VMS wasn't affected.
I _think_ it was in EVL, but I can't be sure now.
On 5/23/2025 14:11, Simon Clubley wrote:
The details are vague since it's been several years since I looked at
DECnet Phase IV, but there's a signed integer delta date field somewhere
in DECnet Phase IV (from a base date offset) that overflowed, at least
if you followed the spec, in 2021 (IIRC). I do remember that VMS treated
it as an unsigned integer, hence VMS wasn't affected.
I _think_ it was in EVL, but I can't be sure now.
I fixed that one; it'll be good until my 100th birthday.
On 2025-05-23, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
On 5/23/2025 14:11, Simon Clubley wrote:
The details are vague since it's been several years since I looked at
DECnet Phase IV, but there's a signed integer delta date field somewhere >>> in DECnet Phase IV (from a base date offset) that overflowed, at least
if you followed the spec, in 2021 (IIRC). I do remember that VMS treated >>> it as an unsigned integer, hence VMS wasn't affected.
I _think_ it was in EVL, but I can't be sure now.
I fixed that one; it'll be good until my 100th birthday.
$ set response/mode=good_natured
I wonder if people will have stopped using DECnet Phase IV by then ? :-)
These old protocols have a habit of staying around a lot longer than >expected. For example, I suspect somewhere people are still using UUCP, >2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ...
I wonder how old you have to be to recognise any of the above these days ? :-)
On 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than
expected. For example, I suspect somewhere people are still using UUCP,
2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ...
I wonder how old you have to be to recognise any of the above these days ? :-)
There is still a UUCP network. It runs over the internet rather than
the phone system but it runs the UUCP protocol.
On 2025-05-28, bill <bill.gunshannon@gmail.com> wrote:
On 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than
expected. For example, I suspect somewhere people are still using UUCP,
2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ...
I wonder how old you have to be to recognise any of the above these days ? :-)
There is still a UUCP network. It runs over the internet rather than
the phone system but it runs the UUCP protocol.
Motivated by that comment, I just had a quick look and discovered
that, 40 years on, FidoNet is still in use...
Simon.
There is still a UUCP network. It runs over the internet rather thanOr emulated serial lines.
the phone system but it runs the UUCP protocol.
The only one I know of that did not survive was BITNET. And if
I could get hold of sources for BITNET systems of various flavors
I wold love to see it revived as well.
On 5/29/2025 4:24 PM, jayjwa wrote:
bill <bill.gunshannon@gmail.com> writes:
There is still a UUCP network. It runs over the internet rather thanOr emulated serial lines.
the phone system but it runs the UUCP protocol.
https://www.digiater.nl/openvms/decus/vax92a/uucp/
❰jayjwa❙~❱✔≻ rlogin kirin
MAIL> send
To: uucp%"atr2!jayjwa"
Subj: UUCP
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
Can you believe that people are still using UUCP?
Exit
MAIL> exit
$ logout
rlogin: Connection to kirin closed normally.26:35.15
❰jayjwa❙~❱✔≻ mailx
mailx version v14.9.25. Type `?' for help
/var/spool/mail/jayjwa: 2 messages 1 new
O 1 Mail System Intern 2025-05-29 11:12 13/536 DON'T DELETE THIS
MESSAGE -- FOLDER INTERNAL DATA
▸N 2 jayjwa@kirin.lan 2025-05-29 11:26 21/891 UUCP
? 2
[-- Message 2 -- 21 lines, 891 bytes --]:
Date: Thu, 29 May 25 15:26:30 EDT
Message-Id: <00BAB43684479760.00000237@kirin.lan>
From: jayjwa@kirin.lan
Subject: UUCP
To: jayjwa@atr2.lan
Can you believe that people are still using UUCP?
?
Can you believe people are still using DECNET? :-)
bill
On 5/29/2025 2:23 PM, Simon Clubley wrote:
On 2025-05-28, bill <bill.gunshannon@gmail.com> wrote:
On 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than
expected. For example, I suspect somewhere people are still using UUCP, >>>> 2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ... >>>>
I wonder how old you have to be to recognise any of the above these days ? :-)
There is still a UUCP network. It runs over the internet rather than
the phone system but it runs the UUCP protocol.
Motivated by that comment, I just had a quick look and discovered
that, 40 years on, FidoNet is still in use...
I know of a number of old BBSes that still run on the INTERNET
today running on things like Tandy Color Computers. There is
still a lot of interest in old "Legacy" stuff. :-)
The only one I know of that did not survive was BITNET. And if
I could get hold of sources for BITNET systems of various flavors
I wold love to see it revived as well.
Can you believe people are still using DECNET? :-)
bill
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
On 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than
expected. For example, I suspect somewhere people are still using UUCP, >>>> 2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ... >>>>
SNA is an architecture. SNA over IP is still SNA. In fact 3270 over
BiSync can be part of an SNA Network. Would you include SNA over X.25?
On 2025-05-29, David Wade <g4ugm@dave.invalid> wrote:
On 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than >>>>> expected. For example, I suspect somewhere people are still using UUCP, >>>>> 2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ...
SNA is an architecture. SNA over IP is still SNA. In fact 3270 over
BiSync can be part of an SNA Network. Would you include SNA over X.25?
I look at SNA in the same way as I look at DECnet. At one time, DECnet
ran over its own transport and lower-level protocols. As a result of
a changing world, it was then adapted to run over a protocol (IP) which
is not a part of SNA/DECnet.
For me, the split point between original and current SNA/DECnet occurred when the previously fully native implementation was adapted to runover IP.
On 2025-05-28, bill <bill.gunshannon@gmail.com> wrote:
On 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than
expected. For example, I suspect somewhere people are still using UUCP,
2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ...
I wonder how old you have to be to recognise any of the above these days ? :-)
There is still a UUCP network. It runs over the internet rather than
the phone system but it runs the UUCP protocol.
Motivated by that comment, I just had a quick look and discovered
that, 40 years on, FidoNet is still in use...
Simon.
bill explained :
Can you believe people are still using DECNET? :-)
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
On 2025-05-30, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
Can you believe people are still using DECNET? :-)
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
For the first one, what about sshfs ?
Isn't DNA the equivalent of SNA?
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
On 2025-05-23, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
On 5/23/2025 14:11, Simon Clubley wrote:
The details are vague since it's been several years since I looked at
DECnet Phase IV, but there's a signed integer delta date field somewhere >>> in DECnet Phase IV (from a base date offset) that overflowed, at least
if you followed the spec, in 2021 (IIRC). I do remember that VMS treated >>> it as an unsigned integer, hence VMS wasn't affected.
I _think_ it was in EVL, but I can't be sure now.
I fixed that one; it'll be good until my 100th birthday.
$ set response/mode=good_natured
I wonder if people will have stopped using DECnet Phase IV by then ? :-)
On 5/30/2025 3:46 AM, Marc Van Dyck wrote:
bill explained :
Can you believe people are still using DECNET? :-)
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
Usage/API compatible? No.
High level functionality? Yes.
Among other options: FAL->FTP
and task to task->INETD.
On 5/27/2025 8:15 AM, Simon Clubley wrote:
On 2025-05-23, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
On 5/23/2025 14:11, Simon Clubley wrote:
The details are vague since it's been several years since I looked atI fixed that one; it'll be good until my 100th birthday.
DECnet Phase IV, but there's a signed integer delta date field somewhere >>>> in DECnet Phase IV (from a base date offset) that overflowed, at least >>>> if you followed the spec, in 2021 (IIRC). I do remember that VMS treated >>>> it as an unsigned integer, hence VMS wasn't affected.
I _think_ it was in EVL, but I can't be sure now.
$ set response/mode=good_natured
I wonder if people will have stopped using DECnet Phase IV by then ? :-)
My impression is that:
* people are now preferring IV over V, because people only
need IV functionality and IV is simpler
* people does not use DECnet that much today, but often enough
that they still prefer to have it installed
* usage is almost entirely:
- $ SET HOST
- RMS file specs
- task-to-task (for those running OSU HTTPD or something else
requiring it)
Arne
Arne Vajhøj laid this down on his screen :
On 5/27/2025 8:15 AM, Simon Clubley wrote:
I wonder if people will have stopped using DECnet Phase IV by then ? :-)
My impression is that:
* people are now preferring IV over V, because people only
need IV functionality and IV is simpler
* people does not use DECnet that much today, but often enough
that they still prefer to have it installed
* usage is almost entirely:
- $ SET HOST
- RMS file specs
- task-to-task (for those running OSU HTTPD or something else
requiring it)
From what I can see from this side of the pond, everyone uses DECnet
phase V exclusively with TCP/IP transport, so that any network gear can
be used, without having the network people involved.
Other advantage is that most OPenVMS installations today are used in environments that must be certified, and external audit people usually
know nothing about DECnet. They are mostly just interested in which IP
ports are opened. Since for DECnet you just need a few, it's easily justified. They couldn't be possibly bothered about what DECnet object
is enabled. They will complain about rlogin or telnet, but see nothing
wrong with set host. FTP ? God forbid. But FAL ? just fine... You can't imagine how easy it was for me to get OpenVMS systems pass audits with
flying colors, while my open systems colleagues suffered...
Arne Vajhøj wrote on 30/05/2025 :
On 5/30/2025 3:46 AM, Marc Van Dyck wrote:
bill explained :
Can you believe people are still using DECNET? :-)
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
Usage/API compatible? No.
High level functionality? Yes.
Among other options: FAL->FTP
How about opening a file remotely without having to copy it over first ?
and task to task->INETD.
Can be done from shell/scripting, without programming ?
On 31/05/2025 18:47, Arne Vajhøj wrote:
Can be done from shell/scripting, without programming ?
DCL does not speak TCP/IP. And probably never will.
But then script it in Python or Groovy or Perl or something
else that does speak TCP/IP.
What about COPY/FTP or the SSH commands?
Can be done from shell/scripting, without programming ?
DCL does not speak TCP/IP. And probably never will.
But then script it in Python or Groovy or Perl or something
else that does speak TCP/IP.
Arne
... external audit people ... are mostly just interested in which IP
ports are opened.
The context was:
#### and
#### transparent task to task communication ?
### and task to task->INETD.
So I assume that we are talking about how to rewrite
something like:
$ open/read f 0::"task=something"
$ read f line
$ close f
$ exit
On Sat, 31 May 2025 12:23:46 +0200, Marc Van Dyck wrote:
... external audit people ... are mostly just interested in which IP
ports are opened.
In other words, they haven’t got a clue.
On Fri, 30 May 2025 09:46:27 +0200, Marc Van Dyck wrote:
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
The irony of it, that the DEC concept requires creating a separate server process for every client connection,
$ typ tst.com
$ open/read/write f 0"myusername mypassword"::"task=add.com"
$ write f "123"
$ write f "456"
$ read f res
$ close f
$ write sys$output res
$ exit
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
On Fri, 30 May 2025 09:46:27 +0200, Marc Van Dyck wrote:
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
The irony of it, that the DEC concept requires creating a separate server
process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate
server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
But again my impression is that often the VMS systems are in same
server room and no routing required.
Arne Vajhj has brought this to us :
Several OpenVMS systems today are used in disaster-tolerant
But again my impression is that often the VMS systems are in same
server room and no routing required.
configurations. That implies at least two different locations.
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate
server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being shut down.
What about multiple concurrent connections? You can’t avoid creating extra processes in that situation.
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate
server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being >> shut down.
What about multiple concurrent connections? You can’t avoid creating extra >> processes in that situation.
On 5/31/2025 5:53 PM, Lawrence D'Oliveiro wrote:
On Sat, 31 May 2025 12:23:46 +0200, Marc Van Dyck wrote:
... external audit people ... are mostly just interested in which IP
ports are opened.
In other words, they haven’t got a clue.
Sure they do ...
They know that:
All computers run WEENDOZE ...
The only networking is TCP/IP ...
:-)
On 5/30/2025 8:18 AM, Simon Clubley wrote:
On 2025-05-29, David Wade <g4ugm@dave.invalid> wrote:
SNA is an architecture. SNA over IP is still SNA. In fact 3270 overOn 5/27/2025 8:15 AM, Simon Clubley wrote:
These old protocols have a habit of staying around a lot longer than >>>>>> expected. For example, I suspect somewhere people are still using UUCP, >>>>>> 2780/3780, xmodem, DDCMP, original SNA (not SNA over TCP/IP), etc, ... >>>
BiSync can be part of an SNA Network. Would you include SNA over X.25?
I look at SNA in the same way as I look at DECnet. At one time, DECnet
ran over its own transport and lower-level protocols. As a result of
a changing world, it was then adapted to run over a protocol (IP) which
is not a part of SNA/DECnet.
Isn't DNA the equivalent of SNA?
For me, the split point between original and current SNA/DECnet occurred when the previously fully native implementation was adapted to runover IP.
Isn't it more accurate to say that support for IP was added as a
possibility in parallel with still supporting the other protocols?
On 5/30/2025 8:34 AM, Simon Clubley wrote:
On 2025-05-30, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
Can you believe people are still using DECNET? :-)
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
For the first one, what about sshfs ?
Does is run on VMS?
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate
server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being >>> shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
Marc Van Dyck formulated on Monday :
Arne Vajhøj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
And even if no disaster tolerance is required, security teams often
mandates to have production, test, and development systems on separate network segments, with heavy firewalling in between. Good luck to
implement that with DECnet native routing.
Arne Vajhj wrote on 30/05/2025 :
On 5/30/2025 3:46 AM, Marc Van Dyck wrote:
bill explained :
Can you believe people are still using DECNET? :-)
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
Usage/API compatible? No.
High level functionality? Yes.
Among other options: FAL->FTP
How about opening a file remotely without having to copy it over first
?
and task to task->INETD.
Can be done from shell/scripting, without programming ?
Arne Vajhøj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
On 6/2/2025 4:34 AM, Marc Van Dyck wrote:
Arne Vajhøj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
True.
But at the risk of sounding like a broken record, that is also
something I got the impression is getting rarer.
But I don't know.
How many multi-site VMS clusters do you know?
In case anyone here has forgotten this, I draw your attention to the
early days of UCX and how DEC was dragged into the TCP/IP world against
its will. With what other vendor would an ongoing market exist for
a third-party TCP/IP stack that you had to pay for ?
On 5/31/2025 6:23 AM, Marc Van Dyck wrote:
Other advantage is that most OPenVMS installations today are used in
environments that must be certified, and external audit people usually
know nothing about DECnet. They are mostly just interested in which IP
ports are opened. Since for DECnet you just need a few, it's easily
justified. They couldn't be possibly bothered about what DECnet object
is enabled. They will complain about rlogin or telnet, but see nothing
wrong with set host. FTP ? God forbid. But FAL ? just fine... You can't
imagine how easy it was for me to get OpenVMS systems pass audits with
flying colors, while my open systems colleagues suffered...
:-)
When I was involved in audits of VMS systems then the auditors did have
VMS checklists and checked stuff like DECnet default access.
On 2025-05-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 5/31/2025 6:23 AM, Marc Van Dyck wrote:
Other advantage is that most OPenVMS installations today are used in
environments that must be certified, and external audit people usually
know nothing about DECnet. They are mostly just interested in which IP
ports are opened. Since for DECnet you just need a few, it's easily
justified. They couldn't be possibly bothered about what DECnet object
is enabled. They will complain about rlogin or telnet, but see nothing
wrong with set host. FTP ? God forbid. But FAL ? just fine... You can't
imagine how easy it was for me to get OpenVMS systems pass audits with
flying colors, while my open systems colleagues suffered...
:-)
That's not something which is funny Arne.
The auditors should know enough to be able to properly audit these
systems especially in the high-critical environment I get the impression
that Marc works in.
When I was involved in audits of VMS systems then the auditors did have
VMS checklists and checked stuff like DECnet default access.
And for as long as an organisation has such systems, then the auditors
should know how to audit them. If they don't, then they are not doing the
job they were paid to do (and which they may even have legal liability
for not doing it properly).
On 2025-05-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 5/31/2025 6:23 AM, Marc Van Dyck wrote:
Other advantage is that most OPenVMS installations today are used in
environments that must be certified, and external audit people usually
know nothing about DECnet. They are mostly just interested in which IP
ports are opened. Since for DECnet you just need a few, it's easily
justified. They couldn't be possibly bothered about what DECnet object
is enabled. They will complain about rlogin or telnet, but see nothing
wrong with set host. FTP ? God forbid. But FAL ? just fine... You can't
imagine how easy it was for me to get OpenVMS systems pass audits with
flying colors, while my open systems colleagues suffered...
:-)
That's not something which is funny Arne.
The auditors should know enough to be able to properly audit these
systems especially in the high-critical environment I get the impression
that Marc works in.
When I was involved in audits of VMS systems then the auditors did have
VMS checklists and checked stuff like DECnet default access.
And for as long as an organisation has such systems, then the auditors
should know how to audit them. If they don't, then they are not doing the
job they were paid to do (and which they may even have legal liability
for not doing it properly).
An attacker doesn't care if their entry point is currently fashionable
or not. They only care that they have an entry point they can exploit.
That doesn't just apply to VMS BTW as it applies to every single device, system, or protocol that an organisation has in use. If there is something that can be compromised, then the organisation's auditors should know how
to evaluate it.
Simon.
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate
server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being shut down.
What about multiple concurrent connections? You can’t avoid creating extra processes in that situation.
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being >>>> shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
I don't see a way to do that.
But please enlighten us.
In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being
shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
Yes.
I don't see a way to do that.
Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
But please enlighten us.
Mailboxes and QIO?
On 6/2/2025 1:16 PM, Dan Cross wrote:
In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time
before being
shut down.
What about multiple concurrent connections? You can’t avoid
creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
Yes.
I don't see a way to do that.
Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
But please enlighten us.
Mailboxes and QIO?
????
Let us look at how it works.
1) client activate task=foobar.exe
2) DECnet note that all existing processes are in use
and start a new process running foobar.exe
foobar.exe can do a lot of QIO on mailboxes, but that
it not gonna change that DECnet started a new process.
On 6/2/2025 1:16 PM, Dan Cross wrote:
In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being
shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
Yes.
I don't see a way to do that.
Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
But please enlighten us.
Mailboxes and QIO?
????
Let us look at how it works.
1) client activate task=foobar.exe
2) DECnet note that all existing processes are in use
and start a new process running foobar.exe
foobar.exe can do a lot of QIO on mailboxes, but that
it not gonna change that DECnet started a new process.
In article <683de86d$0$684$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 1:16 PM, Dan Cross wrote:
In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being
shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
Yes.
I don't see a way to do that.
Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
But please enlighten us.
Mailboxes and QIO?
????
Let us look at how it works.
1) client activate task=foobar.exe
2) DECnet note that all existing processes are in use
and start a new process running foobar.exe
foobar.exe can do a lot of QIO on mailboxes, but that
it not gonna change that DECnet started a new process.
Two cases: transparent task-to-task, and non-transparent.
You just said "DECnet task to task".
Earlier in the thread, Marc mentioned transparent task-to-task,
but you didn't say that. Non-transparent task-to-task
communications over DECnet do not require a new process; they
can make use of all of the techniques I mentioned earlier.
On 6/2/2025 4:23 PM, Dan Cross wrote:
In article <683de86d$0$684$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 1:16 PM, Dan Cross wrote:
In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being
shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
Yes.
I don't see a way to do that.
Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
But please enlighten us.
Mailboxes and QIO?
????
Let us look at how it works.
1) client activate task=foobar.exe
2) DECnet note that all existing processes are in use
and start a new process running foobar.exe
foobar.exe can do a lot of QIO on mailboxes, but that
it not gonna change that DECnet started a new process.
Two cases: transparent task-to-task, and non-transparent.
You just said "DECnet task to task".
Earlier in the thread, Marc mentioned transparent task-to-task,
but you didn't say that. Non-transparent task-to-task
communications over DECnet do not require a new process; they
can make use of all of the techniques I mentioned earlier.
I did not say transparent but the code I posted and Lawrence
commented on was transparent task to task.
Which means that Lawrences comment was actually correct.
And you calling it silly was wrong.
In article <101l2mn$3grj7$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 4:23 PM, Dan Cross wrote:
In article <683de86d$0$684$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 1:16 PM, Dan Cross wrote:
In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 6/2/2025 7:24 AM, Dan Cross wrote:
In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
on 02/06/2025, Lawrence D'Oliveiro supposed :
On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:
On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:
The irony of it, that the DEC concept requires creating a separate >>>>>>>>>>> server process for every client connection,
It doesn't.
Processes are re-used for task to task servers.
Hmm. Presumably the process is kept around for a limited time before being
shut down.
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
I suppose the troll has never heard of event-driven programming, >>>>>>> or asynchronous IO, or, for that matter, threads. Any of these
allow multiple connections to be served by a single process.
For TCP/IP yes.
For DECnet task to task??
Yes.
I don't see a way to do that.
Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
But please enlighten us.
Mailboxes and QIO?
????
Let us look at how it works.
1) client activate task=foobar.exe
2) DECnet note that all existing processes are in use
and start a new process running foobar.exe
foobar.exe can do a lot of QIO on mailboxes, but that
it not gonna change that DECnet started a new process.
Two cases: transparent task-to-task, and non-transparent.
You just said "DECnet task to task".
Earlier in the thread, Marc mentioned transparent task-to-task,
but you didn't say that. Non-transparent task-to-task
communications over DECnet do not require a new process; they
can make use of all of the techniques I mentioned earlier.
I did not say transparent but the code I posted and Lawrence
commented on was transparent task to task.
Which means that Lawrences comment was actually correct.
I've had Lawrence plonked for a while now. I strongly recommend
that you do the same. He is a troll, and does not engage in
good faith.
And you calling it silly was wrong.
I noticed you didn't quote the rest of my reply.
Like I said, I'm not convinced that one cannot write an
application that uses multiple devnames and then define logical
symbols so that it can interact with multiple clients using
transparent task-to-task communications.
And as I mentioned, I
don't see any structural reason that a transparent client cannot
communicate with a non-transparent server.
On 6/2/2025 5:01 PM, Dan Cross wrote:
In article <101l2mn$3grj7$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
[snip]
Which means that Lawrences comment was actually correct.
I've had Lawrence plonked for a while now. I strongly recommend
that you do the same. He is a troll, and does not engage in
good faith.
In this thread he first claimed that my tttt example created a new
process every time. When he was told that was wrong then he
acknowledge that. And the he noted that it would create multiple
processes is run concurrently. Which is correct.
That is good behavior.
There are other participants here that could learn
from that!
And you calling it silly was wrong.
I noticed you didn't quote the rest of my reply.
Like I said, I'm not convinced that one cannot write an
application that uses multiple devnames and then define logical
symbols so that it can interact with multiple clients using
transparent task-to-task communications.
So you called him silly because you think that he could be wrong
even though you don't have any specifics?
Interesting personality you have!
And as I mentioned, I
don't see any structural reason that a transparent client cannot
communicate with a non-transparent server.
I am not even sure what that means.
But I am pretty sure that my code example that Lawrence was commenting
on does not do it. That was totally classic transparent all the way.
So that argument is totally irrelevant.
With what other vendor would an ongoing market exist for a
third-party TCP/IP stack that you had to pay for ?
Nobody that has used UCX 1.x will ever forget it.
On 6/1/2025 11:44 PM, Lawrence D'Oliveiro wrote:
What about multiple concurrent connections? You can’t avoid creating
extra processes in that situation.
True.
But they will all be kept around and reused. OSU HTTPD use it for CGI
scripts - it works.
On 6/2/2025 4:48 AM, Marc Van Dyck wrote:
Marc Van Dyck formulated on Monday :
Arne Vajhj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
And even if no disaster tolerance is required, security teams often
mandates to have production, test, and development systems on separate
network segments, with heavy firewalling in between. Good luck to
implement that with DECnet native routing.
That is a common setup. But I don't see DECnet file copy
dev->test>prod as being a good idea in that setup.
Arne
On 6/2/2025 4:34 AM, Marc Van Dyck wrote:
Arne Vajhj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
True.
But at the risk of sounding like a broken record, that is also
something I got the impression is getting rarer.
But I don't know.
How many multi-site VMS clusters do you know?
Arne
Arne Vajhøj expressed precisely :
On 6/2/2025 4:34 AM, Marc Van Dyck wrote:
Arne Vajhøj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
True.
But at the risk of sounding like a broken record, that is also
something I got the impression is getting rarer.
But I don't know.
How many multi-site VMS clusters do you know?
At least the one that I was in charge of before I retired last year.
Two sites, 3 main applications, 3 production clusters, 3 other ones
on a distant site for disaster tolerance, 3 test systems, one for development, two clusters for system management, and two for system testing/crash & burn activities. FC storage with asynchronous long
distance replication. Backups on shared robots. Lots of fun...
on 02/06/2025, Arne Vajhøj supposed :
On 6/2/2025 4:48 AM, Marc Van Dyck wrote:
Marc Van Dyck formulated on Monday :
Arne Vajhøj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
And even if no disaster tolerance is required, security teams often
mandates to have production, test, and development systems on separate
network segments, with heavy firewalling in between. Good luck to
implement that with DECnet native routing.
That is a common setup. But I don't see DECnet file copy
dev->test>prod as being a good idea in that setup.
That's what we used to release new versions of applications from test
to production. Using DECnet, FAL, and proxies... I also envisaged to
get a DFS setup in place, but got retired before I could achieve that.
On Mon, 2 Jun 2025 09:25:22 -0400, Arne Vajhøj wrote:
On 6/1/2025 11:44 PM, Lawrence D'Oliveiro wrote:
What about multiple concurrent connections? You can’t avoid creating
extra processes in that situation.
True.
But they will all be kept around and reused. OSU HTTPD use it for CGI
scripts - it works.
But there’s a resource-usage cost associated with keeping processes in existence, isn’t there. As opposed to letting the server process control for itself how it will divide up multiple concurrent connections among a
set of service processes/threads.
(I know, CGI doesn’t give you that control anyway. This is why Web developers don’t like to use CGI nowadays.)
On 6/3/2025 4:25 AM, Marc Van Dyck wrote:
Arne Vajhj expressed precisely :
On 6/2/2025 4:34 AM, Marc Van Dyck wrote:
Arne Vajhj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
True.
But at the risk of sounding like a broken record, that is also
something I got the impression is getting rarer.
But I don't know.
How many multi-site VMS clusters do you know?
At least the one that I was in charge of before I retired last year.
Two sites, 3 main applications, 3 production clusters, 3 other ones
on a distant site for disaster tolerance, 3 test systems, one for
development, two clusters for system management, and two for system
testing/crash & burn activities. FC storage with asynchronous long
distance replication. Backups on shared robots. Lots of fun...
Dan just posted a question on the VSI forum about a 6 node cluster.
So clusters do exist.
I just see very few questions related to clusters. But maybe system
managers running clusters are generally more competent than average.
And very few need clusters for load volume leaving mostly HA reason.
Arne
On 6/3/2025 4:28 AM, Marc Van Dyck wrote:
on 02/06/2025, Arne Vajhj supposed :
On 6/2/2025 4:48 AM, Marc Van Dyck wrote:
Marc Van Dyck formulated on Monday :
Arne Vajhj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
And even if no disaster tolerance is required, security teams often
mandates to have production, test, and development systems on separate >>>> network segments, with heavy firewalling in between. Good luck to
implement that with DECnet native routing.
That is a common setup. But I don't see DECnet file copy
dev->test>prod as being a good idea in that setup.
That's what we used to release new versions of applications from test
to production. Using DECnet, FAL, and proxies... I also envisaged to
get a DFS setup in place, but got retired before I could achieve that.
I would have expected at least prod to be:
--(SFTP put install kit)-->SFTP server<--(SFTP get install kit)--prod
I have seen DECnet copy too, but 20+ years ago.
Arne
Arne Vajhøj used his keyboard to write :
On 6/3/2025 4:25 AM, Marc Van Dyck wrote:
Arne Vajhøj expressed precisely :
On 6/2/2025 4:34 AM, Marc Van Dyck wrote:
Arne Vajhøj has brought this to us :
But again my impression is that often the VMS systems are in same
server room and no routing required.
Several OpenVMS systems today are used in disaster-tolerant
configurations. That implies at least two different locations.
True.
But at the risk of sounding like a broken record, that is also
something I got the impression is getting rarer.
But I don't know.
How many multi-site VMS clusters do you know?
At least the one that I was in charge of before I retired last year.
Two sites, 3 main applications, 3 production clusters, 3 other ones
on a distant site for disaster tolerance, 3 test systems, one for
development, two clusters for system management, and two for system
testing/crash & burn activities. FC storage with asynchronous long
distance replication. Backups on shared robots. Lots of fun...
Dan just posted a question on the VSI forum about a 6 node cluster.
So clusters do exist.
I just see very few questions related to clusters. But maybe system
managers running clusters are generally more competent than average.
And very few need clusters for load volume leaving mostly HA reason.
Arne
Indeed. Clusters used the be a way to add compute power by horizontal scaling, because vertical scaling was either impossible or unaffordable. Today compute power is cheap, so clustering is mostly a high
availability tool. With the consequence that large number of nodes have largely disappeared ; most clusters are now two or three (if you don't
want a quorum disk) nodes only. I still remember the development cluster
I ran 25 years ago, a large LAVC with some 50 satellites that used to
take half a day to reboot...
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
On Wed, 04 Jun 2025 10:19:27 +0200, Marc Van Dyck wrote:
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
Basic security should be built into the core OS installation, not added as
an afterthought -- and an extra-cost one at that.
On Wed, 04 Jun 2025 10:19:27 +0200, Marc Van Dyck wrote:
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
Basic security should be built into the core OS installation, not added as
an afterthought -- and an extra-cost one at that.
Lawrence D'Oliveiro laid this down on his screen :
On Wed, 04 Jun 2025 10:19:27 +0200, Marc Van Dyck wrote:
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
Basic security should be built into the core OS installation, not
added as an afterthought -- and an extra-cost one at that.
There are already many security features available in OpenVMS. More than
what many people need. There must be a trade-off. Building more stuff
into the OS means that more customers pay for features they don't need. System Detective is a third party layered product offering features
that I never needed before working in the finance industry. Like, for example, recording all the activity of specific user's interactive
sessions, which is what we do for all privileged accounts.
On 6/5/2025 8:33 AM, Dave Froble wrote:
On 6/4/2025 6:49 PM, Lawrence D'Oliveiro wrote:
On Wed, 04 Jun 2025 10:19:27 +0200, Marc Van Dyck wrote:
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
Basic security should be built into the core OS installation, not
added as
an afterthought -- and an extra-cost one at that.
And I'm guessing that all that should also be free?
With that attitude, you and I and many others would be broke,
homeless, and such ..
Richard Stallman rears his ugly head yet again!!! Of course, it seems
to always be users who never develop anything who believe all the stuff
that gets developed should be free.
bill
On 6/5/2025 8:33 AM, Dave Froble wrote:
On 6/4/2025 6:49 PM, Lawrence D'Oliveiro wrote:
On Wed, 04 Jun 2025 10:19:27 +0200, Marc Van Dyck wrote:
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
Basic security should be built into the core OS installation, not
added as
an afterthought -- and an extra-cost one at that.
And I'm guessing that all that should also be free?
With that attitude, you and I and many others would be broke,
homeless, and such ..
Richard Stallman rears his ugly head yet again!!! Of course, it seems
to always be users who never develop anything who believe all the stuff
that gets developed should be free.
Lawrence D'Oliveiro laid this down on his screen :
Basic security should be built into the core OS installation, not added
as an afterthought -- and an extra-cost one at that.
There are already many security features available in OpenVMS. More than
what many people need. There must be a trade-off. Building more stuff
into the OS means that more customers pay for features they don't need.
GPL/AGPL is less business friendly than Apache/MIT/BSD on the software consumer side.
But GPL/AGPL is more business friendly than Apache/MIT/BSD on the
software producer side.
https://pointsecure.com/products/system-detective/
sounds pretty advanced.
Way more than the basic:
$ SET HOST xxx /LOG=whatever.log
Can it be configured to not log (or x out) certain
sensitive information that should not be logged?
Arne
On 6/4/2025 6:49 PM, Lawrence D'Oliveiro wrote:
On Wed, 04 Jun 2025 10:19:27 +0200, Marc Van Dyck wrote:
Copy between nodes only allowed for specific accounts, and those
accounts are audited by System Detective. That's an absolutely
superb product.
Basic security should be built into the core OS installation, not added as >> an afterthought -- and an extra-cost one at that.
And I'm guessing that all that should also be free?
With that attitude, you and I and many others would be broke, homeless, and such ..
More to the point: security is now basic OS function. Trying to add it
in external products is likely to fail, that is produce something less secure.
On Fri, 30 May 2025 09:46:27 +0200, Marc Van Dyck wrote:
Well, is anyone else proposing a suitable replacement for FAL and
transparent task to task communication ?
The irony of it, that the DEC concept requires creating a separate server process for every client connection, while the standard *nix sockets API
lets a single server process handle multiple connections (or fork off separate processes to spread the load, as it chooses).
I say “irony” because, of course, creation of all these extra processes willy-nilly is expensive on VMS (and on its Windows NT successor), while
it is much cheaper on *nix systems.
That's complicated in unix by the fact of multiple 'known' port
numbers for eg: ssh, telnet, nfs.etc. inetd looks at the port number
then spawns off the relevant process, depending on the port number.
Simple, neat and elegant, one of the good ideas from unix 4.3, back
in the 1980's. rBeing rplaced by xinetd, for better security.
On Thu, 05 Jun 2025 10:44:51 +0200, Marc Van Dyck wrote:
Lawrence D'Oliveiro laid this down on his screen :
Basic security should be built into the core OS installation, not added
as an afterthought -- and an extra-cost one at that.
There are already many security features available in OpenVMS. More than
what many people need. There must be a trade-off. Building more stuff
into the OS means that more customers pay for features they don't need.
Look at what comes standard in the Linux kernel: cgroups, namespaces, containers, virtualization, SELinux, AppArmor, the whole pluggable LSM mechanism, seccomp, netfilter, EBPF ... and that?s just off the top of my head.
On 2025-06-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 05 Jun 2025 10:44:51 +0200, Marc Van Dyck wrote:
Lawrence D'Oliveiro laid this down on his screen :
Basic security should be built into the core OS installation, not added >>>> as an afterthought -- and an extra-cost one at that.
There are already many security features available in OpenVMS. More than >>> what many people need. There must be a trade-off. Building more stuff
into the OS means that more customers pay for features they don't need.
Look at what comes standard in the Linux kernel: cgroups, namespaces,
containers, virtualization, SELinux, AppArmor, the whole pluggable LSM
mechanism, seccomp, netfilter, EBPF ... and that?s just off the top of my
head.
It also has ASLR, KASLR, shells that don't have access to privileges
outside of the privileges the user has, and encrypted filesystems.
It also has secure password hashing algorithms and a central source
of entropy, both of which have only recently been added to x86-64 VMS
(but not added to the other VMS architectures).
On a non-security level, it also has support for filesystems in user
space, and pluggable kernel mode filesystems (which can be unloaded
again without needing a reboot).
On Sun, 8 Jun 2025 23:39:23 +0100, chrisq wrote:
That's complicated in unix by the fact of multiple 'known' port
numbers for eg: ssh, telnet, nfs.etc. inetd looks at the port number
then spawns off the relevant process, depending on the port number.
Simple, neat and elegant, one of the good ideas from unix 4.3, back
in the 1980's. rBeing rplaced by xinetd, for better security.
systemd generalizes this with its socket-based service activation
concept: a single unit definition can specify any number of each of
IPv4 and IPv6 ports, Unix-family socket names, and also named pipes,
to listen on. Oh, and other things like VSOCK and Netlink endpoints as
well. Also POSIX message queues, USB function endpoints, and some
other lesser-known features.
<https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html>
That's interesting, but wonder if they really needed the overarching complpexity of systemd to enable that. More productive and less
disruptive to build on what is already there, but ymmv.
On Mon, 9 Jun 2025 17:34:31 +0100, chrisq wrote:
That's interesting, but wonder if they really needed the overarching
complpexity of systemd to enable that. More productive and less
disruptive to build on what is already there, but ymmv.
I wonder how you see “complexity” in a unified approach to things, as opposed to the old different-mechanism-for-each-connection-type legacy thinking.
On 6/9/25 23:51, Lawrence D'Oliveiro wrote:
On Mon, 9 Jun 2025 17:34:31 +0100, chrisq wrote:
That's interesting, but wonder if they really needed the overarching
complpexity of systemd to enable that. More productive and less
disruptive to build on what is already there, but ymmv.
I wonder how you see “complexity” in a unified approach to things, as
opposed to the old different-mechanism-for-each-connection-type legacy
thinking.
Good engineering is about minimising complexity as far as is practical,
which reduces design and ongoing maintenance, management and staff reeducation costs. Fewer possible bugs, as well.
On 6/10/2025 2:36 PM, chrisq wrote:
On 6/9/25 23:51, Lawrence D'Oliveiro wrote:
On Mon, 9 Jun 2025 17:34:31 +0100, chrisq wrote:
That's interesting, but wonder if they really needed the overarching
complpexity of systemd to enable that. More productive and less
disruptive to build on what is already there, but ymmv.
I wonder how you see “complexity” in a unified approach to things, as >>> opposed to the old different-mechanism-for-each-connection-type legacy
thinking.
Good engineering is about minimising complexity as far as is practical,
which reduces design and ongoing maintenance, management and staff
reeducation costs. Fewer possible bugs, as well.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away"
I think it is good engineering.
But it does not reflect the world of software development today. It is
common to have code bases grow 5-10% per year (which means doubling
every 10 years) for relative mature applications and 15-30% per
year (which means doubling every 3 years) for applications in
quickly evolving domains.
Arne
Had forgotten just how professional and fully sorted, Suse Linux was at
the time. In particular, the seamless install process.
On 6/9/25 23:51, Lawrence D'Oliveiro wrote:
On Mon, 9 Jun 2025 17:34:31 +0100, chrisq wrote:
That's interesting, but wonder if they really needed the overarching
complpexity of systemd to enable that. More productive and less
disruptive to build on what is already there, but ymmv.
I wonder how you see “complexity” in a unified approach to things, as
opposed to the old different-mechanism-for-each-connection-type legacy
thinking.
Good engineering is about minimising complexity as far as is practical,
which reduces design and ongoing maintenance, management and staff reeducation costs. Fewer possible bugs, as well.
Better mousetraps everywhere, but most of them add nothing to the sum of usefulness.
On Tue, 10 Jun 2025 23:33:52 +0100, chrisq wrote:
But the cost was that its system of pluggable modules got
their sticky little fingers into every corner of your Linux system.
On 2025-06-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 10 Jun 2025 23:33:52 +0100, chrisq wrote:
But the cost was that its system of pluggable modules got
their sticky little fingers into every corner of your Linux system.
How is that any different from systemd ?
Systemd is even worse because so much software now requires systemd >integration that it's increasingly difficult to run that software on >non-systemd Unix.
Oh, and for those of you who think Wayland is a full replacement for
X11, KiCad disagrees with you:
From: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
|KiCad does run on Wayland systems, but with significant limitations and known >|issues that substantially degrade the user experience. While you can design >|PCBs using KiCad on Wayland, you will encounter numerous problems that we >|cannot fix at the application level.
On 5/31/2025 3:47 PM, Arne Vajhj wrote:
The context was:
#### and
#### transparent task to task communication ?
### and task to task->INETD.
So I assume that we are talking about how to rewrite
something like:
$ open/read f 0::"task=something"
$ read f line
$ close f
$ exit
Or to provide a complete example:
$ typ add.com
$ open/read/write f sys$net
$ read f num1
$ num1 = f$integer(num1)
$ read f num2
$ num2 = f$integer(num2)
$ numres = num1 + num2
$ numres = f$string(numres)
$ write f numres
$ close f
$ exit
$ typ tst.com
$ open/read/write f 0"myusername mypassword"::"task=add.com"
$ write f "123"
$ write f "456"
$ read f res
$ close f
$ write sys$output res
$ exit
$ @tst
579
Arne
On Thu, 5 Jun 2025 10:01:17 -0400, Arne Vajhøj wrote:
GPL/AGPL is less business friendly than Apache/MIT/BSD on the software
consumer side.
But GPL/AGPL is more business friendly than Apache/MIT/BSD on the
software producer side.
Funny you should say that. Leaving aside the AGPL for a moment, I have
heard lots of people say that copyleft licences are not somehow “business- friendly”. What they are is “competition-friendly”: they ensure that market participants compete on a level playing field.
Remember that, in Free Software, there is not this hard-and-fast
distinction between those who “produce” it and those who “consume” it.
Sheer numbers of passive users do not, on their own, make much difference
to the success of a Free Software project. What matters is the liveliness
of the community that contributes back to the project.
And this is where copyleft comes in. Businesses are notorious for wanting
to take without giving back. Consider the difference between the BSD and Linux worlds: one remains anaemic and relegated to the fringe, weighed
down by freeloaders who keep sucking the lifeblood from the community,
while the other continues to thrive and grow, even as it has come to
dominate the entire computing landscape.
From the OpenVMS Freeware...
Linux and FreeBSD/OpenBSD/NetBSD projects are really not that different.
They are not driven by a profit motive.
Linux is obviously much more widely used than FreeBSD/OpenBSD/NetBSD,
but I very much doubt that the FreeBSD/OpenBSD/NetBSD people envy Linux
- I believe they have different goals.
There are open source projects that started with a permissive license
and where the people and the company behind felt that they were being
treated unfairly (usually when the small company's cloud service could
not compete with Amazon/Microsoft/Google offering the same service using
the company's software) so they decided to change license.
On Sat, 14 Jun 2025 13:00:29 -0400, Stephen Hoffman wrote:
From the OpenVMS Freeware...
See, that kind of thing is getting to the level of complexity where I
would say a Python script would be easier to manage.
On 6/14/2025 7:44 PM, Lawrence D'Oliveiro wrote:
See, that kind of thing is getting to the level of complexity where I
would say a Python script would be easier to manage.
Post a Python script doing the same.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 505 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 51:03:16 |
| Calls: | 9,921 |
| Calls today: | 8 |
| Files: | 13,804 |
| Messages: | 6,347,685 |