Why Linux ?, was: Re: VMS article in The Register

[Simon Clubley]

On 2022-05-11, Dave Froble <da...@tsoft-inc.com> wrote:
>
> In many ways they are very unalike. More than just the terminology. Myself, I
> cannot understand why anyone would like to use Unix/Linux, but perhaps I'm
> prejudiced.
>

Why Linux over VMS ?

Far stronger security features than VMS as it currently exists.

A vast range of applications available, including being _the_ leading
platform for a range of applications these days.

An enormous pool of trained people to work with it.

Cheaper than VMS and with licencing that means you are not at the
mercy of a single supplier. If your current Linux vendor does something
you don't like, just switch to another vendor.

Why VMS over Linux ?

Legacy applications that are guaranteed to continue working as-is in
future versions of VMS.

Unique features such as VMS style clustering or VMS style HBVS (provided
you are rich enough to pay for them).

Simon.

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

[Bill Gunshannon]

On 5/12/22 09:08, Simon Clubley wrote:
> On 2022-05-11, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> In many ways they are very unalike. More than just the terminology. Myself, I
>> cannot understand why anyone would like to use Unix/Linux, but perhaps I'm
>> prejudiced.
>>
>
> Why Linux over VMS ?
>
> Far stronger security features than VMS as it currently exists.
>
> A vast range of applications available, including being _the_ leading
> platform for a range of applications these days.
>
> An enormous pool of trained people to work with it.
>
> Cheaper than VMS and with licencing that means you are not at the
> mercy of a single supplier. If your current Linux vendor does something
> you don't like, just switch to another vendor.
>
> Why VMS over Linux ?
>
> Legacy applications that are guaranteed to continue working as-is in
> future versions of VMS.

Fantasy world. I recently learned of an application that stopped
working after 5.4-5.5. Knowing the application I am sure the response
here would be who cares. But the fact is it did stop working.

>
> Unique features such as VMS style clustering or VMS style HBVS (provided
> you are rich enough to pay for them).

But the only thing that makes them unique is VMS. The functionality
exists elsewhere.

They obviously didn't stop people from leaving VMS.

VMS really needs something that is truly unique to keep customers
hanging on. Don't know what that should be but some companies
seem to have found it.

bill

[Jake Hamby]

On Thursday, May 12, 2022 at 7:41:38 AM UTC-7, Bill Gunshannon wrote:
> On 5/12/22 09:08, Simon Clubley wrote:
> > Why VMS over Linux ?
> >
> > Legacy applications that are guaranteed to continue working as-is in
> > future versions of VMS.
> Fantasy world. I recently learned of an application that stopped
> working after 5.4-5.5. Knowing the application I am sure the response
> here would be who cares. But the fact is it did stop working.

VMS definitely doesn't have as good of a track record as z/OS, where they've stayed binary backwards compatible to assembly language written in the mid-1960s. They have products like a COBOL optimizer that can take customers' code that was compiled with some older version of the compiler, to which they may no longer have the source code (or it's on punch cards or 9-track tapes or something), and generate optimized machine code that uses the newer features of their CPUs, like decimal floating point SIMD. Each new CPU has optimizations specifically for COBOL customers (as well as Java and other newer languages).

VMS 5.4-5.5 was 30 years ago. I'd be more interested in hearing stories about VMS's binary compatibility track record back to, say, V7.2 (Jan. 1999). Have they broken any code that was working in the past 20+ years?

There's a problem for VMS's story as an enterprise system when you compare it to IBM mainframes, because the transition from VAX to Alpha to I64 to x86-64 essentially requires customers to recompile, but if their code was written to use pre-ANSI C, or some other older flavor of a language that the current generation of compilers no longer accept, regardless of "relaxed" settings, then they're in trouble. The same if they have code that was written in one of the now-unsupported languages, like PL/I and DEC Ada.

> > Unique features such as VMS style clustering or VMS style HBVS (provided
> > you are rich enough to pay for them).
> But the only thing that makes them unique is VMS. The functionality
> exists elsewhere.
>
> They obviously didn't stop people from leaving VMS.
>
> VMS really needs something that is truly unique to keep customers
> hanging on. Don't know what that should be but some companies
> seem to have found it.

My sales pitch for VMS is that the architecture is well-suited for server applications today because async I/O is now very fashionable (Node.js, C#, Rust, any language with lambdas), and $QIO is the core of OpenVMS (and Windows NT as well, since they copied the idea). If you're used to the UNIX world, then VMS is going to be alien and you won't see at first what benefits it could provide, but if you're thinking in terms of a stack like Node.js or Erlang or some of the open source that VSI is porting to VMS, then it could potentially be efficient, if the drivers are, because the core OS is very lean (designed for a slow VAX).

I think there's potential for winning customers away from Windows servers more than Linux servers, and potentially even stealing mainframe customers from IBM, but that's only if VSI can afford to upgrade the COBOL compiler to support UTF-8 instead of just ASCII, ISO Latin-1, and EBCDIC (the only VMS language that does support EBCDIC). IBM has object-oriented COBOL support that's integrated with their JVM so COBOL objects can inherit from and call Java objects and vice versa, with the COBOL compiler automatically generating the necessary JNI code.

There seem to be quite a number of consultants specializing in helping customers to "lift and shift" their code onto cloud Linux systems, and if someone were to build a consulting practice on migrating customers who really care about ISAM records, batch queues, or other mainframe-esque services that VMS happens to provide and Linux doesn't, they might get at least a few takers. Having to buy in to a now-retired architecture was always going to be a severe limiting factor on VMS, and now that it'll be running on the commodity 64-bit servers that Itanium tried and failed to become, the OS will only be limited by the value proposition and cost to customers vs. replicating whatever services VMS provides in Linux for their custom code.

Who knows: perhaps IBM® COBOL for Linux® on x86 will even become available for OpenVMS® on x86, if enough people ask for it. IBM and DEC used to be fierce rivals, but I don't see why IBM would be scared of a small company like VSI rather than at least considering the potential for synergy between VMS and z/OS as far as interoperability, since they don't run on the same hardware platforms.

The one strategy that probably isn't going to work for VSI would be attempting to position themselves as something like a "better Linux than Linux", especially since the CRTL still doesn't have a real fork(). But if they borrow a few pages from how IBM has been positioning z/OS to customers (hybrid cloud, porting Go and Python, promoting Java and Docker containers), I think there are some interesting opportunities for VMS (or else I wouldn't be reading this newsgroup).

Jake

[Arne Vajhøj]

On 5/13/2022 10:15 PM, Jake Hamby wrote:
> VMS definitely doesn't have as good of a track record as z/OS, where
> they've stayed binary backwards compatible to assembly language
> written in the mid-1960s. They have products like a COBOL optimizer
> that can take customers' code that was compiled with some older
> version of the compiler, to which they may no longer have the source
> code (or it's on punch cards or 9-track tapes or something), and
> generate optimized machine code that uses the newer features of their
> CPUs, like decimal floating point SIMD. Each new CPU has
> optimizations specifically for COBOL customers (as well as Java and
> other newer languages).
>
> VMS 5.4-5.5 was 30 years ago. I'd be more interested in hearing
> stories about VMS's binary compatibility track record back to, say,
> V7.2 (Jan. 1999). Have they broken any code that was working in the
> past 20+ years?
>
> There's a problem for VMS's story as an enterprise system when you
> compare it to IBM mainframes, because the transition from VAX to
> Alpha to I64 to x86-64 essentially requires customers to recompile,
> but if their code was written to use pre-ANSI C, or some other older
> flavor of a language that the current generation of compilers no
> longer accept, regardless of "relaxed" settings, then they're in
> trouble. The same if they have code that was written in one of the
> now-unsupported languages, like PL/I and DEC Ada.

VMS did have VEST and AEST.

I don't think people liked them.

> My sales pitch for VMS is that the architecture is well-suited for
> server applications today because async I/O is now very fashionable
> (Node.js, C#, Rust, any language with lambdas), and $QIO is the core
> of OpenVMS (and Windows NT as well, since they copied the idea). If
> you're used to the UNIX world, then VMS is going to be alien and you
> won't see at first what benefits it could provide, but if you're
> thinking in terms of a stack like Node.js or Erlang or some of the
> open source that VSI is porting to VMS, then it could potentially be
> efficient, if the drivers are, because the core OS is very lean
> (designed for a slow VAX).

Linux got aio, epoll, libevent etc..

Maybe it is more of a bolt-on than native, but it is there
and that is what matters.

I would try and sell VMS as being lean. Linux is getting fat.

> I think there's potential for winning customers away from Windows
> servers more than Linux servers, and potentially even stealing
> mainframe customers from IBM, but that's only if VSI can afford to
> upgrade the COBOL compiler to support UTF-8 instead of just ASCII,
> ISO Latin-1, and EBCDIC (the only VMS language that does support
> EBCDIC).

Java supports EBCDIC.

:-)

> IBM has object-oriented COBOL support that's integrated with
> their JVM so COBOL objects can inherit from and call Java objects and
> vice versa, with the COBOL compiler automatically generating the
> necessary JNI code.

A mix of managed and un-managed code do have some potential
problems.

I would not recommend such an approach. But that does obviously
not prevent it from being used.

> There seem to be quite a number of consultants specializing in
> helping customers to "lift and shift" their code onto cloud Linux
> systems, and if someone were to build a consulting practice on
> migrating customers who really care about ISAM records, batch queues,
> or other mainframe-esque services that VMS happens to provide and
> Linux doesn't, they might get at least a few takers. Having to buy in
> to a now-retired architecture was always going to be a severe
> limiting factor on VMS, and now that it'll be running on the
> commodity 64-bit servers that Itanium tried and failed to become, the
> OS will only be limited by the value proposition and cost to
> customers vs. replicating whatever services VMS provides in Linux for
> their custom code.

Could be worth a try.

Arne

[Paul Hardy]

Arne Vajhøj <ar...@vajhoej.dk> wrote:
> VMS did have VEST and AEST.
> I don't think people liked them.

Oh we did. VEST was an amazing facility, and let us extend the life of a
particular software suite by decades.

—
Paul Hardy

[Arne Vajhøj]

OK. Some liked them.

BTW, I have not heard about an IEST - is that because such does not exist?

Arne

[Jan-Erik Söderholm]

If that refers to a IA64 to x86-64 binary translator, then I
think that VSI has said that such tool will not be available.
Or even exist at all, I guess.

[Arne Vajhøj]

On 5/16/2022 10:38 AM, Jan-Erik Söderholm wrote:
> Den 2022-05-16 kl. 14:43, skrev Arne Vajhøj:
>> On 5/16/2022 3:12 AM, Paul Hardy wrote:
>>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> VMS did have VEST and AEST.
>>>> I don't think people liked them.
>>>
>>> Oh we did. VEST was an amazing facility, and let us extend the life of a
>>> particular software suite by decades.
>>
>> OK. Some liked them.
>>
>> BTW, I have not heard about an IEST - is that because such does not
>> exist?
>

> If that refers to a IA64 to x86-64 binary translator, then I
> think that VSI has said that such tool will not be available.
> Or even exist at all, I guess.

Yes.

VEST : VAX -> Alpha
AEST : Alpha -> Itanium

if Itanium -> x86-64 existed then I assume it would have been called IEST.

But I am not super surprised that it doesn't exist.

Arne

[Simon Clubley]

On 2022-05-13, Jake Hamby <jake....@gmail.com> wrote:
>
> There's a problem for VMS's story as an enterprise system when you compare it to IBM mainframes, because the transition from VAX to Alpha to I64 to x86-64 essentially requires customers to recompile, but if their code was written to use pre-ANSI C, or some other older flavor of a language that the current generation of compilers no longer accept, regardless of "relaxed" settings, then they're in trouble. The same if they have code that was written in one of the now-unsupported languages, like PL/I and DEC Ada.
>

I'm not sure, but isn't VSI continuing to support /standard=vaxc on the
GEM-based C compiler (not the native LLVM clang compiler) for x86-64 ?

[Simon Clubley]

On 2022-05-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 5/13/2022 10:15 PM, Jake Hamby wrote:
>> IBM has object-oriented COBOL support that's integrated with
>> their JVM so COBOL objects can inherit from and call Java objects and
>> vice versa, with the COBOL compiler automatically generating the
>> necessary JNI code.
>
> A mix of managed and un-managed code do have some potential
> problems.
>
> I would not recommend such an approach. But that does obviously
> not prevent it from being used.
>

The main problem with JNI is when you have to write the code manually
when interfacing Java with C because it's way too easy to make mistakes.

If the COBOL compiler is automatically generating the JNI interface code
at both ends, then that would seem to eliminate that problem...

[John Reagan]

It is just another setting in the C frontend, so yes, it is there on x86. However, it hides SOOOO MANY
errors and bad programming that I strongly suggest people stop using it everywhere.

[Simon Clubley]

_NO_ argument from me on that one. :-)

You are talking to the person who enables all warnings and likes
to turn warnings into errors using the appropriate options if possible. :-)

[Arne Vajhøj]

On 5/16/2022 2:14 PM, Simon Clubley wrote:
> On 2022-05-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 5/13/2022 10:15 PM, Jake Hamby wrote:
>>> IBM has object-oriented COBOL support that's integrated with
>>> their JVM so COBOL objects can inherit from and call Java objects and
>>> vice versa, with the COBOL compiler automatically generating the
>>> necessary JNI code.
>>
>> A mix of managed and un-managed code do have some potential
>> problems.
>>
>> I would not recommend such an approach. But that does obviously
>> not prevent it from being used.
>>
>
> The main problem with JNI is when you have to write the code manually
> when interfacing Java with C because it's way too easy to make mistakes.
>
> If the COBOL compiler is automatically generating the JNI interface code
> at both ends, then that would seem to eliminate that problem...

With JNI the glue is done in C and it is easy to make mistakes in C.
Doing the glue in C may have made sense in the mid 90's but no longer.
And the new foreign function mechanism (that will hopefully be
final in Java 20 or 21) has moved the glue to the Java side
more like Python ctypes.

Autogenerating all code obviously avoid manual glue entirely.

But my comment was not just related to the cumbersome API.
There are other problems.

Including:
* large overhead due to copying of data
* risk of unmanaged code trashing data over on
the managed side
* memory allocation conflicts (like if one of the sides
expects continuous heap space)

Arne

[Stephen Hoffman]

On 2022-05-16 18:22:55 +0000, John Reagan said:

> It is just another setting in the C frontend, so yes, it is there on
> x86. However, it hides SOOOO MANY errors and bad programming that I
> strongly suggest people stop using it everywhere.

If working with or updating old K&R C code, simply finding that
compiler switch usually means added work remediating the issues
reported by newer C compilers and newer C standards.

If that remediation work doesn't happen, the new work inherently "owns"
the existing and quite possibly unstable K&R C code.

Proving who "owns" a latent K&R C bug is non-trivial.

Fix the latent errors now, or troubleshoot in acceptance testing and
production and find and fix a subset of the bugs later.

Code refactoring and remediation is an ongoing and necessary project in
all non-trivial code-bases, and finding K&R C code means it's been a
while.




--
Pure Personal Opinion | HoffmanLabs LLC

[Arne Vajhøj]

On 5/16/2022 3:27 PM, Stephen Hoffman wrote:
> On 2022-05-16 18:22:55 +0000, John Reagan said:
>> It is just another setting in the C frontend, so yes, it is there on
>> x86.  However, it hides SOOOO MANY errors and bad programming that I
>> strongly suggest people stop using it everywhere.
>
> If working with or updating old K&R C code, simply finding that compiler
> switch usually means added work remediating the issues reported by newer
> C compilers and newer C standards.

> Fix the latent errors now, or troubleshoot in acceptance testing and
> production and find and fix a subset of the bugs later.
>
> Code refactoring and remediation is an ongoing and necessary project in
> all non-trivial code-bases, and finding K&R C code means it's been a while.

I agree with the advice to get rid of any code requiring /STANDARD=VAXC.

But I think those with the problem should consider whether
rewriting to standard C99 is the right choice or maybe go
for another language.

If it is a device driver or similar then sure C is obvious.
But if it is a piece of business logic, then why should it
stay in C.

Back in the mid-late 80's there were not that many
common alternatives and it was a period when some
people thought that C would take over the world and
everything should be written in C.

Since then the number of languages has increased. And
many have realized that C is good for some things but
not good for a lot of other things.

Maybe going C++ and a higher abstraction
level would make sense.

Maybe going a lot higher and go for Java or
Python make sense.

Maybe sticking to traditional procedural
but switching to Pascal or Basic make sense.

Arne

[Stephen Hoffman]

On 2022-05-16 19:49:45 +0000, Arne Vajh j said:

> But I think those with the problem should consider whether rewriting to
> standard C99 is the right choice or maybe go for another language.

If willing to and funded to rewrite rather than to refactor into C99,
or into C11, or (probably, nowadays) into C17 with an eye toward C2x,
sure, the implementation choices do expand. Both the choices of
language, and the platform.

Absent an incremental rewrite, the costs and the rates of project
failure both increase, too.

I do know various OpenVMS sites that have incrementally re-written
their apps off of OpenVMS. Some to Windows. Some to Linux. So this
incremental approach can and does work.

Outside of a trivial-sized project, or a planned platform port, a
rewrite is usually out of scope. Not always. But usually.

For refactoring straight C code, the code-refactoring tools I'm
presently working with do work very well. Surprisingly so.

For automated porting, source code translation tools are available, but
I'd want some evidence around code maintenance for the resulting
translated code. I've had some bad experiences, here. Plus there are
other areas—such as data security—that a straight translation might not
account for, as the existing C code doesn't account for it.

Translating into C++ is certainly an option and particularly to a
selected subset of C++ (e.g.
https://github.com/google/styleguide/tree/gh-pages/cpplint or
analogous), but—absent specific or extenuating circumstances—C++
wouldn't usually be my preferred target for a wholesale rewrite from C.
As somebody once commented on C++, “Within C++, there is a much smaller
and cleaner language struggling to get out.” And as somebody else
commented, “good C++ code is better than good C code, but bad C++ can
be much, much worse than bad C code”.

[Stephen Hoffman]

On 2022-05-16 21:43:35 +0000, Stephen Hoffman said:

> Translating into C++ is certainly an option and particularly to a
> selected subset of C++ (e.g.
> https://github.com/google/styleguide/tree/gh-pages/cpplint or
> analogous), but—absent specific or extenuating circumstances—C++
> wouldn't usually be my preferred target for a wholesale rewrite from C.
> As somebody once commented on C++, “Within C++, there is a much smaller
> and cleaner language struggling to get out.” And as somebody else
> commented, “good C++ code is better than good C code, but bad C++ can
> be much, much worse than bad C code”.

ps: String handling is vastly better in C++ than in C. And any
reasonable C refactor would necessarily want to look at data security
and related.

[chris]

But most important of all, that sort of code refactoring needs
people fluent in both the original and substitute languages.
Since C is the most widely used language. might make sense to
stick with it.

Recipe for disaster to choose a substitute language which
has a small available pool of programmers. Increases costs
and risk of serious bugs...

Chris

[Simon Clubley]

On 2022-05-16, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> ps: String handling is vastly better in C++ than in C. And any
> reasonable C refactor would necessarily want to look at data security
> and related.
>

True, but unfortunately that's somewhat compromised by the fact the
default indexing operator in C++ is not bounds checked.

It would have been better if [] was the bounds checked operator and
.at() was the non-bounds checked alternative.

That way, you would have had to do something non-standard in your C++
code to turn off bounds checking instead of having to do something
non-standard to turn it on.

[Arne Vajhøj]

> But most important of all, that sort of code refactoring needs
> people fluent in both the original and substitute languages.

They need people able to read C and people able to write
in the new language.

> Since C is the most widely used language. might make sense to
> stick with it.
>
> Recipe for disaster to choose a substitute language which
> has a small available pool of programmers. Increases costs
> and risk of serious bugs...

That could be a problem with Pascal and Basic.

But you will find more Java and Python programmers than
C programmers today.

And probably around the same number of C++ programmers
as C programmers.

And C is not really suited for the typical business
application - it was not created for such usage - and
it shows.

Arne

[Arne Vajhøj]

On 5/17/2022 8:49 AM, Simon Clubley wrote:
> On 2022-05-16, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>> ps: String handling is vastly better in C++ than in C. And any
>> reasonable C refactor would necessarily want to look at data security
>> and related.
>
> True, but unfortunately that's somewhat compromised by the fact the
> default indexing operator in C++ is not bounds checked.
>
> It would have been better if [] was the bounds checked operator and
> .at() was the non-bounds checked alternative.
>
> That way, you would have had to do something non-standard in your C++
> code to turn off bounds checking instead of having to do something
> non-standard to turn it on.

I do not disagree with that.

But even with this issue are STL string/wstring way better than
char[] and wchar_t[].

Arne

[chris]

But are they software engineers ?. Different requirements
apply, for example apps programming, web programming
and embedded real time.

>
> And probably around the same number of C++ programmers
> as C programmers.
>
> And C is not really suited for the typical business
> application - it was not created for such usage - and
> it shows.
>
> Arne
>

No argument about that, but no doubt many business apps have
been written in C in the past. C is still arguably the best
systems programming language, despite fashions of the moment...

Chris

[Arne Vajhøj]

On 5/17/2022 6:54 PM, chris wrote:
> On 05/17/22 21:33, Arne Vajhøj wrote:
>> On 5/17/2022 7:16 AM, chris wrote:
>>> Since C is the most widely used language. might make sense to
>>> stick with it.
>>  >
>>> Recipe for disaster to choose a substitute language which
>>> has a small available pool of programmers. Increases costs
>>> and risk of serious bugs...
>>
>> That could be a problem with Pascal and Basic.
>>
>> But you will find more Java and Python programmers than
>> C programmers today
>
> But are they software engineers ?.

Java and C++ programmers should have the same or maybe even
higher percentage of sofware engineers as C programmers.

Python probably a bit smaller due to the admin scripters
and the data scientists.

> Different requirements
> apply, for example apps programming, web programming
> and embedded real time.

Yes.

But somewhere above - long dropped from quote - I was talking about
business applications.

>> And probably around the same number of C++ programmers
>> as C programmers.
>>
>> And C is not really suited for the typical business
>> application - it was not created for such usage - and
>> it shows.
>

> No argument about that, but no doubt many business apps have
> been written in C in the past. C is still arguably the best
> systems programming language, despite fashions of the moment...

C is definitely still king in this area.

And going C for that is a safe choice.

Rust, Go, Hare, Zig etc. are just "promising" but not
"proven".

Arne

[Bill Gunshannon]

Might work. Until the first time you have to run a benchmark.


bill

[Bill Gunshannon]

On 5/16/22 15:27, Stephen Hoffman wrote:
>
>
> If that remediation work doesn't happen, the new work inherently "owns"
> the existing and quite possibly unstable K&R C code.
>

What makes the code inherently unstable just because it is K&R
as opposed to the crap being written in the more modern languages?

bill

[Bill Gunshannon]

Thank you. You beat me to it and said it more eloquently than I
would have.

bill

[Bill Gunshannon]

Sorry, based on what I saw in a place with a Masters Degree Program
in SE I would take a good old fashioned Programmer/Analyst over a
Software engineer any day.

>
>>
>> And probably around the same number of C++ programmers
>> as C programmers.
>>
>> And C is not really suited for the typical business
>> application - it was not created for such usage - and
>> it shows.
>>
>> Arne
>>
>
> No argument about that, but no doubt many business apps have
> been written in C in the past. C is still arguably the best
> systems programming language, despite fashions of the moment...

Actually, there is another one that was ideal but never found its
way into common usage or even off of one processor. PL/M.

bill

[Bill Gunshannon]

On 5/17/22 19:32, Arne Vajhøj wrote:
> On 5/17/2022 6:54 PM, chris wrote:
>> On 05/17/22 21:33, Arne Vajhøj wrote:
>>> On 5/17/2022 7:16 AM, chris wrote:
>>>> Since C is the most widely used language. might make sense to
>>>> stick with it.
>>>  >
>>>> Recipe for disaster to choose a substitute language which
>>>> has a small available pool of programmers. Increases costs
>>>> and risk of serious bugs...
>>>
>>> That could be a problem with Pascal and Basic.
>>>
>>> But you will find more Java and Python programmers than
>>> C programmers today
>>
>> But are they software engineers ?.
>
> Java and C++ programmers should have the same or maybe even
> higher percentage of sofware engineers as C programmers.
>
> Python probably a bit smaller due to the admin scripters
> and the data scientists.
>
>>                                     Different requirements
>> apply, for example apps programming, web programming
>> and embedded real time.
>
> Yes.
>
> But somewhere above - long dropped from quote - I was talking about
> business applications.

All the more reason I would shun Software Engineers in favor of
old fashioned Programmer/Analysts.

>
>>> And probably around the same number of C++ programmers
>>> as C programmers.
>>>
>>> And C is not really suited for the typical business
>>> application - it was not created for such usage - and
>>> it shows.
>>
>> No argument about that, but no doubt many business apps have
>> been written in C in the past. C is still arguably the best
>> systems programming language, despite fashions of the moment...
>
> C is definitely still king in this area.
>
> And going C for that is a safe choice.
>
> Rust, Go, Hare, Zig etc. are just "promising" but not
> "proven".

Promising what? Aren't they just solutions searching for a problem?
Or new ego trips.

bill

[Simon Clubley]

Because of what the compilers let you get away with back then and
also didn't even bother to warn you about so you could realise there
was a problem and fix it.

These days, you get a lot more compiler errors and warnings and
code is better for it.

Have you forgotten about VAX C and what an improvement DEC C was ? :-)

Have you forgotten how bad your code is if you need to use /standard=vaxc
to compile it ? :-)

As John has just confirmed, that qualifier is still going to be
available for the GEM-based C compiler for x86-64...

[Stephen Hoffman]

Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.

K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
adding code bugs, and that compilation usually also with YOLO-grade
diagnostics settings.

Clang building with C18 / C2X with diagnostics lit (clang -Wall, maybe
also with -Wextra) produces more reliable code.

VSI C with /STANDARD=C99 /WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT,
QUESTCODE, ...), DISABLE=(...)) does well at finding trouble. Adding
VERBOSE and OVERFLOW can be useful, too.

There can be good VAX C code. It's just... very rarely encountered. If
OpenVMS C code is now compiling with /STANDARD=VAXC, then somebody
noticed the C diagnostics, and decided to ignore them.

[Bill Gunshannon]

On 5/19/22 14:10, Simon Clubley wrote:
> On 2022-05-19, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>
>>>
>>> If that remediation work doesn't happen, the new work inherently "owns"
>>> the existing and quite possibly unstable K&R C code.
>>>
>>
>> What makes the code inherently unstable just because it is K&R
>> as opposed to the crap being written in the more modern languages?
>>
>
> Because of what the compilers let you get away with back then and
> also didn't even bother to warn you about so you could realise there
> was a problem and fix it.

Are we talking compilers or language? No one is using PCC any more.

>
> These days, you get a lot more compiler errors and warnings and
> code is better for it.

And a modern compiler could not generate those warning for K&R?
Note, I said "could not" not doesn't.

>
> Have you forgotten about VAX C and what an improvement DEC C was ? :-)

And what does that have to do with the language? That's a compiler
issue.

>
> Have you forgotten how bad your code is if you need to use /standard=vaxc
> to compile it ? :-)

My code isn't bad. No matter what compiler I use or what compiler
options I choose. I don't rely on compilers to write my code.

>
> As John has just confirmed, that qualifier is still going to be
> available for the GEM-based C compiler for x86-64...

So? Do they deliberately allow bad code without even a warning
because "It's K&R"?

bill

[Bill Gunshannon]

But that's a compiler (or programmer) problem and has nothing to
do with K&R beyond the age of the language definition. A lot was
left out in the bygone era because of the limits on resources.
There is no reason, today, why th compiler can't point out the
bad ideas that programmers do that don't violate the K&R definition
but are just bad ideas. Do I need to point out the Safe C Compiler
again?

bill

[Stephen Hoffman]

You're one of the most adorable folks here. That you continue to
contribute your wealth of knowledge and insight and experience is a
gift to all of us. And by all means, please do scope your projects and
price your project work however you want.

[Dave Froble]

My, Bill is kind of feisty these days. Wonder what they gave him in that
hospital? Have to get me some of that ...

:-)

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

[Jake Hamby]

On Thursday, May 19, 2022 at 12:11:43 PM UTC-7, Stephen Hoffman wrote:
> > What makes the code inherently unstable just because it is K&R as
> > opposed to the crap being written in the more modern languages?
> Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.
>
> K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
> adding code bugs, and that compilation usually also with YOLO-grade
> diagnostics settings.
>
> Clang building with C18 / C2X with diagnostics lit (clang -Wall, maybe
> also with -Wextra) produces more reliable code.
>
> VSI C with /STANDARD=C99 /WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT,
> QUESTCODE, ...), DISABLE=(...)) does well at finding trouble. Adding
> VERBOSE and OVERFLOW can be useful, too.

I completely agree with everything you said, and thanks for the suggestion of useful warnings to enable.

I've been working on reviving the OpenVMS port of Regina (Rexx interpreter), which has been great fun (I have a strange sense of fun) and very educational. Before I could begin to tackle the VMS-specific wrapper functions (the previous author implemented nearly all of the DCL lexical functions as native Rexx functions, which I spent nearly a week modernizing), I had to fix compiler warnings produced by DEC C at the default warning level. Mismatched types (signed/unsigned, pointer types). Turning on the warnings you suggested has exposed a whole new set of questionable things to fix.

Apparently, few people are compiling Regina with the debug assertions enabled and running the test scripts that it comes with, because I spent some time worrying about an assertion failure in Regina's internal memory allocator, only to discover, fortunately, that it was a bug in their implementation of UPPER() and LOWER() that wasn't allocating a big enough string when the output string was longer than the input. Nothing at all VMS-specific about that bug, and I really have had no complaints about DEC C/C++ in terms of the compiler crashing with internal errors or generating bad code or anything like that with open source programs I've compiled.

> There can be good VAX C code. It's just... very rarely encountered. If
> OpenVMS C code is now compiling with /STANDARD=VAXC, then somebody
> noticed the C diagnostics, and decided to ignore them.

Fortunately, I haven't run into that particular issue!

-Jake

[Jake Hamby]

That's a mean thing to say, but it's a big open question (at least for me, since I don't have access to the x86 version): how well does VMS actually perform on modern x86-64 hardware?

I don't think VSI did themselves any favors by demoing VMS booting up on a 9600 bps serial console or whatever speed they were using in VirtualBox. BTW, I've ported some simple IPC benchmarks from Linux to find out for myself how well it performs on vintage hardware:

https://github.com/jhamby/vms-ipc_benchmark/

For comparison, running "pipe" and "tcp" with 8K message size, I can easily get 6,500 MB/s, or 835,000 msg/s on an Intel Xeon W-1290P CPU @ 3.70GHz (turbo to 5.2 GHz) running Ubuntu 22.04 (kernel 5.15.0).

On a dual 1.6 GHz / 3MB ("Fanwood") HP rx2620, the best I can get is around 160MB/s, or 1/40 of the speed of the new PC. On my 667 MHz EV67 XP1000, I get about 65MB/s, or 1%. That hardware is from 2005 and 2002, respectively. The Alpha hits a limit of around 20,000 msg/s that's a bottleneck as I shrink the packet size to 4K and below, while the Itanium handles smaller writes without much issue.

My biggest battle with tuning VMS was discovering that my BIOLM shouldn't be 10000 or higher, because then the writer seems to get congested and the CPU starts to idle and performance fluctuates. With a BIOLM of between 400 and 600, the sustained local pipe/socketpair/TCP/UDP performance (using MultiNet) are the numbers I reported.

You'll also notice if you check the source code that I'm linking in the vms_crtl_init.c and vms_crtl_values.c from the VSI Python 3.10 port, which set the behavior of pipe() to be as UNIX-like as possible. Without that, the speed would be hovering around 14MB/s on the Itanium. Completely unacceptable.

As I said, it's a big open question for me as to whether or not VMS actually *is* lean, because the hardware I have available to me as a hobbyist is so old.

Cheers,
Jake

[John Dallman]

In article <5e165e6b-c0c6-4dab...@googlegroups.com>,

jake....@gmail.com (Jake Hamby) wrote:

> That's a mean thing to say, but it's a big open question (at least
> for me, since I don't have access to the x86 version): how well
> does VMS actually perform on modern x86-64 hardware?

In the late 1990s, when I was new there, my employers were testing the
same software regularly on three different Alpha platforms: 32-bit VMS,
32-bit Windows NT, and 64-bit OSF/1 UNIX. As best I remember, the OSF was
fastest, with Windows and VMS being approximately similar.

Of course, the hardware has changed a lot since then.

John

[Arne Vajhøj]

Nobody pick OS based on benchmarks today.

Speed is not the issue. Software bugs and vulnerabilities are
the issue. More code means higher risk.

Arne

[Arne Vajhøj]

Many things are possible.

But are there any really good checking K&R compilers
available?

If not then the fact that one could be written is not
that useful.

Arne

[Bill Gunshannon]

Trust me, no you don't. The only good news I got was that I
don't have COVID. Went in for knee surgery. Got to the OR.
Everybody jumped up and yelled "April Fool". Got a free ride
to the ER and 3 fun filled days in the hospital. Not a fun week.

bill

[Arne Vajhøj]

They all try to address some known problems in old languages.
The problems are identified and they fix them.

But that does not guarantee that they overall are better
than the old languages.

And in case there are multiple that are better it is
still open which one of the new languages is best.

Arne

[Bill Gunshannon]

Yes, there was. I have mentioned it here numerous times. It
was called Safe C and was available on both the PDP-11 and VAX.
And, apparently, the industry resoundingly rejected it.

>
> If not then the fact that one could be written is not
> that useful.

Why is that? GCC was written from scratch. It was not a rehash
of PCC. They could have put anything they wanted into it. It
would seem they chose to put nothing new in it at all.

bill

[Arne Vajhøj]

On 5/19/2022 9:31 PM, Bill Gunshannon wrote:
> On 5/19/22 21:12, Arne Vajhøj wrote:
>> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>>> But that's a compiler (or programmer) problem and has nothing to
>>> do with K&R beyond the age of the language definition.  A lot was
>>> left out in the bygone era because of the limits on resources.
>>> There is no reason, today, why th compiler can't point out the
>>> bad ideas that programmers do that don't violate the K&R definition
>>> but are just bad ideas. Do I need to point out the Safe C Compiler
>>> again?
>>
>> Many things are possible.
>>
>> But are there any really good checking K&R compilers
>> available?
>
> Yes, there was.  I have mentioned it here numerous times.  It
> was called Safe C and was available on both the PDP-11 and VAX.
> And, apparently, the industry resoundingly rejected it.

So there was something available 30-40 years ago.

That does not help anyone today.

>> If not then the fact that one could be written is not
>> that useful.
>
> Why is that?

Because those people with C code want to build their
C code - they do not want to write their own compiler.
They have to use the C compilers that are actual available
for the platforms of today.

Arne

[Craig A. Berry]

On 5/19/22 4:40 PM, Jake Hamby wrote:
> On Thursday, May 19, 2022 at 10:50:44 AM UTC-7, Bill Gunshannon wrote:
>> On 5/15/22 19:46, Arne Vajhøj wrote:

>>> I would try and sell VMS as being lean. Linux is getting fat.
>> Might work. Until the first time you have to run a benchmark.

> That's a mean thing to say, but it's a big open question (at least
> for me, since I don't have access to the x86 version): how well does VMS
> actually perform on modern x86-64 hardware?

It's going to remain an open question for some time. As far as I know,
none of the cross compilers has optimizations turned on, which means
there is no optimized code in the OS or libraries shipped with the OS,
much less in anything you build yourself.

Once the optimizations are available, you'll run into the inherently
slow file I/O and network I/O that have been discussed many times here.
The current roadmap does not include either of the new filesystems that
have been planned and set aside, nor the networking overhaul (VCI 2.0).
One can hope these will come back one day once the port to x86 is done.

I would not expect VMS to be competitive in raw speed with other OSs on
the same hardware anytime soon, but it really just needs to be a bit
faster on virtual x86 than it was on the last generation of Integrity
hardware for it to be a big step forward. Reducing cost and risk are
going to be a lot more important to most people in the near term than
increasing speed.

> I've ported some simple IPC benchmarks from Linux to
> find out for myself how well it performs on vintage hardware:
>
> https://github.com/jhamby/vms-ipc_benchmark/
>
> For comparison, running "pipe" and "tcp" with 8K message size, I can
> easily get 6,500 MB/s, or 835,000 msg/s on an Intel Xeon W-1290P CPU @
> 3.70GHz (turbo to 5.2 GHz) running Ubuntu 22.04 (kernel 5.15.0).
>
> On a dual 1.6 GHz / 3MB ("Fanwood") HP rx2620, the best I can get is
> around 160MB/s, or 1/40 of the speed of the new PC. On my 667 MHz EV67
> XP1000, I get about 65MB/s, or 1%. That hardware is from 2005 and 2002,
> respectively. The Alpha hits a limit of around 20,000 msg/s that's a
> bottleneck as I shrink the packet size to 4K and below, while the
> Itanium handles smaller writes without much issue.

> You'll also notice if you check the source code that I'm linking in
> the vms_crtl_init.c and vms_crtl_values.c from the VSI Python 3.10 port,
> which set the behavior of pipe() to be as UNIX-like as possible. Without
> that, the speed would be hovering around 14MB/s on the Itanium.
> Completely unacceptable.

pipe() on VMS is based on mailboxes, an ancient virtual device
technology that is convenient to use and quite effective for passing
small messages around between processes. But it's slow, and it's a
record-oriented device, which doesn't always play nice in a
stream-oriented world (though stream-oriented behavior is emulated to
some extent). For a faster pipe implementation see dmpipe, which uses
global sections:

https://sourceforge.net/p/vms-ports/dmpipe

Unfortunately this involves wrapping pretty much every function in the
CRTL that touches a file descriptor -- the fix should really be inside
the CRTL, but, alas, that also is not on the roadmap.

[Bill Gunshannon]

On 5/19/22 21:36, Arne Vajhøj wrote:
> On 5/19/2022 9:31 PM, Bill Gunshannon wrote:
>> On 5/19/22 21:12, Arne Vajhøj wrote:
>>> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>>>> But that's a compiler (or programmer) problem and has nothing to
>>>> do with K&R beyond the age of the language definition.  A lot was
>>>> left out in the bygone era because of the limits on resources.
>>>> There is no reason, today, why th compiler can't point out the
>>>> bad ideas that programmers do that don't violate the K&R definition
>>>> but are just bad ideas. Do I need to point out the Safe C Compiler
>>>> again?
>>>
>>> Many things are possible.
>>>
>>> But are there any really good checking K&R compilers
>>> available?
>>
>> Yes, there was.  I have mentioned it here numerous times.  It
>> was called Safe C and was available on both the PDP-11 and VAX.
>> And, apparently, the industry resoundingly rejected it.
>
> So there was something available 30-40 years ago.
>
> That does not help anyone today.

Yes, but the point was that it could be. Just like they could
have come up with better string handling libraries which over
time could have found their way into the CRTL. Heck, ANSI
could have come up with a defined string that was not null
terminated. Over the past 30-40 years all of this could have
been done and with minimal impact on older code. A defined
string would not have stopped people from using a null
terminated array of char bujt it would have given an option
for future development and even maintenance of older programs.
But it wasn't and that is not the fault of the language.

>
>>> If not then the fact that one could be written is not
>>> that useful.
>>
>> Why is that?
>
> Because those people with C code want to build their
> C code - they do not want to write their own compiler.
> They have to use the C compilers that are actual available
> for the platforms of today.

No one had to write their own compiler. It was done. The
industry wasn't interested. For whatever reason they chose
to continue with compilers that allowed dangerous code. If
it had been accepted it could have been the new standard for
C compilers and we wouldn't be having this conversation. As
you said above, we had 30-40 years to fix this. We even had
a major change of the language by ANSI. Why did no one do
anything about it?

bill

[Arne Vajhøj]

A lot of things is possible. New compilers could be developed.
Some compiler existed 30-40 years ago.

But that does not help those with K&R C code today. They have
the compilers they have.

And based on how the state of world actually are today then
I think Hoff's advice made a lot of sense.

Arne

[Bill Gunshannon]

True, but some of what I mentioned isn't limited to compilers
or just K&R code.

Why didn't ANSI fix some of the problems like null terminated
strings, requiring bounds checking, etc. when they had the
chance?

bill

[Jake Hamby]

On Friday, May 20, 2022 at 9:22:17 AM UTC-7, Bill Gunshannon wrote:
> >
> > And based on how the state of world actually are today then
> > I think Hoff's advice made a lot of sense.
> True, but some of what I mentioned isn't limited to compilers
> or just K&R code.
>
> Why didn't ANSI fix some of the problems like null terminated
> strings, requiring bounds checking, etc. when they had the
> chance?
>
> bill

Well, C is very much in the "worse is better" spirit of software design that Richard Gabriel coined in 1989, to contrast with Lisp and other designs that focused on correctness rather than "move fast and break things".

C++ is the way it is because everyone wanted it to be backwards-compatible to C. It also didn't have the ability in the early days to support safer ways of working with data (STL, exceptions). If you want to see something truly hideous, look up how Symbian (EPOC32) implemented strings and byte buffers (ASCII and UTF-16) for an early GCC cross-compiler using their own custom class library (they had their own setjmp/longjmp based alternative to C++ exceptions, too).

One VMSism that fascinates me is that it's the only OS that I've used with a calling standard that passes the number of arguments and their types (64-bit int or float) to the callee, so it's simple to implement variadic functions in C that don't crash if the programmer put too many "%" specifiers in their printf() string for the number of arguments passed. That's also how the CRTL can have POSIX functions with VMS extensions that take an extra argument or two. Without the argument info register, this wouldn't be possible, and isn't possible on UNIX or Windows.

In a fit of madness about 16 months ago, I started writing some C++ wrappers for VMS system primitives, string descriptors, RMS, etc. to see if it'd be possible to make a friendlier wrapper than the C API. One advantage of C++ is that it's possible to wrap classes around C in a zero-overhead way. In fact, some of my classes inherited from the VMS struct they add functions to.

https://github.com/jhamby/vms-cd-new/tree/main/src

Sadly, I didn't finish my C++ version of the "CD" utility I was trying to port from VAX MACRO, but the attempt was quite educational. I think the C APIs are sufficient for someone to wrap much higher-level abstractions on top of. If you look at VSI's Python modules for VMS system calls, you can see that they're very low-level wrappers on top of the VMS APIs, much like my C++ headers. I prefer the way the port of Regina works, where the author wrote implementations of the DCL F$ lexical functions and then does all the work under the hood in C code to get the info the user wants, as a string or integer.

Jake

[Jake Hamby]

On Thursday, May 19, 2022 at 7:25:58 PM UTC-7, Craig A. Berry wrote:
> It's going to remain an open question for some time. As far as I know,
> none of the cross compilers has optimizations turned on, which means
> there is no optimized code in the OS or libraries shipped with the OS,
> much less in anything you build yourself.
>
> Once the optimizations are available, you'll run into the inherently
> slow file I/O and network I/O that have been discussed many times here.
> The current roadmap does not include either of the new filesystems that
> have been planned and set aside, nor the networking overhaul (VCI 2.0).
> One can hope these will come back one day once the port to x86 is done.
>
> I would not expect VMS to be competitive in raw speed with other OSs on
> the same hardware anytime soon, but it really just needs to be a bit
> faster on virtual x86 than it was on the last generation of Integrity
> hardware for it to be a big step forward. Reducing cost and risk are
> going to be a lot more important to most people in the near term than
> increasing speed.

I agree with everything you just said.

> pipe() on VMS is based on mailboxes, an ancient virtual device
> technology that is convenient to use and quite effective for passing
> small messages around between processes. But it's slow, and it's a
> record-oriented device, which doesn't always play nice in a
> stream-oriented world (though stream-oriented behavior is emulated to
> some extent). For a faster pipe implementation see dmpipe, which uses
> global sections:
>
> https://sourceforge.net/p/vms-ports/dmpipe
>
> Unfortunately this involves wrapping pretty much every function in the
> CRTL that touches a file descriptor -- the fix should really be inside
> the CRTL, but, alas, that also is not on the roadmap.

Aha, that's where I should look for a faster pipe implementation, thanks! I saw something similar to dmpipe in the GNV bash port ("vms_vm_pipe.c"), but it didn't come with docs or test programs, so I didn't want to use that version.

The code that I need to update, to finish making Regina useful again on VMS, is reviving the original author's code to call lib$spawn() with the NOWAIT flag to execute DCL commands and redirect their SYS$INPUT and SYS$OUTPUT.

It'd be nice if I could use the vfork()/execvp() code that I wrote, but it only works for .exe and .com files, not DCL commands. So I'm going to have to revive the lib$spawn() based vms_do_command(), which uses mailbox devices, and was ironically #ifdef'd out later with the (too-optimistic) comment:

/*
* At least with OpenVMS 7.3-1 on Alpha, the Posix way seems to work.
* So there is no need to redirect on (now) bogus code.
* But I keep the code here in case I didn't see something.
*/

Honestly, I'm not sure what code paths any previous users of Regina on VMS were actually using, because, before I started making my changes, the do_command code was falling through to generic code that used temp files for redirection instead of any of the clever POSIX stuff that does mostly seem to work on VMS. It's just that I have to modify it to try to use lib$spawn() first, to achieve the original behavior of letting you put arbitrary DCL commands in Rexx scripts and redirect their input/output into files or Rexx FIFOs (a really cool feature of the language). The vfork()/execvp() code is still useful as a fallback, and when Regina needs to spawn itself as a subprocess.

Jake

[Jake Hamby]

On Thursday, May 19, 2022 at 2:21:04 PM UTC-7, Jake Hamby wrote:
> Nothing at all VMS-specific about that bug, and I really have had no complaints about DEC C/C++ in terms of the compiler crashing with internal errors or generating bad code or anything like that with open source programs I've compiled.

I had to jinx myself: after I wrote that, I managed to get an internal compiler error in VSI C V7.4-002 on the Alpha by building rexx.exe with /PLUS_LIST_OPTIMIZE and /OPT=(LEV=5). I assume I managed to overflow some internal inlining logic. With level 4 optimization, the compile succeeds and the program is smaller and runs faster than with LEV=5 and no /PLUS_LIST.

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000010, PC=00000000005F5F14, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$COMPILER GEM_FI_PEEP MOVE_SECTION
5766 0000000000005604 00000000005F5F14
DECC$COMPILER GEM_FI_PEEP REVERSE_CROSS_JUMP
7959 0000000000007A48 00000000005F8358
DECC$COMPILER GEM_FI_PEEP GEM_FI_PEEP_BRANCH_PROCESSING
3075 000000000000217C 00000000005F2A8C
DECC$COMPILER GEM_FI_PEEP_ALPHA GEM_FI_PEEP_APPLY_PEEPHOLE
741 0000000000000148 000000000083B168
DECC$COMPILER GEM_FI_PEEP PROCESS_PATTERN_LIST
7573 0000000000007284 00000000005F7B94
DECC$COMPILER GEM_FI_PEEP GEM_FI_PEEP
1579 00000000000003E4 00000000005F0CF4
DECC$COMPILER 0 000000000049AC28 000000000049AC28
DECC$COMPILER 0 000000000049B034 000000000049B034
DECC$COMPILER GEM_CO GEM_CO_COMPILE_MODULE
3730 0000000000000D3C 000000000054EDEC
DECC$COMPILER COMPILE gemc_be_master
93315 0000000000000F5C 00000000001C35BC
DECC$COMPILER COMPILE 92535 00000000001C35BC 0000000000000000
DECC$COMPILER GEM_CP_VMS GEM_CP_MAIN
2629 00000000000018BC 0000000000535AEC
0 FFFFFFFF80383C04 FFFFFFFF80383C04
%TRACE-I-END, end of TRACE stack dump
%MMK-F-ERRUPD, error status %X1000000C occurred when updating target REXX.EXE

[Stephen Hoffman]

On 2022-05-19 21:21:02 +0000, Jake Hamby said:

> On Thursday, May 19, 2022 at 12:11:43 PM UTC-7, Stephen Hoffman wrote:
>>
>> Clang building with C18 / C2X with diagnostics lit (clang -Wall, maybe
>> also with -Wextra) produces more reliable code.
>> VSI C with /STANDARD=C99 /WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT,
>> QUESTCODE, ...), DISABLE=(...)) does well at finding trouble. Adding
>> VERBOSE and OVERFLOW can be useful, too.
>>
>
> I completely agree with everything you said, and thanks for the
> suggestion of useful warnings to enable.
>

For projects ranging from refactoring to a full overhaul, consider
adding preprocessor #define commands to cause certain entirely valid
but too-often problematic C calls to generate errors. (e.g. sprintf,
strcat, strcpy, etc)

https://en.wikipedia.org/wiki/C_standard_library#Buffer_overflow_vulnerabilities


Not yet part of ANSI/ISO C, but strlcat and strlcpy and ilk are locally
preferred to the strr* calls, as the latter are problematic around
string termination.

Since this is comp.os.vms, and when portability is not an issue, string
descriptors can be an option. Native OpenVMS C support for descriptors
is limited, however. That support is somewhat less opaque than one
might prefer. Objective C has some related enhancements here, but those
well past descriptors in its capabilities. Assuming run-time
message-passing support of course, which OpenVMS lacks. It'll be
interesting to see how OpenVMS does with blocks, as that extension was
already part of Clang when last I checked.

>
>> There can be good VAX C code. It's just... very rarely encountered. If
>> OpenVMS C code is now compiling with /STANDARD=VAXC, then somebody
>> noticed the C diagnostics, and decided to ignore them.
>
> Fortunately, I haven't run into that particular issue!
>

You're seemingly mostly working with cross-platform code. That has
probably been mostly-scrubbed of K&R C. A little more scrubbing is
probably arriving with C2X, with the function declaration syntax
deprecation.

[Craig A. Berry]

On 5/20/22 3:17 PM, Jake Hamby wrote:
> On Thursday, May 19, 2022 at 7:25:58 PM UTC-7, Craig A. Berry wrote:

>> For a faster pipe implementation see dmpipe, which uses
>> global sections:
>>
>> https://sourceforge.net/p/vms-ports/dmpipe
>>
>> Unfortunately this involves wrapping pretty much every function in the
>> CRTL that touches a file descriptor -- the fix should really be inside
>> the CRTL, but, alas, that also is not on the roadmap.

> Aha, that's where I should look for a faster pipe implementation,
> thanks! I saw something similar to dmpipe in the GNV bash port
> ("vms_vm_pipe.c"), but it didn't come with docs or test programs, so I
> didn't want to use that version.

I'm pretty sure that one is just using heap memory to do its own
buffering around a mailbox pipe, but I confess I've never looked at it
in any detail.

dmpipe uses global sections, which is really what the CRTL should have
switched to decades ago. I believe the VMS port of Apache uses sockets,
but it involves installing an image with privileges in order to be able
to bump the socket buffer size above the puny 255-byte default.

> The code that I need to update, to finish making Regina useful again
> on VMS, is reviving the original author's code to call lib$spawn()
> with the NOWAIT flag to execute DCL commands and redirect their
> SYS$INPUT and SYS$OUTPUT.
>
> It'd be nice if I could use the vfork()/execvp() code that I wrote,
> but it only works for .exe and .com files, not DCL commands.

There is some stuff in the Perl sources that tries to figure out whether
the thing it's been sent is an image name or a DCL command:

https://github.com/Perl/perl5/blob/blead/vms/vms.c#L10520

[Stephen Hoffman]

On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:

> Why didn't ANSI fix some of the problems like null terminated strings,
> requiring bounds checking, etc. when they had the chance?

Just a guess: probably because the C committee is not entirely
comprised of pendejos.

While the C committee could make such changes, those changes would
break enough existing C code that there'd be little reason not to break
yet more of the existing C programs.

Which then means this new C-family language would be competing with
other C-family languages; with the likes of Go, Rust, Swift, Zig, Java,
etc.

[Bill Gunshannon]

On 5/20/22 17:03, Stephen Hoffman wrote:
> On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:
>
>> Why didn't ANSI fix some of the problems like null terminated strings,
>> requiring bounds checking, etc. when they had the chance?
>
> Just a guess: probably because the C committee is not entirely comprised
> of pendejos.
>
> While the C committee could make such changes, those changes would break
> enough existing C code that there'd be little reason not to break yet
> more of the existing C programs.

How would adding a string type break null terminated strings? One could
still use them but a safer option would be available. And then time and
inertia would eventually eliminate the bad practice. Bounds checking?
Even if it were to break something how would that be a bad idea as out
of bounds accesses are a really bad idea.

>
> Which then means this new C-family language would be competing with
> other C-family languages; with the likes of Go, Rust, Swift, Zig, Java,
> etc.

I guess I don't see how this would constitute a new language.
It would merely be a few minor tweaks to C but nothing would
actually change in the syntax or use of the language. And
the old ways would still be available. Heck you could even
make stuff like bounds checking an option in the compiler
but I really fail to see why anyone today would want to forego
it.

bill

[Arne Vajhøj]

On 5/20/2022 3:59 PM, Jake Hamby wrote:
> One VMSism that fascinates me is that it's the only OS that I've used
> with a calling standard that passes the number of arguments and their
> types (64-bit int or float) to the callee,

It certainly passes the number of arguments.

But type??

Arne

[John Reagan]

I haven't forgotten about it. It isn't in yet as we've been focusing on other things
for the most recent ECOs.

[John Reagan]

Only if you compile /TIE (which is not the default).

[John Reagan]

/OPT=5 was always a work-in-progress when the Alpha work was stopped.
There was several places where it generated slower code than /OPT=4. That's
why 4 was left as the default.

[Jake Hamby]

On Friday, May 20, 2022 at 6:00:44 PM UTC-7, xyzz...@gmail.com wrote:
> /OPT=5 was always a work-in-progress when the Alpha work was stopped.
> There was several places where it generated slower code than /OPT=4. That's
> why 4 was left as the default.

That's good to know, thanks. On further inspection, the compiler ran out of heap memory. I watched it with ^T and it crashed after growing to around 1643 MB (210368 pages). /OPT=4 is perfectly fine for me.

I'd guess that there's had to have been some 64-bitification of the GEM compilers for x86-64 due to the size of compiling LLVM and Clang, if nothing else. I'm surprised that Microsoft Visual Studio has only been available as a 64-bit IDE for less than a year (Visual Studio 2022). They've been shipping x86-64 compilers for many years, but the compilers themselves have always been 32-bit until just now.

[Jake Hamby]

Hmm, this seems to be a regression in x86-64 compared to Alpha and Itanium. VSI Calling Standard 3.6.1. Call Conventions:

https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32

See Figure 3.10. Argument Information Register (R25) Format. For Itanium, it's 4.7.5.3. Argument Information (AI) Register:

https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARG_INFO_REGISTER

It's R25 in both cases. There are 8 x 3-bit fields in the register that indicate whether it's a 64-bit integer (or 32-bit sign extended), or one of the variety of floating-point formats supported. If this information is only being generated when compiled with /TIE, there's a serious omission in your own documentation.

On x86-64, the %rax register looks very different and indeed doesn't have the parameter type information:

https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARGUMENT_INFORMATION_REGISTER_X86_64

[Dave Froble]

Do that, and someone like Simon will get in there and break some things.

:-)

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

[John Reagan]

The x86 cross-compilers are all 32-bit pointers including the LLVM pieces. For the native compilers, the frontends and GEM pieces are still 32-bit pointers. The GEM-to-LLVM is now 64-bit pointers and LLVM itself is compiled with 64-bit pointers.

[John Reagan]

On Friday, May 20, 2022 at 10:15:30 PM UTC-4, jake....@gmail.com wrote:
> On Friday, May 20, 2022 at 5:58:40 PM UTC-7, xyzz...@gmail.com wrote:
> > On Friday, May 20, 2022 at 7:46:43 PM UTC-4, Arne Vajhøj wrote:
> > > On 5/20/2022 3:59 PM, Jake Hamby wrote:
> > > > One VMSism that fascinates me is that it's the only OS that I've used
> > > > with a calling standard that passes the number of arguments and their
> > > > types (64-bit int or float) to the callee,
> > > It certainly passes the number of arguments.
> > >
> > > But type??
> > >
> > > Arne
> > Only if you compile /TIE (which is not the default).
> Hmm, this seems to be a regression in x86-64 compared to Alpha and Itanium. VSI Calling Standard 3.6.1. Call Conventions:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32
>
> See Figure 3.10. Argument Information Register (R25) Format. For Itanium, it's 4.7.5.3. Argument Information (AI) Register:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARG_INFO_REGISTER
>
> It's R25 in both cases. There are 8 x 3-bit fields in the register that indicate whether it's a 64-bit integer (or 32-bit sign extended), or one of the variety of floating-point formats supported. If this information is only being generated when compiled with /TIE, there's a serious omission in your own documentation.

I'll double check. I might be thinking of the additional call signature relocations at external calls which might resolve to translated code.

>
> On x86-64, the %rax register looks very different and indeed doesn't have the parameter type information:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARGUMENT_INFORMATION_REGISTER_X86_64

Huh? There is the Argument Info Offset at at bit 47 and then CS talks about what the AIB looks like. We don't create them at this point. It is a latent definition.

[Stephen Hoffman]

On 2022-05-20 22:26:16 +0000, Bill Gunshannon said:

> On 5/20/22 17:03, Stephen Hoffman wrote:
>> On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:
>>
>>> Why didn't ANSI fix some of the problems like null terminated strings,
>>> requiring bounds checking, etc. when they had the chance?
>>
>> Just a guess: probably because the C committee is not entirely
>> comprised of pendejos.
>>
>> While the C committee could make such changes, those changes would
>> break enough existing C code that there'd be little reason not to break
>> yet more of the existing C programs.
>
> How would adding a string type break null terminated strings?

Ah, okay. You were adding features, and not actually fixing things. I
got confused. My bad.

>> Which then means this new C-family language would be competing with
>> other C-family languages; with the likes of Go, Rust, Swift, Zig, Java,
>> etc.
>
> I guess I don't see how this would constitute a new language.

Objective C already provides this, and very nicely.

Or available with a migration to C++ for that matter, too.

But by all means, please do go design and create your new C language.

[Craig A. Berry]

Thanks, and I get it -- your priorities are where they need to be for now.

[John Reagan]

I have asked for it to be moved up. Even with the PIPE driver (cousin of the
mailbox driver), I still see the record orientation showing up when I do something
like

$ pipe anal/obj/section=symbol | search sys$pipe symbolname

[Arne Vajhøj]

On 5/20/2022 10:15 PM, Jake Hamby wrote:
> On Friday, May 20, 2022 at 5:58:40 PM UTC-7, xyzz...@gmail.com wrote:
>> On Friday, May 20, 2022 at 7:46:43 PM UTC-4, Arne Vajhøj wrote:
>>> On 5/20/2022 3:59 PM, Jake Hamby wrote:
>>>> One VMSism that fascinates me is that it's the only OS that I've used
>>>> with a calling standard that passes the number of arguments and their
>>>> types (64-bit int or float) to the callee,
>>> It certainly passes the number of arguments.
>>>
>>> But type??

>> Only if you compile /TIE (which is not the default).
>
> Hmm, this seems to be a regression in x86-64 compared to Alpha and
> Itanium. VSI Calling Standard 3.6.1. Call Conventions:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32
>
> See Figure 3.10. Argument Information Register (R25) Format. For
> Itanium, it's 4.7.5.3. Argument Information (AI) Register:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARG_INFO_REGISTER
>
> It's R25 in both cases. There are 8 x 3-bit fields in the register
> that indicate whether it's a 64-bit integer (or 32-bit sign
> extended), or one of the variety of floating-point formats supported.
> If this information is only being generated when compiled with /TIE,
> there's a serious omission in your own documentation.

I had never seen that.

But I am not sure that I will call that passing type of argument.

It identifies arguments that are F, D, G, S and T floating point.

All the rest is bundled together: 8/16/32/64 bit integers, booleans,
string descriptors, arrays, structs etc.. It is passed in an
integer register, but it is not necessarily an integer.

Arne