On 2022-05-11, Dave Froble <davef@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.

On 5/12/22 09:08, Simon Clubley wrote:
> On 2022-05-11, Dave Froble <davef@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

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

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

Arne Vajhøj <arne@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

On 5/16/2022 3:12 AM, Paul Hardy wrote:
> Arne Vajhøj <arne@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?

Arne

Den 2022-05-16 kl. 14:43, skrev Arne Vajhøj:
> On 5/16/2022 3:12 AM, Paul Hardy wrote:
>> Arne Vajhøj <arne@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?
>
> Arne
>

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.

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 <arne@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

On 2022-05-13, Jake Hamby <jake.hamby@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.

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

On 2022-05-15, Arne Vajhøj <arne@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...

Simon.

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

On Monday, May 16, 2022 at 2:11:03 PM UTC-4, Simon Clubley wrote:
> 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.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
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.

On 2022-05-16, John Reagan <xyzzy1959@gmail.com> wrote:
> On Monday, May 16, 2022 at 2:11:03 PM UTC-4, Simon Clubley wrote:
>> 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.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> 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.

_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. :-)

Simon.

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

On 5/16/2022 2:14 PM, Simon Clubley wrote:
> On 2022-05-15, Arne Vajhøj <arne@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

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

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

On 2022-05-16 19:49:45 +0000, Arne Vajhj 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”.

--
Pure Personal Opinion | HoffmanLabs LLC

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.

--
Pure Personal Opinion | HoffmanLabs LLC

On 05/16/22 20:49, Arne Vajhøj wrote:
> 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
>
>

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

On 2022-05-16, Stephen Hoffman <seaohveh@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.

Simon.

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

On 5/17/2022 7:16 AM, chris wrote:
> On 05/16/22 20:49, Arne Vajhøj wrote:
>> 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.
>
> 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

On 5/17/2022 8:49 AM, Simon Clubley wrote:
> On 2022-05-16, Stephen Hoffman <seaohveh@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

On 05/17/22 21:33, Arne Vajhøj wrote:
> On 5/17/2022 7:16 AM, chris wrote:
>> On 05/16/22 20:49, Arne Vajhøj wrote:
>>> 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.
>>
>> 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

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

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

On 5/15/22 19:46, Arne Vajhøj wrote:
> 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.

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

bill

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