Has there been any talk on this being ported?

On Saturday, April 22, 2023 at 11:38:25 AM UTC+1, issinoho wrote:
> Has there been any talk on this being ported?

See https://forum.vmssoftware.com/viewtopic.php?f=41&t=8627&p=18284&hilit=sql#p18284

and note https://www.mimer.com/mimer-announces-support-for-openvms-v9-2/

On Monday, 24 April 2023 at 15:37:06 UTC+1, Ian Miller wrote:
> On Saturday, April 22, 2023 at 11:38:25 AM UTC+1, issinoho wrote:
> > Has there been any talk on this being ported?
> See https://forum.vmssoftware.com/viewtopic.php?f=41&t=8627&p=18284&hilit=sql#p18284
>
> and note https://www.mimer.com/mimer-announces-support-for-openvms-v9-2/
Excellent. Thanks.

On 4/22/23 5:38 AM, issinoho wrote:
> Has there been any talk on this being ported?

The C++ compiler that will be necessary to make it even theoretically
possible is still in field test and only became available quite
recently. One can hope, but we won't really know until someone does the
work.

On 4/24/2023 6:12 PM, Craig A. Berry wrote:
> On 4/22/23 5:38 AM, issinoho wrote:
>> Has there been any talk on this being ported?
>
> The C++ compiler that will be necessary to make it even theoretically
> possible is still in field test and only became available quite
> recently.  One can hope, but we won't really know until someone does the
> work.

MySQL/MariaDB runs on VMS Alpha and VMS Itanium.

All that is needed to build for VMS x86-64 in the same
version (5.5) as on the other two should be a traditional VMS
compiler. Isn't C++ available as cross compiler?

It has explained stated that getting newer versions of
MySQL/MariaDB (10.x and 11.x) running on VMS require compiler
with support for newer standards - aka need clang.

Arne

On 4/24/23 5:18 PM, Arne Vajhøj wrote:
> On 4/24/2023 6:12 PM, Craig A. Berry wrote:
>> On 4/22/23 5:38 AM, issinoho wrote:
>>> Has there been any talk on this being ported?
>>
>> The C++ compiler that will be necessary to make it even theoretically
>> possible is still in field test and only became available quite
>> recently.  One can hope, but we won't really know until someone does the
>> work.
>
> MySQL/MariaDB runs on VMS Alpha and VMS Itanium.

Yeah, but only versions that are near or past EOL.

> All that is needed to build for VMS x86-64 in the same
> version (5.5) as on the other two should be a traditional VMS
> compiler. Isn't C++ available as cross compiler?

Doesn't look like it, according to this:

https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf

> It has explained stated that getting newer versions of
> MySQL/MariaDB (10.x and 11.x) running on VMS require compiler
> with support for newer standards - aka need clang.

And clang++ is the only C++ there will be for x86.

On 4/24/2023 8:33 PM, Craig A. Berry wrote:
> On 4/24/23 5:18 PM, Arne Vajhøj wrote:
>> On 4/24/2023 6:12 PM, Craig A. Berry wrote:
>>> On 4/22/23 5:38 AM, issinoho wrote:
>>>> Has there been any talk on this being ported?
>>>
>>> The C++ compiler that will be necessary to make it even theoretically
>>> possible is still in field test and only became available quite
>>> recently.  One can hope, but we won't really know until someone does the
>>> work.
>>
>> MySQL/MariaDB runs on VMS Alpha and VMS Itanium.
>
> Yeah, but only versions that are near or past EOL.

MariaDB 5.5 is from 2012 and went EOL in 2020.

Old indeed in general IT. Not quite as old in the VMS world.

And I think it is quite OK functionality wise.

The only think that comes to my mind as missing is the
JSON support in newer versions.

>> All that is needed to build for VMS x86-64 in the same
>> version (5.5) as on the other two should be a traditional VMS
>> compiler. Isn't C++ available as cross compiler?
>
> Doesn't look like it, according to this:
>
> https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf

That explains why they have not been ported yet.

>> It has explained stated that getting newer versions of
>> MySQL/MariaDB (10.x and 11.x) running on VMS require compiler
>> with support for newer standards - aka need clang.
>
> And clang++ is the only C++ there will be for x86.

I don't think anyone will miss traditional VMS C++.

It is so far behind.

Arne

> > https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf
> That explains why they have not been ported yet.

It is more likely that there was no customer interested in porting MariaDB to x86. So, now I'm using clang to complete the preparation of JDK 8u372 for field testing... it's just a matter of priorities.

Vitaly

On 4/25/2023 12:14 AM, Vitaly Pustovetov wrote:
>>> https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf
>> That explains why they have not been ported yet.
>
> It is more likely that there was no customer interested in porting
> MariaDB to x86. So, now I'm using clang to complete the preparation
> of JDK 8u372 for field testing... it's just a matter of priorities.
That is also important for us that like everything starting with J.

:-)

Most existing VMS customers are using Rdb (or inddex-sequential files).
But any new or "come back" VMS users will be looking for a RDBMS. And
right now Mimer seems to be the only one available for VMS x86-64.
Good for them to get more on the VMS radar screen I guess.

Arne

On 4/24/23 4:12 PM, Craig A. Berry wrote:
>
> On 4/22/23 5:38 AM, issinoho wrote:
>> Has there been any talk on this being ported?
>
> The C++ compiler that will be necessary to make it even theoretically
> possible is still in field test and only became available quite
> recently.  One can hope, but we won't really know until someone does the
> work.

When the field test C++ compiler became available I attempted to build
my MariaDB v5.5 kit. It was a no go for a few reasons.

One,
The field test is still limited in some functionality. For example,
there are some pragmas that are not yet supported or not yet fully
supported. The include_directory pragma does not yet appear to work and
my build procedure depends heavily on this.

Two,
There are a number of places in the port that assume that long and
size_t are 32 bits. For x86_64, they are 64 bits. Addressing this
would almost mean redoing the port. (I think long is a bigger issue than
size_t).

Three,
In order for the headers included with the compiler to compile
correctly, certain values must be defined. For example, in order to use
string.h, either __CORRECT_ISO_CPP_STRING_H_PROTO or
_STRING_H_CPLUSPLUS_98_CONFORMANCE_ must be defined. Otherwise, the
compiler throws errors and aborts. I did not see anything about this in
the documentation and stumbled across it when trying to figure out why
the errors were occurring. Now I wonder if there are others.

I think MariaDB, either V5 for V10, will have to wait until the C++
compiler is more complete.

Mark Berryman

On 4/25/2023 11:33 AM, Mark Berryman wrote:
> On 4/24/23 4:12 PM, Craig A. Berry wrote:
>> On 4/22/23 5:38 AM, issinoho wrote:
>>> Has there been any talk on this being ported?
>>
>> The C++ compiler that will be necessary to make it even theoretically
>> possible is still in field test and only became available quite
>> recently.  One can hope, but we won't really know until someone does the
>> work.
>
> When the field test C++ compiler became available I attempted to build
> my MariaDB v5.5 kit.  It was a no go for a few reasons.
>
> One,
> The field test is still limited in some functionality.  For example,
> there are some pragmas that are not yet supported or not yet fully
> supported.  The include_directory pragma does not yet appear to work and
> my build procedure depends heavily on this.

Is that VMS C++ specific pragma or standard?

If VMS C++ specific then maybe it will not be added as I believe John R
want to keep the C++ compiler as close to clang elsewhere as possible.

> Two,
> There are a number of places in the port that assume that long and
> size_t are 32 bits.  For x86_64, they are 64 bits.  Addressing this
> would almost mean redoing the port. (I think long is a bigger issue than
> size_t).

That seems unlikely to be fixed in the compiler.

Time for int32_t and int64_t?

> Three,
> In order for the headers included with the compiler to compile
> correctly, certain values must be defined.  For example, in order to use
> string.h, either __CORRECT_ISO_CPP_STRING_H_PROTO or
> _STRING_H_CPLUSPLUS_98_CONFORMANCE_ must be defined.  Otherwise, the
> compiler throws errors and aborts.  I did not see anything about this in
> the documentation and stumbled across it when trying to figure out why
> the errors were occurring.  Now I wonder if there are others.

That sound as a bug.

> I think MariaDB, either V5 for V10, will have to wait until the C++
> compiler is more complete.

11.0 is already RC, so maybe go straight to 11 instead of 10.

Arne

On 4/25/23 12:04 PM, Arne Vajhøj wrote:
> On 4/25/2023 11:33 AM, Mark Berryman wrote:

>> The field test is still limited in some functionality.  For example,
>> there are some pragmas that are not yet supported or not yet fully
>> supported.  The include_directory pragma does not yet appear to work
>> and my build procedure depends heavily on this.
>
> Is that VMS C++ specific pragma or standard?

Pages 24-25 here:

https://docs.vmssoftware.com/test-docs/vsi-cxx-user-s-guide-for-openvms-systems.pdf

say:

"This pragma is intended to ease DCL command-line length limitations
when porting applications from POSIX-like environments built with
makefiles containing long lists of -I options that specify directories
to search for headers. Just as long lists of macro definitions specified
by the /DEFINE qualifier can be converted to #define directives in a
source file, long lists of places to search specified by the
/INCLUDE_DIRECTORY qualifier can be converted to #pragma
include_directory directives in a source file."

> If VMS C++ specific then maybe it will not be added as I believe John R
> want to keep the C++ compiler as close to clang elsewhere as possible.

A worthy goal, but if there are workarounds in the compiler for
limitations in the VMS build environment, they may very well still be
needed. Unless alternate solutions are found. In this case, it *might*
be possible, depending on current command line length limitations and
where and how the MariaDB build exceeds them, to use clang++ rather than
CXX from the command line. That based on the fact that -Ifoo takes up
less space than /INCLUDE=[foo]. But even if that works, it's just one
reason it might be a new port as Mark suggested might be necessary
rather than just carrying forward the existing port.

On 4/25/2023 3:16 PM, Craig A. Berry wrote:
>
> On 4/25/23 12:04 PM, Arne Vajhøj wrote:
>> On 4/25/2023 11:33 AM, Mark Berryman wrote:
>
>>> The field test is still limited in some functionality.  For example,
>>> there are some pragmas that are not yet supported or not yet fully
>>> supported.  The include_directory pragma does not yet appear to work
>>> and my build procedure depends heavily on this.
>>
>> Is that VMS C++ specific pragma or standard?
>
> Pages 24-25 here:
>
> https://docs.vmssoftware.com/test-docs/vsi-cxx-user-s-guide-for-openvms-systems.pdf
>
> say:
>
> "This pragma is intended to ease DCL command-line length limitations
> when porting applications from POSIX-like environments built with
> makefiles containing long lists of -I options that specify directories
> to search for headers. Just as long lists of macro definitions specified
> by the /DEFINE qualifier can be converted to #define directives in a
> source file, long lists of places to search specified by the
> /INCLUDE_DIRECTORY qualifier can be converted to #pragma
> include_directory directives in a source file."
>
>> If VMS C++ specific then maybe it will not be added as I believe John R
>> want to keep the C++ compiler as close to clang elsewhere as possible.
>
> A worthy goal, but if there are workarounds in the compiler for
> limitations in the VMS build environment, they may very well still be
> needed.  Unless alternate solutions are found.  In this case, it *might*
> be possible, depending on current command line length limitations and
> where and how the MariaDB build exceeds them, to use clang++ rather than
> CXX from the command line.  That based on the fact that -Ifoo takes up
> less space than /INCLUDE=[foo].

Maybe I should have RTFM ...

:-)

But I got it now.

I am sort of in favor of logicals here if possible (but it is not
necessarily possible).

:-)

Demo:

$ type [.liba.include]a.h
char *a = "This is A";
$ type [.libb.include]b.h
char *b = "This is B";
$ type w1.c
#include <stdio.h>

#include "a.h"
#include "b.h"

int main(int argc, char *argv[])
{ printf("%s\n", a);
printf("%s\n", b);
return 0;
} $ cc /include=([.liba.include],[.libb.include]) w1
$ link w1
$ run w1
This is A
This is B
$ type w2.c
#pragma include_directory "[.liba.include]"
#pragma include_directory "[.libb.include]"

#include <stdio.h>

#include "a.h"
#include "b.h"

int main(int argc, char *argv[])
{ printf("%s\n", a);
printf("%s\n", b);
return 0;
} $ cc w2
$ link w2
$ run w2
This is A
This is B
$ type w3.c
#include <stdio.h>

#include "liba/include/a.h"
#include "libb/include/b.h"

int main(int argc, char *argv[])
{ printf("%s\n", a);
printf("%s\n", b);
return 0;
} $ define/nolog liba [.liba]
$ define/nolog libb [.libb]
$ cc w3
$ link w3
$ run w3
This is A
This is B

Arne

On 4/25/2023 5:18 PM, Arne Vajhøj wrote:
> #include "liba/include/a.h"
> #include "libb/include/b.h"

> $ define/nolog liba [.liba]
> $ define/nolog libb [.libb]

Make that:

#include "libadir/include/a.h"
#include "libbdir/include/b.h"

$ define/nolog libadir [.liba]
$ define/nolog libbdir [.libb]

because otherwise it would work without logicals.

Arne

On Tuesday, April 25, 2023 at 11:33:37 AM UTC-4, Mark Berryman wrote:
> On 4/24/23 4:12 PM, Craig A. Berry wrote:
> >
> > On 4/22/23 5:38 AM, issinoho wrote:
> >> Has there been any talk on this being ported?
> >
> > The C++ compiler that will be necessary to make it even theoretically
> > possible is still in field test and only became available quite
> > recently. One can hope, but we won't really know until someone does the
> > work.
> When the field test C++ compiler became available I attempted to build
> my MariaDB v5.5 kit. It was a no go for a few reasons.
>
> One,
> The field test is still limited in some functionality. For example,
> there are some pragmas that are not yet supported or not yet fully
> supported. The include_directory pragma does not yet appear to work and
> my build procedure depends heavily on this.
>
> Two,
> There are a number of places in the port that assume that long and
> size_t are 32 bits. For x86_64, they are 64 bits. Addressing this
> would almost mean redoing the port. (I think long is a bigger issue than
> size_t).
>
> Three,
> In order for the headers included with the compiler to compile
> correctly, certain values must be defined. For example, in order to use
> string.h, either __CORRECT_ISO_CPP_STRING_H_PROTO or
> _STRING_H_CPLUSPLUS_98_CONFORMANCE_ must be defined. Otherwise, the
> compiler throws errors and aborts. I did not see anything about this in
> the documentation and stumbled across it when trying to figure out why
> the errors were occurring. Now I wonder if there are others.
>
> I think MariaDB, either V5 for V10, will have to wait until the C++
> compiler is more complete.
>
> Mark Berryman
I've been away on vacation for a few weeks. I'll get a status and post in a few days.

On Saturday, April 22, 2023 at 6:38:25 AM UTC-4, issinoho wrote:
> Has there been any talk on this being ported?

As others have already mentioned, both MySQL-5.5 and MariaDB-5.5 are no longer supported.

And when they were, I was experiencing database corruptions problems at shutdown that forced me to move to MariaDB-10 on Linux
(our shop has been employing heterogeneous computing since 2016; our primary businesses systems run OpenVMS but our relational databases were being served up on CentOS-7; now Rocky-8)

One of the annoyances with MariaDB-10 (and MySQL-6) is that they can only be built with C11 which is still not available on OpenVMS/Alpha or OpenVMS/Itanium
(that blame goes to all the companies before VSI who did not take C/C++ seriously enough to keep the C/C++ ecosystem up to date on OpenVMS).
(not sure why the authors of MySQL and MariaDB did not follow the example set by Apache where HTTPd would always be tied to a simpler version of C)

Everyone reading this knows how difficult it is to play catchup whenever a company has allowed something to slide for more than a decade (IIRC, C99 was the last standard supported by Compaq and I do not recall any progress being made when HP was at the helm).

Kudos to VSI for making as much progress as they have. I only hope that they get around to also supporting C17 (stable) and C23 (pre-release)

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
http://neilrieck.net/OpenVMS.html

On 4/26/23 5:33 AM, Neil Rieck wrote:

> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
> only be built with C11 which is still not available on OpenVMS/Alpha
> or OpenVMS/Itanium
Not sure that will ever happen. It's hard to see how VSI can afford to
continue to make major changes to the traditional front end on all
platforms while also keeping up with clang on x86.

> Kudos to VSI for making as much progress as they have. I only hope
> that they get around to also supporting C17 (stable) and C23 (pre-release)

Have you tried the clang-based C++ compiler currently in field test,
which, as a side effect of being clang, works as either a C compiler or
a C++ compiler? I suspect that will be the path forward for newer
standards.

On 2023-04-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/25/2023 12:14 AM, Vitaly Pustovetov wrote:
>>
>> It is more likely that there was no customer interested in porting
>> MariaDB to x86. So, now I'm using clang to complete the preparation
>> of JDK 8u372 for field testing... it's just a matter of priorities.
> That is also important for us that like everything starting with J.
>
>:-)
>

So what did you think about _J_OVIAL ? :-)

Or _J_avascript for that matter ? :-)

Simon.

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

On 4/26/2023 8:14 AM, Simon Clubley wrote:
>
> So what did you think about _J_OVIAL ? :-)
>

Laugh all you want. The last I heard the USAF is still using
Jovial. Especially after the fiasco their pet project Ada
turned out to be. :-)

bill

On 2023-04-26, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
> On 4/26/23 5:33 AM, Neil Rieck wrote:
>
>> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
>> only be built with C11 which is still not available on OpenVMS/Alpha
>> or OpenVMS/Itanium
> Not sure that will ever happen. It's hard to see how VSI can afford to
> continue to make major changes to the traditional front end on all
> platforms while also keeping up with clang on x86.
>

They don't need to change those front ends.

If you have existing DEC-specific code, use the DEC front ends that John
is writing.

If you have industry-standard C or C++ code that needs modern compiler
standards, then just call clang directly, instead of via one of the
DEC front ends.

Simon.

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

On 4/26/23 7:19 AM, Simon Clubley wrote:
> On 2023-04-26, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>>
>> On 4/26/23 5:33 AM, Neil Rieck wrote:
>>
>>> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
>>> only be built with C11 which is still not available on OpenVMS/Alpha
>>> or OpenVMS/Itanium
>> Not sure that will ever happen. It's hard to see how VSI can afford to
>> continue to make major changes to the traditional front end on all
>> platforms while also keeping up with clang on x86.
>>
>
> They don't need to change those front ends.
>
> If you have existing DEC-specific code, use the DEC front ends that John
> is writing.
>
> If you have industry-standard C or C++ code that needs modern compiler
> standards, then just call clang directly, instead of via one of the
> DEC front ends.

Which is no help at all for someone who just said, "C11 which is still
not available on OpenVMS/Alpha or OpenVMS/Itanium." Unless someone with
a very large pile of cash wants to revive llvm-alpha and llvm-ia64.

On 2023-04-26, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
> Which is no help at all for someone who just said, "C11 which is still
> not available on OpenVMS/Alpha or OpenVMS/Itanium." Unless someone with
> a very large pile of cash wants to revive llvm-alpha and llvm-ia64.
>

Yeah, you are right Craig. I missed what you were saying. Sorry.

Simon.

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

On 4/26/23 12:42 PM, Simon Clubley wrote:
> On 2023-04-26, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>>
>> Which is no help at all for someone who just said, "C11 which is still
>> not available on OpenVMS/Alpha or OpenVMS/Itanium." Unless someone with
>> a very large pile of cash wants to revive llvm-alpha and llvm-ia64.
>>
>
> Yeah, you are right Craig. I missed what you were saying. Sorry.

For credit where credit is due, I was quoting Neil Rieck, not myself.

On 4/26/2023 12:14 PM, Craig A. Berry wrote:
> On 4/26/23 7:19 AM, Simon Clubley wrote:
>> On 2023-04-26, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>>> On 4/26/23 5:33 AM, Neil Rieck wrote:
>>>> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
>>>> only be built with C11 which is still not available on OpenVMS/Alpha
>>>> or OpenVMS/Itanium
>>> Not sure that will ever happen.  It's hard to see how VSI can afford to
>>> continue to make major changes to the traditional front end on all
>>> platforms while also keeping up with clang on x86.
>>
>> They don't need to change those front ends.
>>
>> If you have existing DEC-specific code, use the DEC front ends that John
>> is writing.
>>
>> If you have industry-standard C or C++ code that needs modern compiler
>> standards, then just call clang directly, instead of via one of the
>> DEC front ends.
>
> Which is no help at all for someone who just said, "C11 which is still
> not available on OpenVMS/Alpha or OpenVMS/Itanium."  Unless someone with
> a very large pile of cash wants to revive llvm-alpha and llvm-ia64.

I don't know if VSI has officially stated it, but when I saw
that Alpha and Itanium would not get 9.x, then my conclusion
was that:
- VSI will support Alpha and Itanium to run what is running
on them today - whatever was created 20-30 years ago will
continue to run for many years to come
- anyone wanting major new VMS or VMS LP functionality for
new stuff will need to migrate to x86-64

Arne

On 4/26/2023 6:33 AM, Neil Rieck wrote:
> On Saturday, April 22, 2023 at 6:38:25 AM UTC-4, issinoho wrote:
>> Has there been any talk on this being ported?
>
> As others have already mentioned, both MySQL-5.5 and MariaDB-5.5 are
> no longer supported.

Yep.

> And when they were, I was experiencing database corruptions problems
> at shutdown

On VMS?

> that forced me to move to MariaDB-10 on Linux (our shop
> has been employing heterogeneous computing since 2016; our primary
> businesses systems run OpenVMS but our relational databases were
> being served up on CentOS-7; now Rocky-8)
>
> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
> only be built with C11 which is still not available on OpenVMS/Alpha
> or OpenVMS/Itanium (that blame goes to all the companies before VSI
> who did not take C/C++ seriously enough to keep the C/C++ ecosystem
> up to date on OpenVMS). (not sure why the authors of MySQL and
> MariaDB did not follow the example set by Apache where HTTPd would
> always be tied to a simpler version of C)
>
> Everyone reading this knows how difficult it is to play catchup
> whenever a company has allowed something to slide for more than a
> decade (IIRC, C99 was the last standard supported by Compaq and I do
> not recall any progress being made when HP was at the helm).
>
> Kudos to VSI for making as much progress as they have. I only hope
> that they get around to also supporting C17 (stable) and C23
> (pre-release)

VMS C has been struggling a bit to get to C99.

But it is my impression that C99 is sort of livable
as few C applications rely on C11 & C17.

I believe the big problem is C++. C++98 is totally
obsolete. A lot of actively maintained C++ applications
require C++11/14 or C++17.

So VMS C++ with its C++98 support is a problem.

And I believe the MySQL/MariaDB issue is in the C++
part not the C part.

Arne