Rust and VMS

[Simon Clubley]

I see once again Stephen is pushing Rust for use within VMS itself.

I'm surprised you are pushing it Stephen because surely you must
realise the one major thing which disqualifies it from use within
VMS itself regardless of whatever merits you think it might have.
This thing is that Rust is not a language which is defined as part
of an international standards body's standards track.

You like to say that decisions made today within VMS will affect
where it is going to be 5-10 years from now and you are quite
correct. However, given the current Rust setup, there is absolutely
no guarantee that the Rust of today will still exist in a viable
form 5-10 years from now and you have no idea if there's going to
be some massive bust-up or split, say a couple of years from now,
which will dramatically change the nature of Rust and it's community
and whether it will even survive that.

You have have reasonable assurance of this with C/C++/Ada/etc but
you don't have this level of confidence with Rust.

Rust is much more a "language of the month/year" type fashion and
as such it's going to be irresponsible to use Rust within VMS itself
until it's placed on an international formal language standards
track with all the duties and responsibilities which that brings.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Craig A. Berry]

On Wednesday, January 18, 2017 at 1:29:06 PM UTC-6, Simon Clubley wrote:
> I see once again Stephen is pushing Rust for use within VMS itself.
>
> I'm surprised you are pushing it Stephen because surely you must
> realise the one major thing which disqualifies it from use within
> VMS itself regardless of whatever merits you think it might have.
> This thing is that Rust is not a language which is defined as part
> of an international standards body's standards track.

Rust is relatively new and standards usually follow widespread use. We seem to still be waiting for MACRO-32 and BLISS to achieve an adoption rate that would merit international standards :-). Plus Rust is MIT-licensed, so if there were significant code in VMS implemented in Rust, and if the Rust developers introduced breaking changes that would require extensive rewrites to that code, VSI would have the option of maintaining their own backward-compatible fork, which would be no disadvantage at all compared to the current implementation languages.

[David Froble]

This is getting to be fun ....

Simon Clubley wrote:
> I see once again Stephen is pushing Rust for use within VMS itself.

Nobody is perfect.

> I'm surprised you are pushing it Stephen because surely you must
> realise the one major thing which disqualifies it from use within
> VMS itself regardless of whatever merits you think it might have.
> This thing is that Rust is not a language which is defined as part
> of an international standards body's standards track.

Where can I find this list. I'll be looking for Macro-10, Macro-11, Macro-32,
Macro-64, BAL, Bliss, Visual C++, and such.

> You like to say that decisions made today within VMS will affect
> where it is going to be 5-10 years from now and you are quite
> correct. However, given the current Rust setup, there is absolutely
> no guarantee that the Rust of today will still exist in a viable
> form 5-10 years from now and you have no idea if there's going to
> be some massive bust-up or split, say a couple of years from now,
> which will dramatically change the nature of Rust and it's community
> and whether it will even survive that.

I'll agree with what you say. But consider, just like the "special" C used for
system programming, should VSI decide to make Rust their system programming
language, would not you think that they would have their own version of the
compiler? Might just need a few things not in the "standard". So, no matter
what, they would still have a version of Rust for VMS over which they would have
full control, right?

> You have have reasonable assurance of this with C/C++/Ada/etc but
> you don't have this level of confidence with Rust.
>
> Rust is much more a "language of the month/year" type fashion and
> as such it's going to be irresponsible to use Rust within VMS itself
> until it's placed on an international formal language standards
> track with all the duties and responsibilities which that brings.

That won't happen. These LOTM thingies are coming out faster than anybody can
add them to your IFLS.

:-)

[Stephen Hoffman]

On 2017-01-18 19:27:27 +0000, Simon Clubley said:

> I see once again Stephen is pushing Rust for use within VMS itself.

I'm pushing the concept of introspection. Not Rust. Of looking
around at the current implementation and considering — really
considering — if the chosen languages are still appropriate, whether
there are changes — moving to C11 or C++14 or otherwise, or whether
there are viable or better alternatives. Or if the decision here is
more of a default choice; of coasting along, getting along, going
along, of not changing things, of perceived safety, of risk aversion,
and other related phrases. This for whatever you're doing, whether
we're discussing OpenVMS or your own application coding tools and
practices, or product purchasing choices or your preferred commuting
routes, or otherwise. How many things do any of us do automatically,
and that we haven't occasionally considered why or whether {whatever}
still makes sense, or if there are better options or approaches or
alternatives available.

Right now, Rust is a rounding error in terms of its general acceptance.
But it has some concepts and capabilities that C doesn't have,
specifically targeting security and stability and predictability. And
developer interest.

> I'm surprised you are pushing it Stephen because surely you must
> realise the one major thing which disqualifies it from use within VMS
> itself regardless of whatever merits you think it might have.

Do you have any pointers to the documents for the Bliss and Macro32
international standards?

Last I checked, the version of C used within OpenVMS was also no longer
considered an international standard, too. But that's pedantic.

> This thing is that Rust is not a language which is defined as part of
> an international standards body's standards track.

Standards processes and documents can be surprisingly sausage-like at
times, too, but then I've tracked some evolving standards closely and
have attended various standards meetings over the years.

See the discussion of "a flaw in the POSIX standards process" here, too:

https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html

Obligatory: https://xkcd.com/927/

> You like to say that decisions made today within VMS will affect where
> it is going to be 5-10 years from now and you are quite correct.
> However, given the current Rust setup, there is absolutely no guarantee
> that the Rust of today will still exist in a viable form 5-10 years
> from now and you have no idea if there's going to be some massive
> bust-up or split, say a couple of years from now, which will
> dramatically change the nature of Rust and it's community and whether
> it will even survive that.

True. But ponder that OSI was a standard, and that imploded. Ada
was considered salvation a couple of decades ago, too. While it's
not an appropriate choice for system-level programming, Java is looking
a little peaked, too. The fun thing with standards is that there are
so many of them to choose from, as the joke goes. Then you get cases
like POSIX time offsets go one way, and everybody else numbers the
other way.

It's all guesses. Gambles. Trade-offs. Figuring out what works
and what doesn't, and where you can differentiate and where you
shouldn't or can't.

As for longer-term stability, I think that's a great idea right up
until somebody gets handed the choice of fixing something and breaking
compatibility, or leaving the problem around for others to deal with.
This whether we're discussing API stability or languages or
upward-compatibility or otherwise. For various and good business and
technical reasons, Macro32 and Bliss code is still around and will
remain for the foreseeable future, though any of us would prefer to
have fewer permutations to deal with. q.v. strangling. That
continued existence will also tend to reduce the willingness of teams
to choose other (and usually better) options, too.

https://www.martinfowler.com/bliki/StranglerApplication.html
https://en.wikipedia.org/wiki/Sunk_cost
Etc.

> You have have reasonable assurance of this with C/C++/Ada/etc but you
> don't have this level of confidence with Rust.

Welcome to trade-offs. Got a choice better than C here? Because all
three languages have issues. As a choice, Ada ain't all that and a
bag of chips, unfortunately. Not in terms of interest generated among
developers, existing international standards aside.

http://stackoverflow.com/research/developer-survey-2016#technology-most-loved-dreaded-and-wanted

> Rust is much more a "language of the month/year" type fashion and as
> such it's going to be irresponsible to use Rust within VMS itself until
> it's placed on an international formal language standards track with
> all the duties and responsibilities which that brings.

Yes, because following along with how Things Are Done usually works out
so well in the long-term, when you're already behind, and are competing
in a market with far larger entities.

TL;DR: Go big or go home. Is Rust even remotely part of that?
Absolutely no idea. None.


--
Pure Personal Opinion | HoffmanLabs LLC

[Simon Clubley]

On 2017-01-18, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2017-01-18 19:27:27 +0000, Simon Clubley said:
>
>> I'm surprised you are pushing it Stephen because surely you must
>> realise the one major thing which disqualifies it from use within VMS
>> itself regardless of whatever merits you think it might have.
>
> Do you have any pointers to the documents for the Bliss and Macro32
> international standards?
>

They are not needed.

A standard is essentially a contract between two groups of otherwise
unrelated parties - the party which creates the standard and the
parties which use the standard.

The reputation of the organisation which has put it's name to the
standard (for example, ISO) is used as a guarantee that products
will be built which comply with this standard and that users can
safely invest resources in using products built to these standards.

This is not needed for Bliss and Macro-32 as the party which created
the languages (DEC) is also the party which uses the languages and
this is especially true as the party in question has a long standing
excellent reputation for compatibility with older versions of products
when it comes to customers using those languages.

(For example, with DEC C, how long has /STANDARD=ALLOW_CRAPPY_CODE,
aka /STANDARD=VAXC, been around ?)

None of this is currently true for Rust.

> Last I checked, the version of C used within OpenVMS was also no longer
> considered an international standard, too. But that's pedantic.
>

Compilers are good at compiling to older versions of a standard even
when something newer comes along.

>> This thing is that Rust is not a language which is defined as part of
>> an international standards body's standards track.
>
> Standards processes and documents can be surprisingly sausage-like at
> times, too, but then I've tracked some evolving standards closely and
> have attended various standards meetings over the years.
>

The standards process is certainly not perfect but it's better than
the alternative.

Web standards came along when vendors realised they needed to stop
playing silly buggers with their browsers and grow up. Even now, there
are still differences between the browsers but the situation would be
far worse if those standards didn't exist in the first place because
those standards establish a lot of detailed ground rules for a new
browser.

Using a language in VMS itself which comes from an external source, and
which doesn't have that formal weight behind it, is utterly unthinkable
in a product designed for the uses that VMS is used for.

[Simon Clubley]

The problem there is that new developers to VSI would have to learn
this older version of the language.

Also, the compiler would increasingly become older and stale and
I've seen something similar. Microchip forked gcc for it's own
PIC32 compiler and as a result the Microchip version was getting
increasingly older and stale the last time I checked a couple of
years or so ago.

[Simon Clubley]

On 2017-01-18, David Froble <da...@tsoft-inc.com> wrote:
> This is getting to be fun ....
>
> Simon Clubley wrote:
>> I'm surprised you are pushing it Stephen because surely you must
>> realise the one major thing which disqualifies it from use within
>> VMS itself regardless of whatever merits you think it might have.
>> This thing is that Rust is not a language which is defined as part
>> of an international standards body's standards track.
>
> Where can I find this list. I'll be looking for Macro-10, Macro-11, Macro-32,
> Macro-64, BAL, Bliss, Visual C++, and such.
>

Visual C++ follows the ISO C++ language standard, you will have to
ask IBM about BAL and the rest are not required as explained in my
reply to Stephen.

>> You like to say that decisions made today within VMS will affect
>> where it is going to be 5-10 years from now and you are quite
>> correct. However, given the current Rust setup, there is absolutely
>> no guarantee that the Rust of today will still exist in a viable
>> form 5-10 years from now and you have no idea if there's going to
>> be some massive bust-up or split, say a couple of years from now,
>> which will dramatically change the nature of Rust and it's community
>> and whether it will even survive that.
>
> I'll agree with what you say. But consider, just like the "special" C used for
> system programming, should VSI decide to make Rust their system programming
> language, would not you think that they would have their own version of the
> compiler? Might just need a few things not in the "standard". So, no matter
> what, they would still have a version of Rust for VMS over which they would have
> full control, right?
>

That special C is just normal C with a restricted kernel mode RTL.

The only truly special C I have ever seen is one that had the
__interrupt keyword (or similar) added to it and most of the time
these days that's not even required.

[Arne Vajhøj]

On 1/18/2017 2:27 PM, Simon Clubley wrote:
> I'm surprised you are pushing it Stephen because surely you must
> realise the one major thing which disqualifies it from use within
> VMS itself regardless of whatever merits you think it might have.
> This thing is that Rust is not a language which is defined as part
> of an international standards body's standards track.
>
> You like to say that decisions made today within VMS will affect
> where it is going to be 5-10 years from now and you are quite
> correct. However, given the current Rust setup, there is absolutely
> no guarantee that the Rust of today will still exist in a viable
> form 5-10 years from now and you have no idea if there's going to
> be some massive bust-up or split, say a couple of years from now,
> which will dramatically change the nature of Rust and it's community
> and whether it will even survive that.
>
> You have have reasonable assurance of this with C/C++/Ada/etc but
> you don't have this level of confidence with Rust.
>
> Rust is much more a "language of the month/year" type fashion and
> as such it's going to be irresponsible to use Rust within VMS itself
> until it's placed on an international formal language standards
> track with all the duties and responsibilities which that brings.

True.

Arne

PS: I think Ada's current usage level is low enough to make using Ada
a risk.

[David Froble]

But ask yourself, why did they do that? I'm guessing there was a reason.
Perhaps your "standard" languages don't provide all of what might be needed for
implementing an OS. Or, do you propose to hobble OS development?

[John E. Malmberg]

Many languages are not too concerned with backwards compatibility.

In learning programming on my Android, I am finding that most of the
examples of what I am trying to do are flagged by my IDE as using
deprecated functions. Things are being replaced faster than the
tutorials and example are being updated.

For Ruby on Linux, in order to support multiple versions, they setup a
"hook" in the shell that runs a script to set up a specific version of
ruby for an environment.

Python on Linux has a virtualenv to support multiple environments.

Building rust seems to require Python.

Is the VMS port of python up to it?

Regards,
-John
wb8...@qsl.net_work

[Richard Maher]

On 19-Jan-17 6:23 AM, Stephen Hoffman wrote:
> On 2017-01-18 19:27:27 +0000, Simon Clubley said:
>
>> I see once again Stephen is pushing Rust for use within VMS itself.
>
> I'm pushing the concept of introspection.

Yeah navel-gazing has always been big with with Digits that never had to
get a real job :-(

[Simon Clubley]

On 2017-01-19, David Froble <da...@tsoft-inc.com> wrote:

> Simon Clubley wrote:
>>
>> The problem there is that new developers to VSI would have to learn
>> this older version of the language.
>>
>> Also, the compiler would increasingly become older and stale and
>> I've seen something similar. Microchip forked gcc for it's own
>> PIC32 compiler and as a result the Microchip version was getting
>> increasingly older and stale the last time I checked a couple of
>> years or so ago.
>>
>

> But ask yourself, why did they do that? I'm guessing there was a reason.

It's Microchip. The alternative would have been to contribute to the
mainstream FSF branch so that everyone could easily and freely use
the PIC32 with future versions of the FSF toolchain but I suspect
they didn't want to give up that level of control.

The irony is that this is what happened anyway - I have never used
any tool from the Microchip website to write code for the PIC32;
I have always used the port done by MIPS themselves instead which
MIPS made freely available.

> Perhaps your "standard" languages don't provide all of what might be needed for
> implementing an OS. Or, do you propose to hobble OS development?

The standard languages have worked just fine for mainstream OS
development so far.

[Bill Gunshannon]

Ada started out as a U.S. Air Force project. Upon completion, even
with a DOD mandate for use, the Air Force refused to use it.
That should really tell people something about how that project turned
out and the value of the language.

bill

[johnwa...@yahoo.co.uk]

I think "worked just fine" may be putting it a bit strong,
depending on whether buffer overflows, off by ones, reuse
after free, etc (and the consequences of those errors) are
considered harmful or just considered inevitable.

"Widely used architecture+design practices implemented in
widely used languages have got widely used OSes to where
they are today" might seem a bit more appropriate.

Should customers be looking for better options than the
widely used ones readily available today? Some of them
certainly should. But how to make that happen?

[Craig A. Berry]

On 1/18/17 11:23 PM, John E. Malmberg wrote:

> Many languages are not too concerned with backwards compatibility.

Rust is not one of them, at least not anymore. From the FAQ[1]:

"Now that Rust has reached 1.0, the language is guaranteed to be
'stable'; and while it may continue to evolve, code which works on
current Rust should continue to work on future releases."

See also "Stability as a Deliverable".[2]

[1] <https://www.rust-lang.org/en-US/faq.html>

[2] <https://blog.rust-lang.org/2014/10/30/Stability.html>

[Arne Vajhøj]

I think Ada did enjoy some success in the 80's and 90's.

But it sort of faded out after that (with the exception of the
real critical stuff in defense and aerospace).

It is also my impression that Ada83 was considered a good
procedural language but that Ada95 was considered a bad
OO language.

Arne

[Arne Vajhøj]

On 1/19/2017 12:23 AM, John E. Malmberg wrote:
> Many languages are not too concerned with backwards compatibility.
>
> In learning programming on my Android, I am finding that most of the
> examples of what I am trying to do are flagged by my IDE as using
> deprecated functions. Things are being replaced faster than the
> tutorials and example are being updated.

Different types of code has different requirements for stability
and backwards compatibility.

Smartphone app code and OS are in different ends of that scale.

Arne

[johnwa...@yahoo.co.uk]

Ain't that the truth. When time to market is a critical
success factor e.g. in the consumer electronics market,
as typified by phones and more recently "smart" TVs (for
dumb people?) it is often more important for something
(anything) to be delivered on time, complete with bad
architecture and implementation defects, something
which may well be obsolete anyway within weeks of being
shipped, so speed of development and shininess of
result is key. Security and ongoing support often isn't
even an afterthought.

This versus delivering something robust(ish) which might
ship in massively smaller quantities but have a deployed
lifetime of years (say in a more traditional business
system which may be a capital purchase rather than a
near-disposable item).

[IanD]

+100

[Arne Vajhøj]

On 1/19/2017 12:14 PM, johnwa...@yahoo.co.uk wrote:
> On Thursday, 19 January 2017 16:20:24 UTC, Arne Vajhøj wrote:
>> On 1/19/2017 12:23 AM, John E. Malmberg wrote:
>>> Many languages are not too concerned with backwards compatibility.
>>>
>>> In learning programming on my Android, I am finding that most of the
>>> examples of what I am trying to do are flagged by my IDE as using
>>> deprecated functions. Things are being replaced faster than the
>>> tutorials and example are being updated.
>>
>> Different types of code has different requirements for stability
>> and backwards compatibility.
>>
>> Smartphone app code and OS are in different ends of that scale.
>

> Ain't that the truth. When time to market is a critical
> success factor e.g. in the consumer electronics market,
> as typified by phones and more recently "smart" TVs (for
> dumb people?) it is often more important for something
> (anything) to be delivered on time, complete with bad
> architecture and implementation defects, something
> which may well be obsolete anyway within weeks of being
> shipped, so speed of development and shininess of
> result is key. Security and ongoing support often isn't
> even an afterthought.
>
> This versus delivering something robust(ish) which might
> ship in massively smaller quantities but have a deployed
> lifetime of years (say in a more traditional business
> system which may be a capital purchase rather than a
> near-disposable item).

And John was talking about smartphone apps not the smartphone
itself.

Those apps are even more fast paced than the phones.

Arne

[Bill Gunshannon]

If I had a dime for every time I heard that said... :-)

bill

[IanD]

I found this a good read about why ADA 'failed'

http://www.adapower.com/adapower1/articles/popularity.html

Written quite a while ago it captures a fair amount of what is probably long been forgotten about as to the landscape around the time

It also seems like the arrogance of the designer came into play a bit but I just finished reading some other aspects of fighter jet coding and what the ADA language was essentially commissioned to do at a time when so many languages were in use was rather impressive and probably required a certain amount of arrogance or the project would have never been implemented

I guess behind the scenes certain aspects of the new VMS will also meet this fate. Time to market for an x86 port is currently critical for VMS. It's at least 5 years behind when IMO it should have started as far as VMS being seen as a current marketable OS of choice. Fixes to items that may see it bottleneck itself will have to wait or x86 is never going to happen

Rust seems to have got the favor of some folks in surveys etc in places like stackoverflow

Seems pure parallel languages are taking a bit of a back-seat in favor of currency which might be easier to model overall ?

I lament that the Fortress language got the axe. Simply too hard to implement aspects of it in the likes of JVM. I really did like the idea of writing code mathematically. Also I believe Chapel and X10 made the shortcut and Fortress, being too new and experimental didn't

[Simon Clubley]

On 2017-01-19, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
> On Thursday, 19 January 2017 08:23:41 UTC, Simon Clubley wrote:
>> On 2017-01-19, David Froble <da...@tsoft-inc.com> wrote:
>>
>> > Perhaps your "standard" languages don't provide all of what might be needed for
>> > implementing an OS. Or, do you propose to hobble OS development?
>>
>> The standard languages have worked just fine for mainstream OS
>> development so far.
>>
>

> I think "worked just fine" may be putting it a bit strong,
> depending on whether buffer overflows, off by ones, reuse
> after free, etc (and the consequences of those errors) are
> considered harmful or just considered inevitable.
>

I knew I should have expanded on that before posting (and in
hindsight I should have worded the above differently), but I was
rushing to get out of the door on time. :-(

What I was trying to say is that there's a difference between the
language used for implementation of an OS and what is actually being
implemented.

C, as a language, is better than what came before (assembly language)
but as I have made clear, I think there are better non-vendor specific
languages which could be used but those other languages need to have
formal standards bodies behind them before they can be used for
serious OS development.

However, that doesn't change the fact that what's being implemented
is quite often the source of the security issues and not the
actual programming language itself.

For example, an OS which uses null terminated strings in it's APIs
and a all-or-nothing security model to do things is going to have
more issues than an OS which uses counted strings or string
descriptors and has more fine grained permissions.

An OS which is implemented as a microkernel may be more secure than
a monolithic kernel, even one which uses descriptors and fine
grained permissions.

This is true even though examples of all 3 types of operating
systems may have been implemented using the same language (C).

C certainly causes it's own range of security problems which would
not exist in other languages, but what is actually being implemented
(and it's APIs) brings it's own security issues, regardless of
implementation language.

[Bill Gunshannon]

I actually remember when the USENET article you pointed to above came
out. I always thought it was a little tongue-in-cheek but also very
insightful. It was fun to read it again now with all the memories it
brings back.

Now, here's my next suggestion. How about we revive PL/M.

bill

(was that also too tongue-in-cheek?)

[Stephen Davies]

On Thursday, 19 January 2017 03:31:04 UTC, Arne Vajhøj wrote:

> PS: I think Ada's current usage level is low enough to make
> using Ada a risk.

My place of work has almost completely abandoned VMS but still
uses Ada widely. I suspect (but may be completely off the mark)
that VMS's future is more at risk than Ada's.

To me, it seems like it would be nice to have a safe/secure
OS written in a safe/secure language. Of course, I don't see
potential VMS customers being swayed by the choice of
programming language.

[Stephen Hoffman]

On 2017-01-19 02:45:47 +0000, Simon Clubley said:

> Using a language in VMS itself which comes from an external source, and
> which doesn't have that formal weight behind it, is utterly unthinkable
> in a product designed for the uses that VMS is used for.

Oddly enough, Bliss arose at CMU, and was then adopted by folks at DEC.

http://www.cs.tufts.edu/%7Enr/cs257/archive/ronald-brender/bliss.pdf

But as to your point, if the full source code is available for the
compiler chain — in the case of Rust, it is — and if there's
familiarity with the internals of the implementation — the code
generation for multiple commercial languages on OpenVMS x86-64 is
expected to be built using the same LLVM back-end that Rust also shares
— I fail to see a particular issue here.

Track the languages chosen — Rust or otherwise — or fork it and use
what works. If the chosen language no longer works and/or if the
standards aren't helpful and/or if the local source code fork is no
longer sufficient for local needs, then choose a different language and
use that. Which is what I was originally stating around C and Bliss
for that matter. Performing an honest self-examination around
implementations and assumptions, as that helps avoid unnecessarily or
unknowingly accreting disadvantages.

The folks that want or need to use international standards are
generally operating further along in the adoption cycles. That
approach works, but often isn't the best spot for any entity attempting
to create competitive products, and to take advantage of technologies
and tools that can help differentiate the product. When you're a
smaller competitive entity, you almost have to move faster to succeed.
When you're bigger, you can have developed an ecosystem around your
products, and can — if you're not actively cannibalizing your own
offerings, as you should, and not taking an honest and deep look at
your own assumptions and practices and tools, as you should — coast
along for as long as a decade or two before the competitive troubles
start to accrue in earnest.

Becoming stuck on an ill-suited approach for IT hardware or software
product development — whether some tool, practice, widget, whatever —
usually doesn't end well for the vendor. Hopefully the vendor
understands that or realizes that their own assumptions have become
little better than delusions before the customers do, and before the
customers bail out, or the competitors move in. Because reversing that
trend is... not easy.

[Stephen Hoffman]

On 2017-01-19 03:02:41 +0000, Simon Clubley said:

> On 2017-01-18, Craig A. Berry <craig....@gmail.com> wrote:
>>
>> Rust is relatively new and standards usually follow widespread use. We
>> seem to still be waiting for MACRO-32 and BLISS to achieve an adoption
>> rate that would merit international standards :-). Plus Rust
>> is MIT-licensed, so if there were significant code in VMS implemented
>> in Rust, and if the Rust developers introduced breaking changes that
>> would require extensive rewrites to that code, VSI would have the
>> option of maintaining their own backward-compatible fork, which would
>> be no disadvantage at all compared to the current implementation
>> languages.
>
> The problem there is that new developers to VSI would have to learn
> this older version of the language.

Ayup. Much like learning Macro32, Bliss and C prior to C99 and the
kernel-mode C subset of the language for that matter, as well as a
whole host of other platform-specific development tools used for the
development of OpenVMS itself.

[David Froble]

There is a good parallel to this topic when it comes to purchasing a computer
system, and perhaps many other things.

If you need a computer today, buy what's available. If you continually wait for
some promised (real soon now) new feature, you'll never make the purchase.

[Bill Gunshannon]

You can't imagine how funny this is to me.

When I was working for a major contractor many moons ago my employer bid
a Prime 50 Series for a certain New England College's RFP. Our only
competitor was DEC. They bid a VAX that didn't exist yet. We provided
more than a box of fanfold paper with the benchmark results from our
system. DEC submitted an envelope that said when the system became
available it would out perform what we were bidding. After a bidding
conference where the Professor controlling the RFP stood up and said,
"I don't care who wins as long as it says VAX on the front." we
withdrew. (Yes, he really said that and I learned a very interesting
concept of doing business from it.) The VAX they bid was over two years
late. And in the end, the reasons the Professor was so adamant about
having a VAX came back to bite him. He wanted to be able to run all
the free educational software like the stuff from Kitt Peak Observatory.
Sadly, DEC had bid and eventually delivered the VAX running VMS. All
the free software he wanted to run was for BSD Unix. :-)

bill

[Arne Vajhøj]

On 1/20/2017 10:53 AM, Stephen Davies wrote:
> On Thursday, 19 January 2017 03:31:04 UTC, Arne Vajhøj wrote:
>> PS: I think Ada's current usage level is low enough to make
>> using Ada a risk.
>
> My place of work has almost completely abandoned VMS but still
> uses Ada widely. I suspect (but may be completely off the mark)
> that VMS's future is more at risk than Ada's.

True.

Arne

[IanD]

+1 and -1 :-)

Those on VMS who will stay there will probably only do so if the new incarnations (x86 and beyond) enable it to function with the rest of IT for the same or lower cost

For it to gain traction in cutting edge markets it's going to have to be attractive to the new minds driving those areas and I think new languages are needed. Your not going to attract a new IT grad with COBOL (throwing money at them aside of course)

The world doesn't seem to care much for waiting for existing languages to come out with the next certified version or standard unless that language is in current new deployment use on new projects (again, I don't see COBOL or BASIC or other languages getting a look in here, apart from C / C++). There was talk of FORTRAN making a comeback but it's probably too late for that language even though it's later versions have some nice features

New project get written in new / current languages it seems. Existing ones get worked on in the language they were created with or the data migrated away to a new platform. Wholesale re-writes onto the same platform are becoming less on older platforms like VMS

Someone once posted on these forums way way back when the excitement of VMS going to x86 was announced that applications were just as important. They were barely heard over all the x86 excitement chatter but I think their view is extremely important

After VMS-x86-64, then what? We have to have something more than just trying to stop customers eyeing the door. x86 only gives them less of a reason, what else will we need to do to keep them and more importantly, attract new ones or perhaps get some back that left reluctantly because of no uncertainly at the time

Cluster revamping? (multi-tiered clusters? perhaps?). Security surely must feature highly as an area of focus. It's an area that business will pay money for. Modernising the development? Getting an open source DB migrated and frame-working open source building on VMS so that it isn't anywhere as painful and 'different'

Where I used to work, they are moving away from VMS. Data is being migrated to an Oracle system. Even with VSI taking the reigns of VMS has not changed their mind. When I spoke with someone recently about staying on VMS, he told me 'We just want uniform platforms and products to support". They have an unlimited license with Oracle, it's no additional cost to bring things under another Oracle product and they gain by having one less 'other' vendor to pay :-(
Uniformity saves money, doing what everyone else is doing saves money

Bundled cost / offerings is very attractive for certain companies with large IT spends. These environments are where small players are getting crushed

[Hans Vlems]

How available is Rust for VMS?
And if there is a kit, where can I get one?
Hans

PS
I'm a poor hobbyist remember....

[Craig A. Berry]

On 1/21/17 5:54 AM, Hans Vlems wrote:
> How available is Rust for VMS?
> And if there is a kit, where can I get one?

It's purely speculative at this point. When the x86_64 port is complete
and if and when enough is known about the LLVM backend of the VSI
compilers that it can be repurposed for another compiler and somebody
(VSI or otherwise) does a port, then it might be available. On x86_64
only. Unless you want to spend billions on creating or reviving
llvm-alpha or llvm-ia64.

The port would likely be more than just a simple build; there might well
be OS-specific considerations around concurrency, file I/O, and perhaps
other things.

[John Reagan]

On Saturday, January 21, 2017 at 1:21:49 AM UTC-5, IanD wrote:

> The world doesn't seem to care much for waiting for existing languages to come out with the next certified version or standard unless that language is in current new deployment use on new projects (again, I don't see COBOL or BASIC or other languages getting a look in here, apart from C / C++). There was talk of FORTRAN making a comeback but it's probably too late for that language even though it's later versions have some nice features

I get as many questions about Fortran futures as anything else. There is still a pretty large Fortran community.

[Phillip Helbig (undress to reply)]

In article <78eab57d-09b7-42d9...@googlegroups.com>, John

Indeed. Much of it is used by people actually doing real calculations,
instead of trying to be cool. :-)

[Bill Gunshannon]

And COBOL as well, regardless of what academia has to say about it.

bill

[Kerry Main]

Throwing money at Cobol developers would be a small fraction of the company cost to convert to something else.

Unfortunately, to many in senior mgmt. positions either do not understand this or want to make a name for themselves in the company and/or for their resume.

Unfortunately, "Upgrade and integrate" vs. "rip-n-replace" decisions are often based on the past religion of those making and/or influencing the decisions.

> The world doesn't seem to care much for waiting for existing languages
> to come out with the next certified version or standard unless that
> language is in current new deployment use on new projects (again, I
> don't see COBOL or BASIC or other languages getting a look in here,
> apart from C / C++). There was talk of FORTRAN making a comeback
> but it's probably too late for that language even though it's later
> versions have some nice features
>
> New project get written in new / current languages it seems. Existing
> ones get worked on in the language they were created with or the
> data migrated away to a new platform. Wholesale re-writes onto the
> same platform are becoming less on older platforms like VMS
>

Ask any business unit or C level exec if they could care less what dev language or even what OS platform the IT dept. uses to address their rapidly changing business requirements.

Weak management and lax company standards are what allows IT developers to make decisions on their own about what cool development language of the day they use to build new company applications.

> Someone once posted on these forums way way back when the
> excitement of VMS going to x86 was announced that applications were
> just as important. They were barely heard over all the x86 excitement
> chatter but I think their view is extremely important
>

That’s certainly not what I have heard. OpenVMS Customers and promoters have been through the VAX-Alpha and Alpha to IA64 migrations, so I don't think there are many that would say Apps are not important.

Porting to X86-64 is like having the key to the main door in an apartment complex. However, once you get past the main door, there are many more keys required to go anywhere in the Apt complex.

> After VMS-x86-64, then what? We have to have something more than
> just trying to stop customers eyeing the door. x86 only gives them less
> of a reason, what else will we need to do to keep them and more
> importantly, attract new ones or perhaps get some back that left
> reluctantly because of no uncertainly at the time
>

Very simple - yes, add more functionality, but at the heart of future IT decision making, it is all about cost reduction and depending on the Customer, being able to more quickly address rapidly changing business requirements.

As I have mentioned before, the last 10 years was all about HW cost reduction, but the next 10 years is all about SW cost reductions.

Even public cloud computing, aka outsourcing, on the surface is about flexibility, adaptability (insert other hype terms), but like traditional outsourcing initiatives, at the heart of interest in public cloud / outsourcing solutions is senior management looking to reduce head count, because IT staffing is approx. 60+% of their IT budget.

Big IT shop I was under contract with in 2015 is re-writing all of their current Solaris/Oracle apps in their next generation middleware/web environment to be Oracle / IBM SW free because they can no longer afford $25K per core licensing +15% annual support for their middleware and DB environment. They had no issue with the functionality of Oracle/IBM sw, but they realized when their future designs were all based on "how many cores" for each component, they knew they had to change their future model. They also realized that they fell under the umbrella of many customers who only use a small fraction of the total functionality of the Oracle products.

To put this in perspective - a dual 4 core on each server X86-64 platform can be put together for say $25K. Even with current (very high) OpenVMS licensing including clustering, this might add another $25K. Oracle licensing with Weblogic and enterprise Server DB costs would be in the range of $500K+. With RAC clustering, this would likely increase to $750K. Then add your mandatory annual 15% Oracle support costs.

If you are a CIO and your job depends on reducing future IT costs, this is not a hard decision to make.

In other words, similar to why many Custs migrated to X86-64 hw, they realized that Oracle / IBM alternatives are available today for a fraction of the cost. These alternatives may not provide all of the functionality of the Oracle/IBM solutions, but they are "good enough" (sound familiar?).

Yes, in the short term, Oracle / IBM sw solutions on X86-64 support for OpenVMS is important because many Customers need to support what they have today.

However, to address your question of what comes next, OpenVMS needs to develop solutions that provide much lower costs, more stable solutions, increased security, increased automation, and making it easier for developers have OpenVMS as their preferred platform.

One consideration is to make it simpler and quicker for developers to develop solutions.

Yes, there is lots of open source work to do, but keep in mind that when developing on Windows/Linux/Unix clustering, add node/deletes, data consistency, availability, data replication, data partitioning/sharding is handled at the APPLICATION level. With OpenVMS, most (not all) of this is handled at the OS level. Hence, once there are more open source options, a future positioning of OpenVMS might be to allow developers to focus on their core responsibility in terms of code functionality and optimization and leave the availability/data partitioning/replication/node mgmt. to the OS layer.

> Cluster revamping? (multi-tiered clusters? perhaps?). Security surely
> must feature highly as an area of focus. It's an area that business will
> pay money for. Modernising the development? Getting an open
> source DB migrated and frame-working open source building on VMS
> so that it isn't anywhere as painful and 'different'
>

Mostly agree .. although one needs to be careful about stating "companies are willing to pay for additional security". Yes, everyone says they want more security, but until they experience a major issue, most companies focus on getting solutions out the door and worry about security later. That’s the unfortunate reality.

Having stated this, being perceived as not being a secure solution or not having security specific processes and technologies in place, is a big reason for companies to not choose your platform to address new requirements (even if the true reason is that the decision maker has adopted other platform religion).

> Where I used to work, they are moving away from VMS. Data is being
> migrated to an Oracle system. Even with VSI taking the reigns of VMS
> has not changed their mind. When I spoke with someone recently
> about staying on VMS, he told me 'We just want uniform platforms
> and products to support". They have an unlimited license with Oracle,
> it's no additional cost to bring things under another Oracle product and
> they gain by having one less 'other' vendor to pay :-( Uniformity saves
> money, doing what everyone else is doing saves money
>

I would suggest that company is behind in where the industry is heading.

Imho, SW cost reductions is where the 800lb gorilla opportunity is in the future - not fattening the gorilla to be 1000lbs which makes it even harder to manage.

> Bundled cost / offerings is very attractive for certain companies with
> large IT spends. These environments are where small players are
> getting crushed
>

The drive to reduce IT costs is increasing exponentially. The project I am on now (huge govt initiative) is looking at all sorts of hyper-converged infrastructure solutions from a number of smaller companies. These solutions are very, very impressive - think drag-n-drop of VM's between VMware, KVM and Hyper-V.

I do agree bundled cost / simplified offerings is key to the future success of companies like VSI. With Customers pulling their hair out with complex and ultra-high cost licensing schemes from Oracle, Microsoft, IBM etc., there is a huge opportunity for VSI OpenVMS to evolve to be a low cost LA option - Linux Alternative. (ok, I made that last term up, but it sounded cool).

:-)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[John E. Malmberg]

It could be a good hobbyist project.

1. Get Python for VMS
2. Get the rust source.
3. See if any of the build procedures work.
4. Find a way to make them work.

Main obstacles that I see are:

* The Python on VMS code does not support Bash or the GNV environment as
a target for subprocess. There has been some improvements done there,
but I do not know if they are in available Python on VMS kits.

* Fully functional Python/Ruby/Java on VMS needs at least the libffi
library ported to VMS. This uses assembly language code which requires
knowing calling sequence better than I do. And all the existing code
for AXP is based on Tru64 source code.

I can not get the development python 3.x procedure to run the self tests
with out libffi on my AXP 8.4 VMS system.

I seem to have found code to make libffi build on VMS 8.4/IA64, but I
only have 1/2 the code working for VMS 8.4/Alpha.

So my guess is to get Rust ported, it will probably also need libffi,
and updates to the Python on VMS port.

I am currently working on getting GNV into maintainable components and
being able to build current upstream sources.

Regards,
-John
wb8tyw@qsl_network

[BillPedersen]

On Saturday, January 21, 2017 at 11:25:19 AM UTC-5, John E. Malmberg wrote:
> On 1/21/2017 5:54 AM, Hans Vlems wrote:
> > How available is Rust for VMS?
> > And if there is a kit, where can I get one?
> > Hans
> >
> > PS
> > I'm a poor hobbyist remember....
>
> It could be a good hobbyist project.
>
> 1. Get Python for VMS
> 2. Get the rust source.
> 3. See if any of the build procedures work.
> 4. Find a way to make them work.
>
> Main obstacles that I see are:
>
> * The Python on VMS code does not support Bash or the GNV environment as
> a target for subprocess. There has been some improvements done there,
> but I do not know if they are in available Python on VMS kits.

Well, it does if you use the subprocess.py available on the SourceForge VMS-Ports project. I have submitted code to JFP for inclusion with his VMS Python 2.x distribution but I have not taken the time to see if it has actually made it into the mix. If you run it from Bash it knows to use Bash and if you run it from DCL it knows to use DCL. The code is such that it does not expose the Bash command line sequences to DCL to prevent breakage.

It "supports" subprocesses as best we can given the differences between Linux/Unix and VMS. By this I mean that it supports it sufficiently well to run the newest build for Samba on VMS with little or no modification of the Samba build procedure, now written in Python - WAF.

Perl on the other hand is an different story. It definitely does not yet properly support Bash. On the other hand I have been able to fix the Samba build to support Bash - one script needed changes. This is in contrast to Perl needing to be changed in at least four different places to support subprocesses properly under Bash.

>
> * Fully functional Python/Ruby/Java on VMS needs at least the libffi
> library ported to VMS. This uses assembly language code which requires
> knowing calling sequence better than I do. And all the existing code
> for AXP is based on Tru64 source code.
>
> I can not get the development python 3.x procedure to run the self tests
> with out libffi on my AXP 8.4 VMS system.
>
> I seem to have found code to make libffi build on VMS 8.4/IA64, but I
> only have 1/2 the code working for VMS 8.4/Alpha.
>
> So my guess is to get Rust ported, it will probably also need libffi,
> and updates to the Python on VMS port.
>
> I am currently working on getting GNV into maintainable components and
> being able to build current upstream sources.

I fully agree with John on the need to get some help to implement an effect libffi for AXP to help with the ports of newer scripting languages and tools. We could use some help there.

I am looking to get back to my Samba 4.x port in the next couple months. The effort stalled due to personal issues. Things are moving along so when I have some more progress there I will let folks know.

Best,
Bill.

[David Froble]

What I find amusing is that for some people, if they don't see something, they
then think nobody else sees it either.

While a person's perceptions are his reality, personal reality has little
bearing on actual reality.

I've seen actual instances where somebody convinced management that they had to
do a port off VMS, and it cost so much, the business didn't survive. Too bad
those people survive the business they killed ....

[Jan-Erik Soderholm]

Den 2017-01-21 kl. 16:39, skrev Kerry Main:

> To put this in perspective - a dual 4 core on each server X86-64

> platform can be put together for say $25K...

At the IKEA meeting in November, a question was rasied from one
guy from HPE regarding the interest for dual-core X86-64 servers.

It is, as I understood, easy to disable cores in an Xeon processor
to get a system with any number of cores.

The reason for this is of course that any dual-core Xeon would
have enough power for a customer coming from an Itanium or even
more so if coming from an Alpha environment.

Then you could go from, say, an dual-CPU Alpha to a dual-core
X86-64 with no raise in costs for the "by-core" licenses. And
still get a lot more processing power from the system.

As I remember, their was a number of hands in the air.

And as long as you keep your Cobol or Basic applications and do
not try to migrate them to (say) Java, you will have all processor
power you need in any X86-64 system... :-)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of

> Jan-Erik Soderholm via Info-vax
> Sent: January 21, 2017 12:04 PM
> To: info...@rbnsn.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>
> Subject: [Info-vax] Licensing and cores (was: Rust and VMS)
>
> Den 2017-01-21 kl. 16:39, skrev Kerry Main:
>
> > To put this in perspective - a dual 4 core on each server X86-64
> > platform can be put together for say $25K...
>
> At the IKEA meeting in November, a question was rasied from one guy
> from HPE regarding the interest for dual-core X86-64 servers.
>
> It is, as I understood, easy to disable cores in an Xeon processor
to get
> a system with any number of cores.
>
> The reason for this is of course that any dual-core Xeon would have
> enough power for a customer coming from an Itanium or even more
> so if coming from an Alpha environment.
>

They said the same thing about IA64 in the early days.

Reality is while X86-64 performance should be better in most
scenario's, I do not expect really significant gains of X86-64 over
current IA64 I4 offerings.

> Then you could go from, say, an dual-CPU Alpha to a dual-core
> X86-64 with no raise in costs for the "by-core" licenses. And still
get a
> lot more processing power from the system.
>
> As I remember, their was a number of hands in the air.
>
> And as long as you keep your Cobol or Basic applications and do not
try
> to migrate them to (say) Java, you will have all processor power you
> need in any X86-64 system... :-)
>

Reality is that most Alpha/IA64 customers moving to X86-64 are not
going to do so because they want better performance.

While there are always exceptions, likely 75% of Alpha/IA64 OpenVMS
Cust's have Apps that run just fine on Alpha / IA64 servers. Heck, one
could likely state that, assuming it was ported, 75% of most Apps
today would run just fine with acceptable performance on ANY current
server HW platform from ANY vendor.

The reasons for Custs moving to X86-64 are going to do so for reduced
maint costs, reduced risks of parts availability and being able to
further standardize their server HW platforms and server mgmt.
solutions. As an example, one would assume that at some point, OpenVMS
X86-64 servers would simply plug into X86-64 mgmt. platforms like HP's
OneView framework. The HW support would already be there and only the
OS specific plug-ins would be required. Same would apply to OpenVMS
running on Dell X86-64 servers.

Reference:
https://www.hpe.com/ca/en/integrated-systems/software.html

Now, having stated all of this, one HUGE reason for OpenVMS Oracle
Customers on Alpha/IA64 to move to OpenVMS X86-64 will be to reduce
their Oracle costs by approx. 50%. One needs to remember that the
Oracle licencing is based on the type of HW platform and includes a
Processor Core Factor that gets applied to the total Oracle costs on
the target HW platform.

For Alpha/IA64 (and other non-Oracle HW), that multiple is 1.0. With
X86-64, that multiplier is 0.5.

The Oracle cost reductions from Alpha/IA64 will likely more than pay
for any associated porting costs of their applications. Especially
when looking at multi-year costs and savings.

[Simon Clubley]

On 2017-01-20, Stephen Davies <jovi...@gmail.com> wrote:
> On Thursday, 19 January 2017 03:31:04 UTC, Arne Vajhøj wrote:
>
>> PS: I think Ada's current usage level is low enough to make
>> using Ada a risk.
>
> My place of work has almost completely abandoned VMS but still
> uses Ada widely. I suspect (but may be completely off the mark)
> that VMS's future is more at risk than Ada's.
>

One of the interesting things I have noticed is that VSI have not
yet formally announced their Ada plans.

I don't know if this is simply due to ongoing discussions with
AdaCore or whether there are no longer enough Ada users left on
VMS for it to be viable for AdaCore to provide an Ada compiler
on x86-64.

> To me, it seems like it would be nice to have a safe/secure
> OS written in a safe/secure language. Of course, I don't see
> potential VMS customers being swayed by the choice of
> programming language.

You will get absolutely _no_ argument from me on that one; however
the compiler availability situation needs to be sorted out first
and those compilers need to be freely available and with no generated
code redistribution restrictions if uptake of this language is to
be encouraged.

[Simon Clubley]

On 2017-01-21, IanD <iloveo...@gmail.com> wrote:

> Your not going to attract a new IT grad with COBOL (throwing money
> at them aside of course)
>

Actually, all you need to do is to tell the hipsters that COBOL
is so old that it's now become cool again. :-)

Don't forget these hipsters are the ones who think it's some
fashionable/cool statement to use typewriters in a public place
in the 21st century.

No, I don't get that one either.

[Simon Clubley]

On 2017-01-20, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2017-01-19 02:45:47 +0000, Simon Clubley said:
>
>> Using a language in VMS itself which comes from an external source, and
>> which doesn't have that formal weight behind it, is utterly unthinkable
>> in a product designed for the uses that VMS is used for.
>
> Oddly enough, Bliss arose at CMU, and was then adopted by folks at DEC.
>

I was thinking more about the expected standards in today's world.

> http://www.cs.tufts.edu/%7Enr/cs257/archive/ronald-brender/bliss.pdf
>
> But as to your point, if the full source code is available for the
> compiler chain — in the case of Rust, it is — and if there's
> familiarity with the internals of the implementation — the code
> generation for multiple commercial languages on OpenVMS x86-64 is
> expected to be built using the same LLVM back-end that Rust also shares
> — I fail to see a particular issue here.
>

[Pick one of either 1a) or 1b)]

1a) Employees need to learn the language if it's not a generally
used language and it's only used by one employer. Good luck
getting employees to put that on their CV. BTW, who else uses
Bliss these days ?

or

1b) If it's a generally used language but the employer is stuck
on a specific version, then that version is going to stagnate
while the rest of the community advances. As an example, I refer
you to your comments about the version of C in use in the VMS
world.

2) The language might have issues in it because it hasn't been
through a formal process. BTW, doesn't Bliss have issues with
the dot character ? Probably the kind of thing which was thought
to be "clever" at the time, but is now recognised as a language
feature which causes reliability issues when writing new code
(as I understand it anyway).

> Track the languages chosen — Rust or otherwise — or fork it and use
> what works. If the chosen language no longer works and/or if the
> standards aren't helpful and/or if the local source code fork is no
> longer sufficient for local needs, then choose a different language and
> use that. Which is what I was originally stating around C and Bliss
> for that matter. Performing an honest self-examination around
> implementations and assumptions, as that helps avoid unnecessarily or
> unknowingly accreting disadvantages.
>

So basically, you are saying that once either the local version of
the language stagnates too much or tracking the language changes
becomes too much work, VSI need to choose another language and start
over with that new language.

Wouldn't it be better to choose a language established on a formal
standards track instead where compilers which can compile code from
various versions of the language is a standard feature ?

[David Froble]

Jan-Erik Soderholm wrote:
> Den 2017-01-21 kl. 16:39, skrev Kerry Main:
>
>> To put this in perspective - a dual 4 core on each server X86-64
>> platform can be put together for say $25K...
>
> At the IKEA meeting in November, a question was rasied from one
> guy from HPE regarding the interest for dual-core X86-64 servers.
>
> It is, as I understood, easy to disable cores in an Xeon processor
> to get a system with any number of cores.

Ayep! And this leads into a little story, for those unaware.

AMD's Phenom chip is a 4 core design. Now, sometimes not every core tests out
Ok. What to do? Why, turn off 2 cores and sell it as a Calypso chip, which was
so successful that they turned off perfectly good cores because of the market
demand for the Calypso chip.

So then, what's a motherboard mfg to do? Why, include capability to turn off,
or ON, cores on a chip. More than one person has bought a Calypso chip and
turned it into a Phenom.

Of course, one doesn't know which he bought, a perfectly good 4 core chip, or a
chip with one or two defective cores. Nor would it be readily apparent that a
core was bad without AMD's testing capability.

:-)

[Stephen Hoffman]

On 2017-01-21 22:10:31 +0000, Simon Clubley said:

> On 2017-01-20, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

>> Track the languages chosen — Rust or otherwise — or fork it and use
>> what works. If the chosen language no longer works and/or if the
>> standards aren't helpful and/or if the local source code fork is no
>> longer sufficient for local needs, then choose a different language and
>> use that. Which is what I was originally stating around C and Bliss
>> for that matter. Performing an honest self-examination around
>> implementations and assumptions, as that helps avoid unnecessarily or
>> unknowingly accreting disadvantages.
>
> So basically, you are saying that once either the local version of the
> language stagnates too much or tracking the language changes becomes
> too much work, VSI need to choose another language and start over with
> that new language.

Nope. I'm suggesting maintaining awareness of what's under
development, and particularly what might provide advantages, and making
an effort to avoid prejudicing the comparisons based on past decisions
and past assumptions. Because becoming hidebound in development
practices or choices of tools doesn't usually work out beneficially.

https://en.wikipedia.org/wiki/Escalation_of_commitment

Certainly too much change too quickly — churning, flailing, indecision
and suchlike — is bad.

But over the longer term, a rate of change that's too low and too slow
— getting stuck — is just as bad for any IT-related endeavor. If not
worse.

Getting back to my earlier comments, I'm not entirely fond of C or
Macro32 or Bliss here, as all three have various issues. That's
having written more than a little code in each. And having coded bugs
in and debugged bugs in each, too. I'd prefer to look around, and to
learn if there are better ways to use those, better tools — I've really
become fond of the better IDEs, as those are more effective than
edit-compile-link-debug cycle — or partially or wholly different
approaches that work better.

> Wouldn't it be better to choose a language established on a formal
> standards track instead where compilers which can compile code from
> various versions of the language is a standard feature ?

Nope. I'm suggesting maintaining awareness of what's under
development — both within committees, as well as with the sorts of
projects that might eventually themselves become wholly new standards —
and particularly around what is in development or early deployment that
might be a competitive advantage. If you wait, competitive advantages
tend to evaporate; you're closer to mainstream or — by the time the
changes can be instituted and deployed in production — potentially well
toward the trailing edge in your practices. When you're perpetually
catching up with the rest. (There can be a market toward the trailing
edge too, but it's not a growth market.)

Few committees are known for particularly ground-breaking new work.
It happens, but it's not common. For new work and new programming
languages, these efforts almost always takes place outside of
committees. Folks that have problems or ideas or approaches that no
other package or tool or interface provides, too.

Further along that whole product creation process, committees then tend
to develop, and compatibility and familiarity and existing stakeholders
become far more important to the processes and discussions. If you
prefer external validation or applicable standards as part of your
local investigations and product or tool or process choices, you're
trading off a perception of and a preference for what may be a
perceived-safer lower-risk choice, for what will also be lower
competitive advantage. Or quite possibly no advantage, depending on
how long you've waited before moving.

Committees are no panacea, either. This particularly if some of the
stakeholders involved might want some other outcome, or might want to
delay the outcome, or to maintain some alternative approach or
advantage or standard that the folks involved might prefer or already
possess. The committee processes — even the best ones — can look
rather like a sausage factory, and even the best committees can and
variously do produce documents that include some pretty serious
compromises or workarounds. (Some meetings might remind attendees of
the OSS Simple Sabotage Manual too, but I digress.)

For competitive and new-development and advanced development work, I'd
just prefer to be avoid restricting the investigation. I'd prefer to
be looking around and comparing and determining whether there are
advantages to be gained. Whether that's from an existing or new
committee, or from some other source entirely. Whether that's for my
own end-use, or for the products being produced.

https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf

[Stephen Hoffman]

https://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/

[Bob Koehler]

In article <o5vsb0$1lgq$1...@news.kjsl.com>, hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>
> Indeed. Much of it is used by people actually doing real calculations,
> instead of trying to be cool. :-)

About half the Forteran users I know are still writing in Fortran 77.
The rest have moved on past the standards supported by VMS. But I
really think VSI has higher priorities.

[Bob Koehler]

In article <o601ua$i35$1...@dont-email.me>, "John E. Malmberg" <wb8...@qsl.net_work> writes:
>
> It could be a good hobbyist project.
>
> 1. Get Python for VMS
> 2. Get the rust source.
> 3. See if any of the build procedures work.
> 4. Find a way to make them work.

Oh, somehow I think that getting a useable compiler ported is much more
than getting it to build. The above seems only to be a recipie for a
cross compiler, which would generate code that runs on some other
platform.

[Jan-Erik Soderholm]

No.

The Python scripts (which acts like some make environment)
will of course call native compilers. They *could* also call
cross-compilers, but that is probably not the normal way.

[Ian Miller]

Rust is sooo last week. Hip people are pushing Nim http://nim-lang.org/ as the new wonder programming language

next week, who knows :-)

[Simon Clubley]

On 2017-01-23, Ian Miller <gx...@uk2.net> wrote:
> Rust is sooo last week. Hip people are pushing Nim http://nim-lang.org/ as
> the new wonder programming language
>

Thank you Ian; you have just made my point for me. :-)

> next week, who knows :-)

Indeed. :-)

On a more serious point however, it does re-enforce the point I am
making. I want to see something better than C emerge for operating
system/kernel development but you need guarantees that whatever
replaces C is going to be around and supported for a long time.

Otherwise, you are either going to be in the crazy situation of
re-writing code for no good reason when something more fashionable
comes along or you are going to have multiple (and fading into
disuse) languages present within the kernel code.

At some point, people have to stop following fashions and become
engineers instead, especially when it comes to something as serious
as operating system development which is at the core of the ecosystem
built on top of it.

[Paul Sture]

On 2017-01-23, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2017-01-23, Ian Miller <gx...@uk2.net> wrote:
>> Rust is sooo last week. Hip people are pushing Nim http://nim-lang.org/ as
>> the new wonder programming language
>>
>
> Thank you Ian; you have just made my point for me. :-)
>
>> next week, who knows :-)
>
> Indeed. :-)
>
> On a more serious point however, it does re-enforce the point I am
> making. I want to see something better than C emerge for operating
> system/kernel development but you need guarantees that whatever
> replaces C is going to be around and supported for a long time.
>
> Otherwise, you are either going to be in the crazy situation of
> re-writing code for no good reason when something more fashionable
> comes along or you are going to have multiple (and fading into
> disuse) languages present within the kernel code.
>
> At some point, people have to stop following fashions and become
> engineers instead, especially when it comes to something as serious
> as operating system development which is at the core of the ecosystem
> built on top of it.

"We find that whole communities suddenly fix their minds upon one object,
and go mad in its pursuit; that millions of people become simultaneously
impressed with one delusion, and run after it, till their attention is
caught by some new folly more captivating than the first."

"Extraordinary Popular Delusions and the Madness of Crowds"
Charles Mackay, 1841

<https://en.wikipedia.org/wiki/Extraordinary_Popular_Delusions_and_the_Madness_of_Crowds>


--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

[Phillip Helbig (undress to reply)]

In article <+zPp6V...@eisner.encompasserve.org>,

koe...@eisner.nospam.decuserve.org (Bob Koehler) writes:

> In article <o5vsb0$1lgq$1...@news.kjsl.com>, hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
> >
> > Indeed. Much of it is used by people actually doing real calculations,
> > instead of trying to be cool. :-)
>
> About half the Forteran users I know are still writing in Fortran 77.
> The rest have moved on past the standards supported by VMS.

In some cases because VMS doesn't support anything later than F95?

> But I
> really think VSI has higher priorities.

DEC FORTRAN used to be the gold standard. People who had never used VMS
learned it because the compilers were better than the competition. And
VMS's language-neutral (compared to C-favouring unix) is nice. With
x86, VMS will move to hardware which is (more) commodity. Much
high-performance computing is number crunching, and Fortran is still
very vibrant there. Even if it doesn't pay for itself in the narrower
sense, it might be good advertising, similar to a car manufacturer
competing in Formula-One racing.

[Stephen Hoffman]

On 2017-01-23 18:42:55 +0000, Simon Clubley said:

> On 2017-01-23, Ian Miller <gx...@uk2.net> wrote:
>> Rust is sooo last week. Hip people are pushing Nim http://nim-lang.org/ as
>> the new wonder programming language
>>
>
> Thank you Ian; you have just made my point for me. :-)
>
>> next week, who knows :-)
>
> Indeed. :-)

Yes, and I'm *certain* it'll be using committee-generated
standards-compliant Ada, of course.

> On a more serious point however, it does re-enforce the point I am
> making. I want to see something better than C emerge for operating
> system/kernel development but you need guarantees that whatever
> replaces C is going to be around and supported for a long time.

There's always a reason to not adapt and to not adopt a change, of
course. The classic DEC equivalent to this approach was known as the
"Product Prevention Committee". By the time any of these decisions
become a (mostly, probably) safe choice, you've lost most of the
opportunity and squandered more than a little of the potential savings,
too.

> Otherwise, you are either going to be in the crazy situation of
> re-writing code for no good reason when something more fashionable
> comes along or you are going to have multiple (and fading into disuse)
> languages present within the kernel code.

Yeah, because there's clearly been a suggestion in my postings that the
existing Bliss and C and Macro32 code be rewritten. That obviously
already happened when C was picked decades ago, and which is why
OpenVMS development rewrote all the existing Bliss and Macro32 code, of
course.

> At some point, people have to stop following fashions and become
> engineers instead, especially when it comes to something as serious as
> operating system development which is at the core of the ecosystem
> built on top of it.

1. Ignore what others and customers are doing, using
2. ?
3. Profit!

If any project wants to wait ten or twenty years for standards to
become accepted and published, the project is almost never going to
accrue any particular competitive benefits from the changes. Such
projects are always going to be chasing what others are doing and
using, and the effort is almost inherently going to cost more, too;
opportunity costs arise. There are certainly good reasons to be
conservative around changes — projects involving life safety are one
example, for instance — but those same folks damned well better be
looking around anyway, lest their own caution itself leads to risks.
But not looking around? That's just utterly stupid.

https://en.wikipedia.org/wiki/Opportunity_cost

[Bob Koehler]

In article <o65q9o$969$1...@news.kjsl.com>, hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>
> DEC FORTRAN used to be the gold standard.

Yes, I can remember when IBM, HP, and Sun were all claiming that
their compilers were "VAX Fortran compatable".

Those were the days.

[Simon Clubley]

On 2017-01-23, Paul Sture <nos...@sture.ch> wrote:
>
> "We find that whole communities suddenly fix their minds upon one object,
> and go mad in its pursuit; that millions of people become simultaneously
> impressed with one delusion, and run after it, till their attention is
> caught by some new folly more captivating than the first."
>
> "Extraordinary Popular Delusions and the Madness of Crowds"
> Charles Mackay, 1841
>
><https://en.wikipedia.org/wiki/Extraordinary_Popular_Delusions_and_the_Madness_of_Crowds>
>

That, Paul, sums up this industry perfectly. :-(

Thanks,

[Simon Clubley]

On 2017-01-23, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2017-01-23 18:42:55 +0000, Simon Clubley said:
>
>> Otherwise, you are either going to be in the crazy situation of
>> re-writing code for no good reason when something more fashionable
>> comes along or you are going to have multiple (and fading into disuse)
>> languages present within the kernel code.
>
> Yeah, because there's clearly been a suggestion in my postings that the
> existing Bliss and C and Macro32 code be rewritten. That obviously
> already happened when C was picked decades ago, and which is why
> OpenVMS development rewrote all the existing Bliss and Macro32 code, of
> course.
>

So you are into the multiple and fading into disuse languages present
within the kernel code option.

Unlike some of the modern fashionable languages there was a very good
reason to choose Macro-32 originally (because of the period in which
VMS was created) and then to goto C for new work 15 years later.

However, I strongly suspect VSI are spending a good chunk of money
developing it's Macro-32 compiler for x86-64 because of the need to
support VMS's existing Macro-32 code. I also suspect it's a lot easier
to work on the C code in VMS than it is the original Macro-32 code
(which also translates into cost savings).

>> At some point, people have to stop following fashions and become
>> engineers instead, especially when it comes to something as serious as
>> operating system development which is at the core of the ecosystem
>> built on top of it.
>
> 1. Ignore what others and customers are doing, using
> 2. ?
> 3. Profit!
>

The number 2 in this list is "Evaluate but wait and see what happens
to the current fashionable language of the month before deciding to
use it".

> If any project wants to wait ten or twenty years for standards to
> become accepted and published, the project is almost never going to
> accrue any particular competitive benefits from the changes. Such
> projects are always going to be chasing what others are doing and
> using, and the effort is almost inherently going to cost more, too;
> opportunity costs arise. There are certainly good reasons to be

> conservative around changes ? projects involving life safety are one
> example, for instance ? but those same folks damned well better be

> looking around anyway, lest their own caution itself leads to risks.
> But not looking around? That's just utterly stupid.
>
> https://en.wikipedia.org/wiki/Opportunity_cost
>

The language is an implementation tool and there are some tools
better than the most popular tool (C) and which can help you
write better and more secure code, but in the end it's what you
create with the tool that matters.

As I've mentioned previously, the same language has been used in
operating systems ranging from an all-or-nothing security model
with a monolithic kernel, to a fine grained security model in
a monolithic kernel through to microkernel based operating systems
with formal security in mind.

[Stephen Hoffman]

On 2017-01-24 18:49:51 +0000, Simon Clubley said:

> On 2017-01-23, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>> On 2017-01-23 18:42:55 +0000, Simon Clubley said:
>>
>>> Otherwise, you are either going to be in the crazy situation of
>>> re-writing code for no good reason when something more fashionable
>>> comes along or you are going to have multiple (and fading into disuse)
>>> languages present within the kernel code.
>>
>> Yeah, because there's clearly been a suggestion in my postings that the
>> existing Bliss and C and Macro32 code be rewritten. That obviously
>> already happened when C was picked decades ago, and which is why
>> OpenVMS development rewrote all the existing Bliss and Macro32 code, of
>> course.

For those following along at home, that was sarcasm. OpenVMS
development has not rewritten existing and working code, as a rule.
New work uses C, older work and maintenance preserves the Bliss or
Macro32 barring some specific reason to rewrite the code.

> So you are into the multiple and fading into disuse languages present
> within the kernel code option.

Nope. I'd prefer otherwise, but rewrites are intractable short of
strangulation-like approaches.

> Unlike some of the modern fashionable languages there was a very good
> reason to choose Macro-32 originally (because of the period in which
> VMS was created) and then to goto C for new work 15 years later.

C being immutable and always perfect, will of course be the pinnacle of
software development choices. BTW, sarcasm.

> However, I strongly suspect VSI are spending a good chunk of money
> developing it's Macro-32 compiler for x86-64 because of the need to
> support VMS's existing Macro-32 code. I also suspect it's a lot easier
> to work on the C code in VMS than it is the original Macro-32 code
> (which also translates into cost savings).

For those following along at home, a Macro32 compiler is being
implemented for x86-64, because that was deemed a better strategy than
rewriting the Macro32 code.

>>> At some point, people have to stop following fashions and become
>>> engineers instead, especially when it comes to something as serious as
>>> operating system development which is at the core of the ecosystem
>>> built on top of it.
>>
>> 1. Ignore what others and customers are doing, using
>> 2. ?
>> 3. Profit!
>>
>
> The number 2 in this list is "Evaluate but wait and see what happens to
> the current fashionable language of the month before deciding to use
> it".

Which is why I'd suggested looking at it and other available choices,
and taking a careful look at where C falls down.

>> If any project wants to wait ten or twenty years for standards to
>> become accepted and published, the project is almost never going to
>> accrue any particular competitive benefits from the changes. Such
>> projects are always going to be chasing what others are doing and
>> using, and the effort is almost inherently going to cost more, too;
>> opportunity costs arise. There are certainly good reasons to be
>> conservative around changes ? projects involving life safety are one
>> example, for instance ? but those same folks damned well better be
>> looking around anyway, lest their own caution itself leads to risks.
>> But not looking around? That's just utterly stupid.
>>
>> https://en.wikipedia.org/wiki/Opportunity_cost
>>
>
> The language is an implementation tool and there are some tools better
> than the most popular tool (C) and which can help you write better and
> more secure code, but in the end it's what you create with the tool
> that matters.

If you're working on art, sure.

If it's a commercial product, it's more often about revenue,
opportunity cost, risk and various other considerations.

> As I've mentioned previously, the same language has been used in
> operating systems ranging from an all-or-nothing security model with a
> monolithic kernel, to a fine grained security model in a monolithic
> kernel through to microkernel based operating systems with formal
> security in mind.

C is crusty, problematic, and — like any other tool — has some nasty
trade-offs. Ada is in the wrong part of the adoption curve. Whether
Rust is the path forward? Donno.

Change has costs. Not adapting to changes has higher costs. (I'm
currently dealing with that in another context, but I digress.) Not
looking around? That's one of the most expensive mistakes possible.

[Stephen Davies]

On Tuesday, 24 January 2017 19:19:06 UTC, Stephen Hoffman wrote:

> C is crusty, problematic, and — like any other tool — has some nasty
> trade-offs. Ada is in the wrong part of the adoption curve. Whether
> Rust is the path forward? Donno.

And what part of the adoption curve is VMS in?

[Stephen Hoffman]

Looking back, that's clear. Looking forward? Donno. That depends
greatly on the outcomes of existing and new opportunities that might
match with the decisions of and the efforts being expended by VSI.

[John E. Malmberg]

According the wild wild web, rust is now passe.

Need to move to something called "nim".

https://nim-lang.org/

Of course it looks like it also needs libffi ported for full functionality.

Regards,
-John
wb8...@qsl.net_work

[hb]

On 01/21/2017 05:25 PM, John E. Malmberg wrote:
> I seem to have found code to make libffi build on VMS 8.4/IA64, but I
> only have 1/2 the code working for VMS 8.4/Alpha.

I hacked an OLB with libffi code for VMS 8.3/Alpha, including ffi_call
and ffi_closure. It seems to work with the few tests/examples I have
(calling CRTL's puts, printf - 2 arguments, atof, sin and closure for
puts). I'm looking for more tests/examples. Source code or pointers to
are welcome.

[IanD]

On Sunday, January 22, 2017 at 1:11:43 AM UTC+11, John Reagan wrote:
> On Saturday, January 21, 2017 at 1:21:49 AM UTC-5, IanD wrote:
>
> > The world doesn't seem to care much for waiting for existing languages to come out with the next certified version or standard unless that language is in current new deployment use on new projects (again, I don't see COBOL or BASIC or other languages getting a look in here, apart from C / C++). There was talk of FORTRAN making a comeback but it's probably too late for that language even though it's later versions have some nice features
>
> I get as many questions about Fortran futures as anything else. There is still a pretty large Fortran community.

Funny you should mention FORTRAN

I was looking at the wiki about the latest FORTRAN standard and it has some pretty good stuff in it (I wouldn't look at the official standard, it would be well over my head)

If only people had ported some of the libraries floating around that enable easier data interchange to it, perhaps it might have got more traction beyond the scientific arena?

[Phillip Helbig (undress to reply)]

In article <f105c314-0620-41a8...@googlegroups.com>, IanD

<iloveo...@gmail.com> writes:

> Funny you should mention FORTRAN
>

> I was looking at the wiki about the latest FORTRAN standard and it has some=
> pretty good stuff in it (I wouldn't look at the official standard, it woul=

> d be well over my head)

Like VMS, Fortran's drop in popularity is not due to lack of quality,
but in self-appointed dudes determining what should be cool.

> If only people had ported some of the libraries floating around that enable=
> easier data interchange to it, perhaps it might have got more traction bey=
> ond the scientific arena?

Modern Fortran has a standardized interface to C.

On VMS, it is relatively easy to mix languages.

[Simon Clubley]

On 2017-02-21, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>
> On VMS, it is relatively easy to mix languages.
>

Traditional procedural languages anyway...

[Johnny Billquist]

On 2017-02-22 14:18, Simon Clubley wrote:
> On 2017-02-21, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>>
>> On VMS, it is relatively easy to mix languages.
>>
>
> Traditional procedural languages anyway...

I seem to remember that VAX+LISP played nicely as well...

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[David Froble]

Simon Clubley wrote:
> On 2017-02-21, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>> On VMS, it is relatively easy to mix languages.
>>
>
> Traditional procedural languages anyway...
>
> Simon.
>

It's all ones and zeros.

If something like the VMS argument passing standard is used, and the two
routines use the same definition of the variables used, then it should be able
to work.

Now, if you want to do something such as pass big-endian data to a routine that
expects small endian data, well, it gets a bit harder ....

As an example. While Basic doesn't support zero terminated strings, and passes
ByRef, ByValue, or ByDesc, I can build a zero terminated string, and using the
LOC() function, pass the address of the constructed data ...

[Simon Clubley]

On 2017-02-22, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2017-02-21, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>>> On VMS, it is relatively easy to mix languages.
>>>
>>
>> Traditional procedural languages anyway...
>>
>> Simon.
>>
>
> It's all ones and zeros.
>
> If something like the VMS argument passing standard is used, and the two
> routines use the same definition of the variables used, then it should be able
> to work.
>

I can see you have never done any OO programming David.

The following error message shows what a full-blown C++ identifier looks
like by the time it reaches the assembler/linker:

/tmp/ccX3K3yT.s: Assembler messages:
/tmp/ccX3K3yT.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'

There's simply no real _direct_ compatibility between normal C++ objects
and the VMS APIs. However, the C++ designers were aware of this problem
with interfacing in general so they implemented an extern C capability
so that things declared within the scope of extern C are treated as
normal C calls and you can pass variables using normal C conventions.

Other OO language designers are also aware of this issue and they also
tend to offer a C style calling interface built into the language when
making calls outside of the language in question.

IOW, this means that the VMS way of doing things is rapidly becoming
obsolete and the new inter-language calling convention these days is
the C style calling convention. Not exactly great given what VMS has
offered, but it has the major advantage that your inter-language
compatibility now includes object orientated languages, unlike on VMS.

> Now, if you want to do something such as pass big-endian data to a routine that
> expects small endian data, well, it gets a bit harder ....
>
> As an example. While Basic doesn't support zero terminated strings, and passes
> ByRef, ByValue, or ByDesc, I can build a zero terminated string, and using the
> LOC() function, pass the address of the constructed data ...

And what if you wanted to write directly into an std::string from
Basic, while also automatically extending the string as required ?

You can't, which is why language designers are restricting themselves
to providing an extern C style interface.

Simon.

PS: In case anyone is interested, this is the full error message from
the above example:

/tmp/ccX3K3yT.s: Assembler messages:
/tmp/ccX3K3yT.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'
make[4]: *** [array_type_info.lo] Error 1
make[4]: Leaving directory `/work/vms-cc/obj-gcc-7-20170129/alpha-dec-vms/libstdc++-v3/libsupc++'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/work/vms-cc/obj-gcc-7-20170129/alpha-dec-vms/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/work/vms-cc/obj-gcc-7-20170129/alpha-dec-vms/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2

This is the _current_ :-) blocker for building a cross-compiled gcc
for VMS Alpha. Looks like an Alpha code generation problem, and no,
I have no desire to learn enough of gcc internals to begin to
diagnose the problem.

PPS: I've never used C++ on VMS. Does it provide a class similar
to std::string that can be used to directly interface with VMS
descriptors ?

[Simon Clubley]

On 2017-02-22, Johnny Billquist <b...@softjar.se> wrote:
> On 2017-02-22 14:18, Simon Clubley wrote:
>> On 2017-02-21, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>>>
>>> On VMS, it is relatively easy to mix languages.
>>>
>>
>> Traditional procedural languages anyway...
>
> I seem to remember that VAX+LISP played nicely as well...
>

I never used VAX Lisp so I will take your word for it. :-)

[Stephen Hoffman]

On 2017-02-23 14:26:58 +0000, Simon Clubley said:

> PPS: I've never used C++ on VMS. Does it provide a class similar to
> std::string that can be used to directly interface with VMS descriptors
> ?

Nope. Not integrated. Neither has C. Nor has IP been, for all
practical purposes. But I digress. It can be hacked together, of
course. It's all just more glue code, after all.

Looking the other direction, the OpenVMS system APIs aren't (yet?)
object-accessible akin to .NET and the CLR. That's what the OpenVMS
calling standard effectively grew up into.

[Simon Clubley]

On 2017-02-23, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2017-02-23 14:26:58 +0000, Simon Clubley said:
>
>> PPS: I've never used C++ on VMS. Does it provide a class similar to
>> std::string that can be used to directly interface with VMS descriptors
>> ?
>
> Nope. Not integrated. Neither has C. Nor has IP been, for all
> practical purposes. But I digress. It can be hacked together, of
> course. It's all just more glue code, after all.
>

Yes, having done lots of descriptor handling code in C under VMS,
I am well aware of the situation there unfortunately. However, what
I didn't know was if DEC/CPQ/HP had created additional classes for
their own C++ compiler which made it easier to handle descriptor
based strings.

Simon.

[IanD]

On Friday, February 24, 2017 at 3:37:00 AM UTC+11, Stephen Hoffman wrote:

<snip>

> Looking the other direction, the OpenVMS system APIs aren't (yet?)
> object-accessible akin to .NET and the CLR. That's what the OpenVMS
> calling standard effectively grew up into.
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

I think what MS did with their CLR is very forward thinking. A rather smart way to tie together all their languages under the same banner and have all the goodness of a java like VM for deployment. Add in managed and unmanaged code to increase quality as well (that's the theory at least)

Add in aspects like ironpython etc and other scripting languages and they have effectively brought everything under the same roof

>>> That's what the OpenVMS calling standard effectively grew up into.

I'll re-quote that sentence again because it's spot on

Grew up being the key words IMO. They effectively redid everything they had, which at the time wasn't overly broken and moved their entire basis into an OO based world and integrated it together - love em or hate em but I think this was a bold move by MS and showed great vision

Where is the vision for VMS? I have not seen much mention of OO as a direction other than a revamp of the C++ compiler and piggybacking on Java.

I know it's early days but I do wonder if the powers that be are thinking along the lines of a revamp of the heart of VMS at some point in time akin to the major work that MS did...

[David Froble]

IanD wrote:
> On Friday, February 24, 2017 at 3:37:00 AM UTC+11, Stephen Hoffman wrote:
>
> <snip>
>
>> Looking the other direction, the OpenVMS system APIs aren't (yet?)
>> object-accessible akin to .NET and the CLR. That's what the OpenVMS
>> calling standard effectively grew up into.
>>
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
>
> I think what MS did with their CLR is very forward thinking. A rather smart
> way to tie together all their languages under the same banner and have all
> the goodness of a java like VM for deployment. Add in managed and unmanaged
> code to increase quality as well (that's the theory at least)
>
> Add in aspects like ironpython etc and other scripting languages and they
> have effectively brought everything under the same roof
>
>>>> That's what the OpenVMS calling standard effectively grew up into.
>
> I'll re-quote that sentence again because it's spot on

And still works quite well, for those things that respect it.

> Grew up being the key words IMO. They effectively redid everything they had,
> which at the time wasn't overly broken and moved their entire basis into an
> OO based world and integrated it together - love em or hate em but I think
> this was a bold move by MS and showed great vision
>
> Where is the vision for VMS? I have not seen much mention of OO as a
> direction other than a revamp of the C++ compiler and piggybacking on Java.

The vision for VMS? That's an easy one. Basic. Don't agree? Too bad. That's
my opinion, and I'm sticking to it.

> I know it's early days but I do wonder if the powers that be are thinking
> along the lines of a revamp of the heart of VMS at some point in time akin to
> the major work that MS did...

If it ain't broke, don't fix it ....

[Stephen Hoffman]

On 2017-02-24 05:29:09 +0000, IanD said:

> Where is the vision for VMS? I have not seen much mention of OO as a
> direction other than a revamp of the C++ compiler and piggybacking on
> Java.
> I know it's early days but I do wonder if the powers that be are
> thinking along the lines of a revamp of the heart of VMS at some point
> in time akin to the major work that MS did...

Technically...

I'd prefer to aim past what .NET and CLR or ObjC/Swift/Cocoa or
LLVM/Rust or... offer, because those already exist. Copying from what
is inherently a moving target isn't ever going to allow you to catch
up. Nor is doing the same as has always been done going to help
progress, for that matter.

How to make those changes while also staying true to the folks working
in the Fortran, COBOL and BASIC worlds won't be easy, either. Not
that I particularly see substantial wholly-new Fortran, COBOL or BASIC
work — or C or C++ work, for that matter — being the path forward,
either. Not beyond maintenance and updates for better conformance to
newer standards and tools, where the languages offer those, and adding
(some) new vendor-specific features the languages, where those are
applicable.

The existing apps and tools and developers are all aging out, and there
is presently insufficient incentive to host wholly new apps on OpenVMS,
and the x86-64 port won't alter the existing incentives enough. The
port will certainly help, but there needs to be far more — both "new
shiny" to get developers to upgrade and adapt their apps for the new
work and also to remediate targeted and necessary
compatibility-breaking changes, and enough "new shiny" to make
deploying on OpenVMS more cost-effective — by some measure — than
deploying apps on Windows Server, Linux or otherwise.

The existing app developers will also and entirely correctly tell VSI
not to make any breaking changes, too. Which is about the worst thing
for OpenVMS that those same developers can ask for, too. Short-term
and tactical thinking, but then that's a common theme (problem?) in IT.
This at least until after VSI can show the end-users and developers
"new shiny" that'll start pulling them and their apps and their servers
forward.

Business-wise....

VSI is completely and utterly backlogged with work. For now, it's
all about building the revenues with minimal work, about watching the
revenue trends, and about getting the x86-64 port out the door.
Revenues and trends for VSI, and also eventually around revenues for
third-party developers. Because with low revenues or poor revenue
trends, there is no OpenVMS. They don't (yet) have a good
opportunity to design and deploy substantial updates or major overhauls.

"Simply" implementing .NET and CLR — or continuing to do all of what
has been done with OpenVMS before — won't move any of this morass
forward in isolation. Not even the port, for that matter. Not until
the benefits accrue to both VSI and to the end-users and third-party
developers.

What happens as we get closer to 2022 or to 2027? Quo Vadis VMS? We
shall learn more in the fullness of time.

[plugh]

How to push this initiative forward? What's the current state of llvm on vms? I'm sure there's more to it than that, but let's open the discussion there.

[Jan-Erik Söderholm]

Den 2022-01-09 kl. 15:52, skrev plugh:

> What's the current state of llvm on vms?

Start looking and listening to some of the webinars published by VSI.
Many of them have updates on the LLVM/VMS status.

https://vmssoftware.com/about/webinars/

[John Dallman]

In article <sretlu$ask$1...@dont-email.me>, jan-erik....@telia.com

(Jan-Erik Söderholm) wrote:

> Start looking and listening to some of the webinars published by
> VSI. Many of them have updates on the LLVM/VMS status.

To summarise broadly, only fairly old versions of LLVM will build for
IA-64 VMS. VSI have been gradually bootstrapping LLVM on x86-64 VMS using
that, with the obvious objective of a modern self-hosting LLVM on x86-64.
Once that is complete, getting Rust running on it should be reasonably
straightforward.

John

[plugh]

I think we start here?
https://llvm.org/doxygen/classllvm_1_1Triple.html
I'm guessing the videos Jan Erik points to also hold clues.

[John Reagan]

Well, Rust is written mainly in Rust so the bootstrapping will be interesting but
no different than the bootstrapping we are doing now for clang/llvm. We're
using LLVM 10.0.1 for our initial bootstrap (with some subsequent bugfixes
we cherrypicked).

[John Reagan]

As we move to put the code back to LLVM, we'll create a real OpenVMS triple.
Today we are just using a generic tuple.

$ show sys/noproc
OpenVMS XG4C-H4S on node X86VMS 9-JAN-2022 11:37:14.50 Uptime 4 20:48:41
$ clang --version
clang version 10.0.1 (g...@bitbucket.org:vms_software/llvm-10.0.1.git 9de667ac5f86bc2e4a3ba7d9071c0ebbdc756b21)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: DKA100:[JREAGAN]

[plugh]

Thanks for the checkpoint! Fun times!