https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
On 11/4/2025 7:36 PM, Arne Vajh|+j wrote:
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
Sounds like a lot of work to me!
Arne
On 11/4/2025 6:51 PM, Arne Vajh|+j wrote:
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
Not surprising that it's x86 only, but that's disappointing. It was
stated other places that iSCSI is dependent on TCP/IP V7.0 so that
means no backporting to Integrity or Alpha.
On 11/4/2025 7:36 PM, Arne Vajh|+j wrote:
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
On 11/4/2025 7:51 PM, Arne Vajh|+j wrote:
On 11/4/2025 7:36 PM, Arne Vajh|+j wrote:
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
Yeah, it would be tough, but some of us are still holding out hope, but
the chances are admittedly quite slim that TCP/IP V7.0 might make
Alpha or IA64.
On 11/4/2025 7:51 PM, Arne Vajh|+j wrote:
On 11/4/2025 7:36 PM, Arne Vajh|+j wrote:
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
Yeah, it would be tough, but some of us are still holding out hope, but
the chances are admittedly quite slim that TCP/IP V7.0 might make
Alpha or IA64.
On 11/4/2025 10:10 PM, Robert A. Brooks wrote:
On 11/4/2025 7:51 PM, Arne Vajh|+j wrote:
On 11/4/2025 7:36 PM, Arne Vajh|+j wrote:
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
Yeah, it would be tough, but some of us are still holding out hope, but
the chances are admittedly quite slim that TCP/IP V7.0 might make
Alpha or IA64.
Back porting the code to C99 does not make any sense as
future updates will be a nigtmare.
That leaves:
* bringing clang to Alpha and Itanium
* updating VMS C to newer C (whatever is needed C11 or C23)
:-(
Arne
And yes, we're looking at TLS for x86 with TCPIP V7 as an important consumer.
On 11/4/2025 10:15 PM, Arne Vajh|+j wrote:
On 11/4/2025 10:10 PM, Robert A. Brooks wrote:
On 11/4/2025 7:51 PM, Arne Vajh|+j wrote:
On 11/4/2025 7:36 PM, Arne Vajh|+j wrote:
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
Interesting description of TCPIP 7.0.
Based on FreeBSD 14.2, will use DUNIX threads, x86-64 only (requires
clang), they will implement bmake.
Yeah, it would be tough, but some of us are still holding out hope, but
the chances are admittedly quite slim that TCP/IP V7.0 might make
Alpha or IA64.
Back porting the code to C99 does not make any sense as
future updates will be a nigtmare.
That leaves:
* bringing clang to Alpha and Itanium
* updating VMS C to newer C (whatever is needed C11 or C23)
:-(
And it is more than just a C compiler, you also need header changes,
backend changes (GEM), linker changes (thread local storage), image activator changes, pthreads changes, debugger, etc.
Moving clang to Alpha/Itanium means finding/resurrecting ancient LLVM targets OR trying to adapt clang to GEM (the reverse of what we've
done).-a Either way, you still have all the other downstream changes.
no Tomcat newer than 9.0.x, no ActiveMQ newer than 5.16.xetc. on Itanium.
https://events.vmssoftware.com/post-portsmouth-bootcamp-2025
has links to presentations and recordings!
They are migrating some IO and memory management code from
Macro-32/Bliss to C.
On Thu, 6 Nov 2025 15:31:53 -0500, Arne Vajh|+j wrote:
They are migrating some IO and memory management code from
Macro-32/Bliss to C.
Why not Rust?
Rust is not available for VMS.
Arne
On 06/11/2025 21:28, Arne Vajh|+j wrote:
Rust is not available for VMS.
Yet...
But the people writing average business applications have
many other languages prioritized higher than Rust.
On Thu, 6 Nov 2025 18:58:40 -0500, Arne Vajh|+j wrote:
But the people writing average business applications have
many other languages prioritized higher than Rust.
I thought VMS had a strong focus on high availability, process control,
that kind of thing.
On 11/6/2025 8:20 PM, Lawrence DrCOOliveiro wrote:
On Thu, 6 Nov 2025 18:58:40 -0500, Arne Vajh|+j wrote:
But the people writing average business applications have many other
languages prioritized higher than Rust.
I thought VMS had a strong focus on high availability, process control,
that kind of thing.
HA is architecture not programming language.
[snip] x86 can do FC but
that requires dedicating a HBA to each VM Guest. Hardly practical
unless you have a server with a lot of PCIe slots or very few OpenVMS
guests.
On 11/6/2025 6:35 PM, Chris Townley wrote:
On 06/11/2025 21:28, Arne Vajh|+j wrote:
Rust is not available for VMS.
Yet...
True.
But I do not expect it to become available any time soon.
Sure most OS and compiler people would love to see Rust on VMS.
In article <mmvmu4F1c8iU1@mid.individual.net>,
John H. Reinhardt <johnhreinhardt@thereinhardts.org> wrote:
[snip] x86 can do FC but
that requires dedicating a HBA to each VM Guest. Hardly practical
unless you have a server with a lot of PCIe slots or very few OpenVMS
guests.
One presumes fiber channel HBAs are mostly PCIe devies at this
point; given that, what about using SR-IOV to mux guests onto a
single (or small set of) HBA(s)?
On 11/6/2025 6:58 PM, Arne Vajh|+j wrote:
On 11/6/2025 6:35 PM, Chris Townley wrote:
On 06/11/2025 21:28, Arne Vajh|+j wrote:
Rust is not available for VMS.
Yet...
True.
But I do not expect it to become available any time soon.
Sure most OS and compiler people would love to see Rust on VMS.
I doubt most "OS and compiler people" have a clue what VMS
is or care what languages run on it.
On Thu, 6 Nov 2025 20:34:31 -0500, Arne Vajh|+j wrote:
On 11/6/2025 8:20 PM, Lawrence DrCOOliveiro wrote:
On Thu, 6 Nov 2025 18:58:40 -0500, Arne Vajh|+j wrote:
But the people writing average business applications have many other
languages prioritized higher than Rust.
I thought VMS had a strong focus on high availability, process control,
that kind of thing.
HA is architecture not programming language.
Memory safety has a part to play in minimizing downtime.
On 11/6/2025 6:58 PM, Arne Vajh|+j wrote:
On 11/6/2025 6:35 PM, Chris Townley wrote:
On 06/11/2025 21:28, Arne Vajh|+j wrote:
Rust is not available for VMS.
Yet...
True.
But I do not expect it to become available any time soon.
Sure most OS and compiler people would love to see Rust on VMS.
I doubt most "OS and compiler people" have a clue what VMS
is or care what languages run on it.
On 11/6/2025 6:58 PM, Arne Vajh|+j wrote:
On 11/6/2025 6:35 PM, Chris Townley wrote:
On 06/11/2025 21:28, Arne Vajh|+j wrote:
Rust is not available for VMS.
Yet...
True.
But I do not expect it to become available any time soon.
Sure most OS and compiler people would love to see Rust on VMS.
I doubt most "OS and compiler people" have a clue what VMS
is or care what languages run on it.
bill
In article <mn6p6bFfndpU2@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
On 11/6/2025 6:58 PM, Arne Vajh|+j wrote:
On 11/6/2025 6:35 PM, Chris Townley wrote:
On 06/11/2025 21:28, Arne Vajh|+j wrote:
Rust is not available for VMS.
Yet...
True.
But I do not expect it to become available any time soon.
Sure most OS and compiler people would love to see Rust on VMS.
I doubt most "OS and compiler people" have a clue what VMS
is or care what languages run on it.
I assure you you are wrong about the first part. Unfortunately
the second part is probably accurate.
It didn't help getting a new generation of folks interested in
alternatives to the dominant near-monoculture that the hobbyist
program went away. :-( I get that VSI had pragmatic reasons,
but is still a real shame.
- Dan C.
On 11/7/25 6:22 AM, Dan Cross wrote:
In article <mmvmu4F1c8iU1@mid.individual.net>,
John H. Reinhardt <johnhreinhardt@thereinhardts.org> wrote:
[snip] x86 can do FC but
that requires dedicating a HBA to each VM Guest. Hardly practical
unless you have a server with a lot of PCIe slots or very few OpenVMS
guests.
One presumes fiber channel HBAs are mostly PCIe devies at this
point; given that, what about using SR-IOV to mux guests onto a
single (or small set of) HBA(s)?
On ESXi V8 the Qlogic 2692 is listed as not capable of SR-IOV. I also
have 8G HBAs with the same status. I don't have any 32G HBAs to check.
But traditionally high availability is used to describe the ability to continue service in case a system goes down and not systems with low probability to go down.
Anyway the memory safety of Rust makes it clearly different from C/C++,
but if we look at languages typical used for business applications, then memory safety is common.
On Fri, 7 Nov 2025 15:01:23 -0500, Arne Vajh|+j wrote:
But traditionally high availability is used to describe the ability to
continue service in case a system goes down and not systems with low
probability to go down.
It helps if the system is designed not to go down so readily in the first place.
Remember the old saying: rCLan ounce of prevention is worth a pound of curerCY.
Anyway the memory safety of Rust makes it clearly different from C/C++,
but if we look at languages typical used for business applications, then
memory safety is common.
Do rCLbusiness applicationsrCY need to do network connections?
Using custom protocols, even?
On 11/8/2025 4:59 PM, Lawrence DrCOOliveiro wrote:
On Fri, 7 Nov 2025 15:01:23 -0500, Arne Vajh|+j wrote:
Anyway the memory safety of Rust makes it clearly different from
C/C++, but if we look at languages typical used for business
applications, then memory safety is common.
Do rCLbusiness applicationsrCY need to do network connections?
Absolutely.
Requests coming in over the network. Accessing database servers,
message queue servers, cache servers etc. during processing.
On Sat, 8 Nov 2025 17:14:33 -0500, Arne Vajh|+j wrote:
On 11/8/2025 4:59 PM, Lawrence DrCOOliveiro wrote:
On Fri, 7 Nov 2025 15:01:23 -0500, Arne Vajh|+j wrote:
Anyway the memory safety of Rust makes it clearly different from
C/C++, but if we look at languages typical used for business
applications, then memory safety is common.
Do rCLbusiness applicationsrCY need to do network connections?
Absolutely.
Requests coming in over the network. Accessing database servers,
message queue servers, cache servers etc. during processing.
Those are well-known sources of memory errors, buffer overflows,
security vulnerabilities caused by (accidentally or deliberately)
corrupted packets etc.
On 11/8/2025 6:09 PM, Lawrence DrCOOliveiro wrote:
On Sat, 8 Nov 2025 17:14:33 -0500, Arne Vajh|+j wrote:
On 11/8/2025 4:59 PM, Lawrence DrCOOliveiro wrote:
On Fri, 7 Nov 2025 15:01:23 -0500, Arne Vajh|+j wrote:
Anyway the memory safety of Rust makes it clearly different from
C/C++, but if we look at languages typical used for business
applications, then memory safety is common.
Do rCLbusiness applicationsrCY need to do network connections?
Absolutely.
Requests coming in over the network. Accessing database servers,
message queue servers, cache servers etc. during processing.
Those are well-known sources of memory errors, buffer overflows,
security vulnerabilities caused by (accidentally or deliberately)
corrupted packets etc.
Yes.
But I don't think you got the point.
Rewriting the business application from one
memory safe language (Java, C#, Python, Pascal
or whatever) to Rust does not help anything.
If the issue is at the application level, then
the old language already prevent buffer overflow
and if the issue is in some low level library,
then nothing changes by rewriting the application.
In article <10eok5t$2u3pu$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
Rewriting the business application from one
memory safe language (Java, C#, Python, Pascal
Given the `POINTER` type, consequent support for type-casting
pointers, and dynamic memory allocation, it's hard to understand
how VSI Pascal can be considered meaningfully memory safe in the
way that Rust or a managed language is.
I do not see a problem with the pointer type casts. If
normal code is safe, then I think it is OK to have ways
to workaround the safeness. Sometimes it is desirable
and it is hopefully easy to identify usage of such
constructs and require extra code review of such code.
On 11/12/2025 5:14 PM, Arne Vajh|+j wrote:
I do not see a problem with the pointer type casts. If
normal code is safe, then I think it is OK to have ways
to workaround the safeness. Sometimes it is desirable
and it is hopefully easy to identify usage of such
constructs and require extra code review of such code.
Illustration:
type
-a-a a4 = array [1..4] of integer;
-a-a pa4 = ^a4;
var
-a-a ap : pa4;
-a-a new(ap);
I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc. Not to mention FFI calls from safe
languages into unsafe code.
On 2025-11-12 13:04:23 +0000, Dan Cross said:
I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc.-a Not to mention FFI calls from safe
languages into unsafe code.
What *exactly* is memory unsafe using Macro?
You do realize that the
lion's share of VMS is Macro???
On 11/12/2025 5:14 PM, Arne Vajh|+j wrote:
I do not see a problem with the pointer type casts. If
normal code is safe, then I think it is OK to have ways
to workaround the safeness. Sometimes it is desirable
and it is hopefully easy to identify usage of such
constructs and require extra code review of such code.
Illustration:
On 11/12/2025 8:04 AM, Dan Cross wrote:
In article <10eok5t$2u3pu$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
Rewriting the business application from one
memory safe language (Java, C#, Python, Pascal
Given the `POINTER` type, consequent support for type-casting
pointers, and dynamic memory allocation, it's hard to understand
how VSI Pascal can be considered meaningfully memory safe in the
way that Rust or a managed language is.
The US government considers Pascal a memory safe language.
:-)
But I think you are right about it being a bit questionable.
I consider the 3 biggest memory unsafe problems to be:
* no out of bounds check for array index
* allowing use of deallocated memory
* memory leak due to memory never being deallocated
Pascal only prevents the first not the other two.
The other two are not as common in Pascal as in C,
because dynamic memory allocation is not as common in
Pascal as in C.
I did a quick check in my code repo and I use dynamic
memory allocation in 25% of my C pieces but only in
0.5% of my Pascal pieces. I am just one out of
millions so it is obviously anecdotal only, but pretty
big difference ...
Anyway 1 fixed + 2 not fixed but rare is not really
fixed.
So I think you are right and the US government is wrong.
:-)
I do not see a problem with the pointer type casts. If
normal code is safe, then I think it is OK to have ways
to workaround the safeness. Sometimes it is desirable
and it is hopefully easy to identify usage of such
constructs and require extra code review of such code.
On 2025-11-12 13:04:23 +0000, Dan Cross said:
I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc. Not to mention FFI calls from safe
languages into unsafe code.
What *exactly* is memory unsafe using Macro?
You do realize that the lion's share of VMS is Macro???
In article <10f30sp$1koun$4@dont-email.me>,
I consider the 3 biggest memory unsafe problems to be:
* no out of bounds check for array index
* allowing use of deallocated memory
* memory leak due to memory never being deallocated
Pascal only prevents the first not the other two.
The other two are not as common in Pascal as in C,
because dynamic memory allocation is not as common in
Pascal as in C.
Pascal is certainly an improvement over (at least) C and
assembler languages in this domain: as I recall, it doesn't
support arbitrary pointer arithmetic,
and arrays are properlyEither the dimension(s) is in the compile time declaration or
typed by including the array size in the type, and so on.
Delphi code:
program pasptr(input, output);
var
-a p : pchar;
-a hack1, hack2 : pchar;
begin
-a GetMem(p, 3);
-a p := 'ABC';
-a writeln(p[0]);
-a hack1 := p + 1;
-a writeln(hack1[0]);
-a hack2 := @p[0] + 2;
-a writeln(hack2[0]);
end.
That code is C in Pascal.
Anyway, it's a big design space in languages, and one must admit
that safety in this dimension exists along some spectrum; from
trivially dangerous (C, assembler) to safe-by-default (Rust, Ada
etc). Pascal is somewhere in the middle.
In article <10f30sp$1koun$4@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
The US government considers Pascal a memory safe language.
:-)
Have you seen the state of my government recently? :-(
Pascal only prevents the first not the other two.
The other two are not as common in Pascal as in C,
because dynamic memory allocation is not as common in
Pascal as in C.
Pascal is certainly an improvement over (at least) C and
assembler languages in this domain: as I recall, it doesn't
support arbitrary pointer arithmetic, and arrays are properly
typed by including the array size in the type, and so on.
On 2025-11-15, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <10f30sp$1koun$4@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
The US government considers Pascal a memory safe language.
:-)
Have you seen the state of my government recently? :-(
You have a government ???
I thought your people had elected a group of Feudal warlords who go
on raiding parties to other countries to force them to pay tribute
to your warlords to make up for the lack of investment in your country
or its people by previous US governments over the last 20+ years.
I also thought your Feudal warloads had a strategy of deliberately
humilating those leaders and their countries in order to force their >submission and to force them into paying tribute to your warlords.
Your Feudal warlords also have developed a habit of breaking international >agreements and alliances or just outright ignoring them.
I also really hope for your sakes that your feudal warlords don't
suddenly find themselves needing help from those other countries as
they are far less likely to place their citizens in harm's way like
they did after 9/11 in order to help your country.
Sorry Dan, but after seeing the latest set of events, you just set me off.
On 2025-11-15, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
[snip]
Pascal only prevents the first not the other two.
The other two are not as common in Pascal as in C,
because dynamic memory allocation is not as common in
Pascal as in C.
Pascal is certainly an improvement over (at least) C and
assembler languages in this domain: as I recall, it doesn't
support arbitrary pointer arithmetic, and arrays are properly
typed by including the array size in the type, and so on.
C and assembly language (Macro-32 in this case) are not at the
same level when it comes to safety.
Assembly language is much more dangerous than C because you can
create vulnerabilities with it that even a C compiler has a good
chance of stopping.
Bliss, the other VMS system implementation language, I would place
somewhere between Macro-32 and C in terms of safety.
On 2025-11-15, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <10f30sp$1koun$4@dont-email.me>,
Arne Vajh|a-+j <arne@vajhoej.dk> wrote:
The US government considers Pascal a memory safe language.
:-)
Have you seen the state of my government recently? :-(
You have a government ???
I thought your people had elected a group of Feudal warlords who go
on raiding parties to other countries to force them to pay tribute
to your warlords to make up for the lack of investment in your country
or its people by previous US governments over the last 20+ years.
I also thought your Feudal warloads had a strategy of deliberately
humilating those leaders and their countries in order to force their submission and to force them into paying tribute to your warlords.
Your Feudal warlords also have developed a habit of breaking international agreements and alliances or just outright ignoring them.
I also really hope for your sakes that your feudal warlords don't
suddenly find themselves needing help from those other countries as
they are far less likely to place their citizens in harm's way like
they did after 9/11 in order to help your country.
Simon.
On 2025-11-12 13:04:23 +0000, Dan Cross said:
I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc. Not to mention FFI calls from safe
languages into unsafe code.
What *exactly* is memory unsafe using Macro? You do realize that the lion's share of VMS is Macro???
rCo VAXman
On 11/12/2025 6:39 PM, Brian Schenkenberger wrote:
On 2025-11-12 13:04:23 +0000, Dan Cross said:
I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc. Not to mention FFI calls from safe
languages into unsafe code.
What *exactly* is memory unsafe using Macro? You do realize that the lion's >> share of VMS is Macro???
rCo VAXman
Well ....
From what I've read, Macro-32 is down to 33% or less these days, and shrinking.
I'm not really sure just what "memory unsafe" means. Nor is "idiot safe" something that can be enforced in any language.
Good code is relatively safe, but not always. I defy anyone to mention any language in which I cannot do something stupid. Might exist, but I can really
be very stupid.
On 11/12/2025 6:39 PM, Brian Schenkenberger wrote:
On 2025-11-12 13:04:23 +0000, Dan Cross said:
I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc. Not to mention FFI calls from safe
languages into unsafe code.
What *exactly* is memory unsafe using Macro? You do realize that the lion's >> share of VMS is Macro???
Well ....
From what I've read, Macro-32 is down to 33% or less these days, and shrinking.
I'm not really sure just what "memory unsafe" means.
Nor is "idiot safe"
something that can be enforced in any language.
Good code is relatively safe, but not always. I defy anyone to mention any >language in which I cannot do something stupid. Might exist, but I can really
be very stupid.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 54 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 17:44:12 |
| Calls: | 742 |
| Files: | 1,218 |
| D/L today: |
4 files (8,203K bytes) |
| Messages: | 184,414 |
| Posted today: | 1 |