From a recent email:

"VMS Software Inc. is pleased to announce availability of a test release of a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on OpenVMS I64 for source compatibility."

The message contained a link to the Release Notes, but the URL does not paste well.

- Bob Gezelter, http://www.rlgsc.com

On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
> From a recent email:
>
> "VMS Software Inc. is pleased to announce availability of a test release of a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on OpenVMS I64 for source compatibility."
>
> The message contained a link to the Release Notes, but the URL does not paste well.
>
> - Bob Gezelter, http://www.rlgsc.com

Good news indeed! But our last Fortran customer departed some years ago.

Basic is what we're waiting for.

On 2023-03-01, Rich Jordan <jordan@ccs4vms.com> wrote:
> On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
>> From a recent email:
>>
>> "VMS Software Inc. is pleased to announce availability of a test release of a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on OpenVMS I64 for source compatibility."
>>
>> The message contained a link to the Release Notes, but the URL does not paste well.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> Good news indeed! But our last Fortran customer departed some years ago.
>
> Basic is what we're waiting for.
>

Given that it's already March 2023, my guess is that Basic will come out
in time for the 10th anniversary of the VMS porting effort. :-)

On a more serious note, I wonder how much income VSI get from Basic ?

If John finds a core problem that can't be easily fixed, is there a
point at which VSI could say that the expenditure on VMS Basic is
going to be greater than the income from it and hence drop it ?

Of the mainstream languages available for x86-64 VMS, Basic would appear
to be the one with the smallest market share, and don't forget that VSI
have already decided not to proceed with Ada for x86-64 VMS.

Simon.

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

On Wednesday, March 1, 2023 at 1:14:45 PM UTC-5, Simon Clubley wrote:
> On 2023-03-01, Rich Jordan <jor...@ccs4vms.com> wrote:
> > On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
> >> From a recent email:
> >>
> >> "VMS Software Inc. is pleased to announce availability of a test release of a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on OpenVMS I64 for source compatibility."
> >>
> >> The message contained a link to the Release Notes, but the URL does not paste well.
> >>
> >> - Bob Gezelter, http://www.rlgsc.com
> >
> > Good news indeed! But our last Fortran customer departed some years ago..
> >
> > Basic is what we're waiting for.
> >
> Given that it's already March 2023, my guess is that Basic will come out
> in time for the 10th anniversary of the VMS porting effort. :-)
>
> On a more serious note, I wonder how much income VSI get from Basic ?
>
> If John finds a core problem that can't be easily fixed, is there a
> point at which VSI could say that the expenditure on VMS Basic is
> going to be greater than the income from it and hence drop it ?
>
> Of the mainstream languages available for x86-64 VMS, Basic would appear
> to be the one with the smallest market share, and don't forget that VSI
> have already decided not to proceed with Ada for x86-64 VMS.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Don't blow the BASIC issue out of proportion. It is just that the BASIC frontend
generates GEM symbol table that look "different" than everybody else. I
just haven't had the time (or desire) to change how G2L has to operate. I'd
rather change the BASIC frontend. I have other things to do first. It is not
a multiple person-year task. We have all the real HARD pieces of BASIC already
working.

On 3/1/2023 1:14 PM, Simon Clubley wrote:
> On 2023-03-01, Rich Jordan <jordan@ccs4vms.com> wrote:
>> On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
>>> From a recent email:
>>>
>>> "VMS Software Inc. is pleased to announce availability of a test release of a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on OpenVMS I64 for source compatibility."
>>>
>>> The message contained a link to the Release Notes, but the URL does not paste well.
>>>
>>> - Bob Gezelter, http://www.rlgsc.com
>>
>> Good news indeed! But our last Fortran customer departed some years ago.
>>
>> Basic is what we're waiting for.
>>
>
> Given that it's already March 2023, my guess is that Basic will come out
> in time for the 10th anniversary of the VMS porting effort. :-)
>
> On a more serious note, I wonder how much income VSI get from Basic ?
>
> If John finds a core problem that can't be easily fixed, is there a
> point at which VSI could say that the expenditure on VMS Basic is
> going to be greater than the income from it and hence drop it ?
>
> Of the mainstream languages available for x86-64 VMS, Basic would appear
> to be the one with the smallest market share, and don't forget that VSI
> have already decided not to proceed with Ada for x86-64 VMS.

Based on comp.os.vms questions and forum.vmssoftware.com questions,
then VMS Basic seems to be pretty widely used on VMS.

I don't think VMS Basic is at risk to be deemed financially
not worth it.

It just has to be completed. I suspect that the main reason
why Fortran was done before Basic was the simple fact that
LLVM has Fortran support (flang) out of the box. Alternative
explanation is that VMS Basic has some advanced features while
Fortran is probably more traditional.

Arne

On 3/1/2023 6:44 PM, Arne Vajhøj wrote:
> On 3/1/2023 1:14 PM, Simon Clubley wrote:
>> On 2023-03-01, Rich Jordan <jordan@ccs4vms.com> wrote:
>>> On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
>>>> From a recent email:
>>>>
>>>> "VMS Software Inc. is pleased to announce availability of a test release of
>>>> a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on
>>>> OpenVMS I64 for source compatibility."
>>>>
>>>> The message contained a link to the Release Notes, but the URL does not
>>>> paste well.
>>>>
>>>> - Bob Gezelter, http://www.rlgsc.com
>>>
>>> Good news indeed! But our last Fortran customer departed some years ago.
>>>
>>> Basic is what we're waiting for.
>>>
>>
>> Given that it's already March 2023, my guess is that Basic will come out
>> in time for the 10th anniversary of the VMS porting effort. :-)
>>
>> On a more serious note, I wonder how much income VSI get from Basic ?
>>
>> If John finds a core problem that can't be easily fixed, is there a
>> point at which VSI could say that the expenditure on VMS Basic is
>> going to be greater than the income from it and hence drop it ?
>>
>> Of the mainstream languages available for x86-64 VMS, Basic would appear
>> to be the one with the smallest market share, and don't forget that VSI
>> have already decided not to proceed with Ada for x86-64 VMS.
>
> Based on comp.os.vms questions and forum.vmssoftware.com questions,
> then VMS Basic seems to be pretty widely used on VMS.
>
> I don't think VMS Basic is at risk to be deemed financially
> not worth it.
>
> It just has to be completed. I suspect that the main reason
> why Fortran was done before Basic was the simple fact that
> LLVM has Fortran support (flang) out of the box. Alternative
> explanation is that VMS Basic has some advanced features while
> Fortran is probably more traditional.

Some may have me expound on "smart people" in the past. Those who think they
are clever by doing things different/sneaky/whatever. From what John has
written in the past, it seems that some "smart people" did some things in the
Basic compiler that were a bit different (to say the least) than what John's
people expected.

It was quite interesting when he recently said he'd rather change the compiler.
Perhaps to dumb down to reasonable what some "smart people" did in the past.

:-)

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

On 3/1/2023 6:58 PM, Dave Froble wrote:
> On 3/1/2023 6:44 PM, Arne Vajhøj wrote:
>> On 3/1/2023 1:14 PM, Simon Clubley wrote:
>>> On a more serious note, I wonder how much income VSI get from Basic ?
>>>
>>> If John finds a core problem that can't be easily fixed, is there a
>>> point at which VSI could say that the expenditure on VMS Basic is
>>> going to be greater than the income from it and hence drop it ?
>>>
>>> Of the mainstream languages available for x86-64 VMS, Basic would appear
>>> to be the one with the smallest market share, and don't forget that VSI
>>> have already decided not to proceed with Ada for x86-64 VMS.
>>
>> Based on comp.os.vms questions and forum.vmssoftware.com questions,
>> then VMS Basic seems to be pretty widely used on VMS.
>>
>> I don't think VMS Basic is at risk to be deemed financially
>> not worth it.
>>
>> It just has to be completed. I suspect that the main reason
>> why Fortran was done before Basic was the simple fact that
>> LLVM has Fortran support (flang) out of the box. Alternative
>> explanation is that VMS Basic has some advanced features while
>> Fortran is probably more traditional.
>
> Some may have me expound on "smart people" in the past.  Those who think
> they are clever by doing things different/sneaky/whatever.  From what
> John has written in the past, it seems that some "smart people" did some
> things in the Basic compiler that were a bit different (to say the
> least) than what John's people expected.

There are two types of "smart".

Providing smart functionality. VMS Basic has a very nice LOC/FP
ratio in my opinion.

Implementing some functionality in a "smart" way.

> It was quite interesting when he recently said he'd rather change the
> compiler. Perhaps to dumb down to reasonable what some "smart people"
> did in the past.

He can not change the first type of smart only the second.

(well - he can do anything, but he don't want VMS Basic users showing
up with pitchforks)

Arne

On 3/1/23 5:44 PM, Arne Vajhøj wrote:
> On 3/1/2023 1:14 PM, Simon Clubley wrote:
>> On 2023-03-01, Rich Jordan <jordan@ccs4vms.com> wrote:
>>> On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
>>>>  From a recent email:
>>>>
>>>> "VMS Software Inc. is pleased to announce availability of a test
>>>> release of a Fortran compiler for OpenVMS x86. The code is based on
>>>> VSI Fortran on OpenVMS I64 for source compatibility."
>>>>
>>>> The message contained a link to the Release Notes, but the URL does
>>>> not paste well.
>>>>
>>>> - Bob Gezelter, http://www.rlgsc.com
>>>
>>> Good news indeed!  But our last Fortran customer departed some years
>>> ago.
>>>
>>> Basic is what we're waiting for.
>>>
>>
>> Given that it's already March 2023, my guess is that Basic will come out
>> in time for the 10th anniversary of the VMS porting effort. :-)
>>
>> On a more serious note, I wonder how much income VSI get from Basic ?
>>
>> If John finds a core problem that can't be easily fixed, is there a
>> point at which VSI could say that the expenditure on VMS Basic is
>> going to be greater than the income from it and hence drop it ?
>>
>> Of the mainstream languages available for x86-64 VMS, Basic would appear
>> to be the one with the smallest market share, and don't forget that VSI
>> have already decided not to proceed with Ada for x86-64 VMS.
>
> Based on comp.os.vms questions and forum.vmssoftware.com questions,
> then VMS Basic seems to be pretty widely used on VMS.
>
> I don't think VMS Basic is at risk to be deemed financially
> not worth it.
>
> It just has to be completed. I suspect that the main reason
> why Fortran was done before Basic was the simple fact that
> LLVM has Fortran support (flang) out of the box. Alternative
> explanation is that VMS Basic has some advanced features while
> Fortran is probably more traditional.

The Fortran compiler just released is based on the existing front end
and the G2L translation layer that produces LLVM intermediate
representations out of GEM intermediate representations.[1] This has
been stated publicly a number of times, as has been the fact they are
going roughly in order by number of affected customers as they move
through the list of compilers. flang has nothing to do with it.

A different project to port flang to VMS and add enough VMSisms to make
it mostly compatible with the existing VMS compiler is theoretically
possible, and somewhat interesting for newer features and standards
compliance. I believe it's been floated in the newsgroup before. It
seems unlikely anyone has the will or the resources to do it near-term.

The only other possibly relevant note about which of these two compilers
gets done first is that the implementation of COMMON blocks in Fortran
appears not to have been as evil as the implementation of MAP blocks in
BASIC, which affects what has to be done to G2L and/or the front end
itself to get things working. In the case of BASIC, it sounds like
reimplementing MAP in the front end is going to be less trouble than
hacking G2L to manage what BASIC does. Again, the fact that Fortran
could be built with less intrusive changes to G2L has nothing at all to
do with flang.

[1]
https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf

On 3/1/23 11:32 AM, Rich Jordan wrote:
> On Wednesday, March 1, 2023 at 10:09:23 AM UTC-6, Bob Gezelter wrote:
>> From a recent email:
>>
>> "VMS Software Inc. is pleased to announce availability of a test release of a Fortran compiler for OpenVMS x86. The code is based on VSI Fortran on OpenVMS I64 for source compatibility."
>>
>> The message contained a link to the Release Notes, but the URL does not paste well.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> Good news indeed! But our last Fortran customer departed some years ago.
>
> Basic is what we're waiting for.

Me too. That and ACME-LDAP, or some other mechanism to authenticate
against Active Directory.

On 3/1/2023 8:48 PM, Craig A. Berry wrote:
> On 3/1/23 5:44 PM, Arne Vajhøj wrote:
>> Based on comp.os.vms questions and forum.vmssoftware.com questions,
>> then VMS Basic seems to be pretty widely used on VMS.
>>
>> I don't think VMS Basic is at risk to be deemed financially
>> not worth it.
>>
>> It just has to be completed. I suspect that the main reason
>> why Fortran was done before Basic was the simple fact that
>> LLVM has Fortran support (flang) out of the box. Alternative
>> explanation is that VMS Basic has some advanced features while
>> Fortran is probably more traditional.
>
> The Fortran compiler just released is based on the existing front end
> and the G2L translation layer that produces LLVM intermediate
> representations out of GEM intermediate representations.[1]  This has
> been stated publicly a number of times, as has been the fact they are
> going roughly in order by number of affected customers as they move
> through the list of compilers.  flang has nothing to do with it.
>
> A different project to port flang to VMS and add enough VMSisms to make
> it mostly compatible with the existing VMS compiler is theoretically
> possible, and somewhat interesting for newer features and standards
> compliance.  I believe it's been floated in the newsgroup before.  It
> seems unlikely anyone has the will or the resources to do it near-term.

I was not implying that the released Fortran was flang - I know it
is not.

My speculation was that because flang frontend exist, then the LLVM
backend has everything needed to support Fortran language readily
available making it easier to get the VMS Fortran frontend working.

> The only other possibly relevant note about which of these two compilers
> gets done first is that the implementation of COMMON blocks in Fortran
> appears not to have been as evil as the implementation of MAP blocks in
> BASIC, which affects what has to be done to G2L and/or the front end
> itself to get things working.  In the case of BASIC, it sounds like
> reimplementing MAP in the front end is going to be less trouble than
> hacking G2L to manage what BASIC does.  Again, the fact that Fortran
> could be built with less intrusive changes to G2L has nothing at all to
> do with flang.

See above. And compare to Basic where there is no "blang"
and if something is missing in the backend then it may be
easier to hack the frontend than the backend.

But then I don't know LLVM at all. So I am just speculating.

Arne

On 3/1/2023 8:50 PM, Craig A. Berry wrote:

> Me too.  That and ACME-LDAP, or some other mechanism to authenticate
> against Active Directory.

Enterprise Directory/X.500?

--

--- Rob

On 3/1/23 7:57 PM, Arne Vajhøj wrote:
> On 3/1/2023 8:48 PM, Craig A. Berry wrote:
>> On 3/1/23 5:44 PM, Arne Vajhøj wrote:
>>> Based on comp.os.vms questions and forum.vmssoftware.com questions,
>>> then VMS Basic seems to be pretty widely used on VMS.
>>>
>>> I don't think VMS Basic is at risk to be deemed financially
>>> not worth it.
>>>
>>> It just has to be completed. I suspect that the main reason
>>> why Fortran was done before Basic was the simple fact that
>>> LLVM has Fortran support (flang) out of the box. Alternative
>>> explanation is that VMS Basic has some advanced features while
>>> Fortran is probably more traditional.
>>
>> The Fortran compiler just released is based on the existing front end
>> and the G2L translation layer that produces LLVM intermediate
>> representations out of GEM intermediate representations.[1]  This has
>> been stated publicly a number of times, as has been the fact they are
>> going roughly in order by number of affected customers as they move
>> through the list of compilers.  flang has nothing to do with it.
>>
>> A different project to port flang to VMS and add enough VMSisms to make
>> it mostly compatible with the existing VMS compiler is theoretically
>> possible, and somewhat interesting for newer features and standards
>> compliance.  I believe it's been floated in the newsgroup before.  It
>> seems unlikely anyone has the will or the resources to do it near-term.
>
> I was not implying that the released Fortran was flang - I know it
> is not.
>
> My speculation was that because flang frontend exist, then the LLVM
> backend has everything needed to support Fortran language readily
> available making it easier to get the VMS Fortran frontend working.
>
>> The only other possibly relevant note about which of these two compilers
>> gets done first is that the implementation of COMMON blocks in Fortran
>> appears not to have been as evil as the implementation of MAP blocks in
>> BASIC, which affects what has to be done to G2L and/or the front end
>> itself to get things working.  In the case of BASIC, it sounds like
>> reimplementing MAP in the front end is going to be less trouble than
>> hacking G2L to manage what BASIC does.  Again, the fact that Fortran
>> could be built with less intrusive changes to G2L has nothing at all to
>> do with flang.
>
> See above. And compare to Basic where there is no "blang"
> and if something is missing in the backend then it may be
> easier to hack the frontend than the backend.
>
> But then I don't know LLVM at all. So I am just speculating.

Yeah, me too, but my understanding is that the gotchas are in language
implementation details, not language features.

On 3/1/23 8:11 PM, Robert A. Brooks wrote:
> On 3/1/2023 8:50 PM, Craig A. Berry wrote:
>
>> Me too.  That and ACME-LDAP, or some other mechanism to authenticate
>> against Active Directory.
>
> Enterprise Directory/X.500?

The requirement is that all systems on the network must authenticate
against Microsoft Active Directory. On VMS this means external
authentication. I may be missing something, but how does Enterprise
Directory make that possible?

On 3/1/2023 9:34 PM, Craig A. Berry wrote:
> On 3/1/23 8:11 PM, Robert A. Brooks wrote:
>> On 3/1/2023 8:50 PM, Craig A. Berry wrote:
>>> Me too.  That and ACME-LDAP, or some other mechanism to authenticate
>>> against Active Directory.
>>
>> Enterprise Directory/X.500?
>
> The requirement is that all systems on the network must authenticate
> against Microsoft Active Directory.  On VMS this means external
> authentication.  I may be missing something, but how does Enterprise
> Directory make that possible?

I believe AD is X.500 compatible, but obviously that does not
guarantee that X.500 is AD compatible.

Arne

On 3/1/23 8:39 PM, Arne Vajhøj wrote:
> On 3/1/2023 9:34 PM, Craig A. Berry wrote:
>> On 3/1/23 8:11 PM, Robert A. Brooks wrote:
>>> On 3/1/2023 8:50 PM, Craig A. Berry wrote:
>>>> Me too.  That and ACME-LDAP, or some other mechanism to authenticate
>>>> against Active Directory.
>>>
>>> Enterprise Directory/X.500?
>>
>> The requirement is that all systems on the network must authenticate
>> against Microsoft Active Directory.  On VMS this means external
>> authentication.  I may be missing something, but how does Enterprise
>> Directory make that possible?
>
> I believe AD is X.500 compatible, but obviously that does not
> guarantee that X.500 is AD compatible.

Yes, what version or flavor of X.500 the pieces and parts speak to each
other could potentially be a problem. But the more fundamental problem
is that, as far as I know (which may not be very far) Enterprise
Directory is a server. What is needed is a client such that logging in
to the VMS system sends the authentication request elsewhere. Thus the
"external" in the external authentication I mentioned earlier. ACME-LDAP
does this. Even if Enterprise Directory also does this (and I can't see
how after a few minutes of searching), I'm pretty sure it's an
extra-cost product. So I think I'll wait for ACME-LDAP, which is
supposedly getting a rewrite from Ada to C.

On Wednesday, March 1, 2023 at 8:57:34 PM UTC-5, Arne Vajhøj wrote:
> On 3/1/2023 8:48 PM, Craig A. Berry wrote:
> > On 3/1/23 5:44 PM, Arne Vajhøj wrote:
> >> Based on comp.os.vms questions and forum.vmssoftware.com questions,
> >> then VMS Basic seems to be pretty widely used on VMS.
> >>
> >> I don't think VMS Basic is at risk to be deemed financially
> >> not worth it.
> >>
> >> It just has to be completed. I suspect that the main reason
> >> why Fortran was done before Basic was the simple fact that
> >> LLVM has Fortran support (flang) out of the box. Alternative
> >> explanation is that VMS Basic has some advanced features while
> >> Fortran is probably more traditional.
> >
> > The Fortran compiler just released is based on the existing front end
> > and the G2L translation layer that produces LLVM intermediate
> > representations out of GEM intermediate representations.[1] This has
> > been stated publicly a number of times, as has been the fact they are
> > going roughly in order by number of affected customers as they move
> > through the list of compilers. flang has nothing to do with it.
> >
> > A different project to port flang to VMS and add enough VMSisms to make
> > it mostly compatible with the existing VMS compiler is theoretically
> > possible, and somewhat interesting for newer features and standards
> > compliance. I believe it's been floated in the newsgroup before. It
> > seems unlikely anyone has the will or the resources to do it near-term.
> I was not implying that the released Fortran was flang - I know it
> is not.
>
> My speculation was that because flang frontend exist, then the LLVM
> backend has everything needed to support Fortran language readily
> available making it easier to get the VMS Fortran frontend working.
> > The only other possibly relevant note about which of these two compilers
> > gets done first is that the implementation of COMMON blocks in Fortran
> > appears not to have been as evil as the implementation of MAP blocks in
> > BASIC, which affects what has to be done to G2L and/or the front end
> > itself to get things working. In the case of BASIC, it sounds like
> > reimplementing MAP in the front end is going to be less trouble than
> > hacking G2L to manage what BASIC does. Again, the fact that Fortran
> > could be built with less intrusive changes to G2L has nothing at all to
> > do with flang.
> See above. And compare to Basic where there is no "blang"
> and if something is missing in the backend then it may be
> easier to hack the frontend than the backend.
>
> But then I don't know LLVM at all. So I am just speculating.
>
> Arne
Yes there is a flang (there are actually two of them). I've only briefly looked at the code.

The LLVM IR is quite capable of describing any language. The existence of flang did not influence any of our decisions.

The G2L converter simply converts the GEM CIL and symbol table into LLVM. What we didn't get was the subtle nature of COMMON blocks in the GEM symbol table. Nothing to do with LLVM. Nothing to do with flang. Nothing special about BASIC other than it describe the COMMON blocks "differently" than Fortran.

Why Fortran? Uh, customers asked? It was next on the roadmap? The build system that builds Fortran is the same one that builds GEM so we had some understanding of it?