Announced today:
<https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
ed/>

"VSI is also planning on making OpenVMS V9.2 available to hobbyists as
soon as more native compilers are available."

John

In article <memo.20220714171951.11788A@jgd.cix.co.uk>, jgd@cix.co.uk
(John Dallman) writes:

> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
> soon as more native compilers are available."

Great news!

Now if there could only be non-expiring licenses!

I realize that the hobbyist license always expired, but there was always
the possibility to buy a commercial one if necessary.

On 2022-07-14, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>
> Now if there could only be non-expiring licenses!
>

That's clearly not going to happen for the general case Phillip, even
though there is clearly heavy discussion about this going on behind
the scenes.

I just hope this decision doesn't tip VSI from being a viable business
into a non-viable one.

Simon.

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

In article <tapiqb$2p2h4$1@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2022-07-14, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> >
> > Now if there could only be non-expiring licenses!
>
> That's clearly not going to happen for the general case Phillip, even
> though there is clearly heavy discussion about this going on behind
> the scenes.

If there are still discussions, there is still hope. :-)

> I just hope this decision doesn't tip VSI from being a viable business
> into a non-viable one.

Indeed.

In article <memo.20220714171951.11788A@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes:
>Announced today:
><https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>ed/>
>
>"VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>soon as more native compilers are available."

Macro32 is all that's needed. Don't forget a native assembler too.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 7/14/2022 12:18 PM, John Dallman wrote:
> Announced today:
> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
> ed/>
>
> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
> soon as more native compilers are available."

https://vmssoftware.com/about/roadmap/ says:

July
OpenVMS V9.2 (Limited Production Release)
....
Native compilers with LLVM backend code generator:
BLISS, XMACRO, C++ (Phase 1)
....
July-November
....
Additional native compilers
C, COBOL, and C++ (Phase 2 – VMS Extensions)
....
November/December
OpenVMS V9.2-1 (Production Release – x86-64)
....
OpenJDK for x86
Native compilers with LLVM backend code generator:
Fortran, BASIC, and Pascal

Arne

On 2022-07-14, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <memo.20220714171951.11788A@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes:
>>Announced today:
>><https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>>ed/>
>>
>>"VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>>soon as more native compilers are available."
>
> Macro32 is all that's needed. Don't forget a native assembler too.
>

:-)

And back in normal-land, everyone is using C, COBOL, Fortran, etc and
don't give a damn about Macro-32 compilers. :-)

Simon.

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

On 2022-07-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/14/2022 12:18 PM, John Dallman wrote:
>> Announced today:
>> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>> ed/>
>>
>> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>> soon as more native compilers are available."
>
> https://vmssoftware.com/about/roadmap/ says:
>
> July
> OpenVMS V9.2 (Limited Production Release)
> ...
> Native compilers with LLVM backend code generator:
> BLISS, XMACRO, C++ (Phase 1)
> ...
> July-November
> ...
> Additional native compilers
> C, COBOL, and C++ (Phase 2 ? VMS Extensions)

Interesting that COBOL is a way higher priority than Fortran.

I assume what that is saying is that many scientific workloads have long
moved away from VMS.

> ...
> November/December
> OpenVMS V9.2-1 (Production Release ? x86-64)
> ...
> OpenJDK for x86
> Native compilers with LLVM backend code generator:
> Fortran, BASIC, and Pascal
>

One unknown is Pascal. There's obviously still a demand for it, but how
much of the VMS application base still uses Pascal ?

Simon.

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

On 7/15/2022 9:02 AM, Simon Clubley wrote:
> On 2022-07-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/14/2022 12:18 PM, John Dallman wrote:
>>> Announced today:
>>> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>>> ed/>
>>>
>>> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>>> soon as more native compilers are available."
>>
>> https://vmssoftware.com/about/roadmap/ says:
>>
>> July
>> OpenVMS V9.2 (Limited Production Release)
>> ...
>> Native compilers with LLVM backend code generator:
>> BLISS, XMACRO, C++ (Phase 1)
>> ...
>> July-November
>> ...
>> Additional native compilers
>> C, COBOL, and C++ (Phase 2 ? VMS Extensions)
>
> Interesting that COBOL is a way higher priority than Fortran.

I think that was to be expected.

> I assume what that is saying is that many scientific workloads have long
> moved away from VMS.

Scientific workloads like cheap CPU's and cheap OS.

>> ...
>> November/December
>> OpenVMS V9.2-1 (Production Release ? x86-64)
>> ...
>> OpenJDK for x86
>> Native compilers with LLVM backend code generator:
>> Fortran, BASIC, and Pascal
>>
>
> One unknown is Pascal. There's obviously still a demand for it, but how
> much of the VMS application base still uses Pascal ?

Based on questions here and at forum.vmssoftware.com then it seems
like there are still some Pascal users.

Arne

On Friday, July 15, 2022 at 9:02:58 AM UTC-4, Simon Clubley wrote:
> On 2022-07-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> > On 7/14/2022 12:18 PM, John Dallman wrote:
> >> Announced today:
> >> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
> >> ed/>
> >>
> >> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
> >> soon as more native compilers are available."
> >
> > https://vmssoftware.com/about/roadmap/ says:
> >
> > July
> > OpenVMS V9.2 (Limited Production Release)
> > ...
> > Native compilers with LLVM backend code generator:
> > BLISS, XMACRO, C++ (Phase 1)
> > ...
> > July-November
> > ...
> > Additional native compilers
> > C, COBOL, and C++ (Phase 2 ? VMS Extensions)
>
> Interesting that COBOL is a way higher priority than Fortran.
>
> I assume what that is saying is that many scientific workloads have long
> moved away from VMS.
>
> > ...
> > November/December
> > OpenVMS V9.2-1 (Production Release ? x86-64)
> > ...
> > OpenJDK for x86
> > Native compilers with LLVM backend code generator:
> > Fortran, BASIC, and Pascal
> >
> One unknown is Pascal. There's obviously still a demand for it, but how
> much of the VMS application base still uses Pascal ?
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
I have way more field test sites that use Pascal than use COBOL.

The sequence of the compilers in the roadmap is somewhat random. They may appear in a different sequence.
Write your favorite compiler on the back of a $100 bill and send it to me.

On Thursday, July 14, 2022 at 5:49:45 PM UTC-4, VAXman- wrote:
> In article <memo.20220714...@jgd.cix.co.uk>, j...@cix.co.uk (John Dallman) writes:
> >Announced today:
> ><https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
> >ed/>
> >
> >"VSI is also planning on making OpenVMS V9.2 available to hobbyists as
> >soon as more native compilers are available."
> Macro32 is all that's needed. Don't forget a native assembler too.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
>
> I speak to machines with the voice of humanity.
Yes, I plan to put a native assembler on the system too (along with most of the other
LLVM tools that fall out of the LLVM build). Things like the LLVM sanitizers, etc will be
later since they'll require work on our part to port them over.

On Friday, July 15, 2022 at 8:57:33 AM UTC-4, Simon Clubley wrote:
> On 2022-07-14, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
> > In article <memo.20220714...@jgd.cix.co.uk>, j...@cix.co.uk (John Dallman) writes:
> >>Announced today:
> >><https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
> >>ed/>
> >>
> >>"VSI is also planning on making OpenVMS V9.2 available to hobbyists as
> >>soon as more native compilers are available."
> >
> > Macro32 is all that's needed. Don't forget a native assembler too.
> >
> :-)
>
> And back in normal-land, everyone is using C, COBOL, Fortran, etc and
> don't give a damn about Macro-32 compilers. :-)
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Part of the reason why Macro-32 was first is that it needed the fewest pieces to get
it native. It still needed changes since the "assembler" interface to a current
LLVM is different than the interface for the LLVM 3.4.2 code-base. Plus
it all relied on a C++ compiler since all of LLVM is in C++ along with a single
module inside the XMACRO compiler.

In article <b53f8203-ba59-4b84-b25e-2b998bc4f2b0n@googlegroups.com>,
xyzzy1959@gmail.com (John Reagan) wrote:

> Yes, I plan to put a native assembler on the system too (along with
> most of the other LLVM tools that fall out of the LLVM build).

Presumably work will be required to provide headers for VMS system
services?

John

On 7/15/22 09:02, Simon Clubley wrote:
> On 2022-07-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/14/2022 12:18 PM, John Dallman wrote:
>>> Announced today:
>>> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>>> ed/>
>>>
>>> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>>> soon as more native compilers are available."
>>
>> https://vmssoftware.com/about/roadmap/ says:
>>
>> July
>> OpenVMS V9.2 (Limited Production Release)
>> ...
>> Native compilers with LLVM backend code generator:
>> BLISS, XMACRO, C++ (Phase 1)
>> ...
>> July-November
>> ...
>> Additional native compilers
>> C, COBOL, and C++ (Phase 2 ? VMS Extensions)
>
> Interesting that COBOL is a way higher priority than Fortran.

Might be that the COBOL compiler is easier to port than the Fortran.

>
> I assume what that is saying is that many scientific workloads have long
> moved away from VMS.
>
>> ...
>> November/December
>> OpenVMS V9.2-1 (Production Release ? x86-64)
>> ...
>> OpenJDK for x86
>> Native compilers with LLVM backend code generator:
>> Fortran, BASIC, and Pascal
>>
>
> One unknown is Pascal. There's obviously still a demand for it, but how
> much of the VMS application base still uses Pascal ?

A bigger question would be other than Dave how much of the VMS
application base still uses BASIC. :-)

bill

On 7/15/22 09:08, Arne Vajhøj wrote:
> On 7/15/2022 9:02 AM, Simon Clubley wrote:
>> On 2022-07-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 7/14/2022 12:18 PM, John Dallman wrote:
>>>> Announced today:
>>>> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>>>>
>>>> ed/>
>>>>
>>>> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>>>> soon as more native compilers are available."
>>>
>>> https://vmssoftware.com/about/roadmap/ says:
>>>
>>> July
>>> OpenVMS V9.2 (Limited Production Release)
>>> ...
>>> Native compilers with LLVM backend code generator:
>>>       BLISS, XMACRO, C++ (Phase 1)
>>> ...
>>> July-November
>>> ...
>>> Additional native compilers
>>>       C, COBOL, and C++ (Phase 2 ? VMS Extensions)
>>
>> Interesting that COBOL is a way higher priority than Fortran.
>
> I think that was to be expected.

Wonder where all of these VMS COBOL users are.
And do they need any COBOL expertise? :-)

bill

In article <taro7p$329ob$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-07-14, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <memo.20220714171951.11788A@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes:
>>>Announced today:
>>><https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
>>>ed/>
>>>
>>>"VSI is also planning on making OpenVMS V9.2 available to hobbyists as
>>>soon as more native compilers are available."
>>
>> Macro32 is all that's needed. Don't forget a native assembler too.
>>
>
>:-)
>
>And back in normal-land, everyone is using C, COBOL, Fortran, etc and
>don't give a damn about Macro-32 compilers. :-)

Long before you crawled out from under the unix slime, internals programs
on VMS were written using Macro32 and Bliss. There was a discipline that
made it easy to do so and Macro32 was a very high level assembly language.
Its assembler has a MACRO facility, unlike your beloved C launguage's pre-
processor string substitution, that allows coding reusable macro routines
that can accept an argument or three or more. It's not a powerful as the
Bliss compiler's macro facility but still pretty competent.

There are hundreds of thousands of lines of Macro32 in just the code that
I maintain for several third-party applications. In this day and age, it
is highly doubtful that the companies which own these products would pay
me to recode it all in your beloved C language and then, go through all of
the effort to verify that the rewritten code still performs like the old.
I think there was another company that put forth that same argument. If
ONLY I could only DECant its name from my vast recollection.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-07-15, John Dallman <jgd@cix.co.uk> wrote:
> In article <b53f8203-ba59-4b84-b25e-2b998bc4f2b0n@googlegroups.com>,
> xyzzy1959@gmail.com (John Reagan) wrote:
>
>> Yes, I plan to put a native assembler on the system too (along with
>> most of the other LLVM tools that fall out of the LLVM build).
>
> Presumably work will be required to provide headers for VMS system
> services?
>

I really, really hope people are not planning to write handwrite code
that calls VMS system services using the native assembler. Those days
are _long_ past.

I see the native assembler as being for bits of specialist assembly
language that directly needs to interface to things such as hardware
or for use as part of a specialist compiler backend (for example).

Those are the kinds of things native assemblers are used for elsewhere.
Nobody uses the native assembler on Linux to handwrite applications
that calls Linux system services (also for example).

If VMS later gets an ARM port (for example) all that native assembly
code would become useless and would need to be rewritten for ARM.

Simon.

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

On Friday, July 15, 2022 at 10:29:25 AM UTC-4, John Dallman wrote:
> In article <b53f8203-ba59-4b84...@googlegroups.com>,
> xyzz...@gmail.com (John Reagan) wrote:
>
> > Yes, I plan to put a native assembler on the system too (along with
> > most of the other LLVM tools that fall out of the LLVM build).
> Presumably work will be required to provide headers for VMS system
> services?
>
> John
All of those headers in SYS$STARLET_C.TLB are built by SDL and really
don't have any LLVM dependencies. We have been making changes to
some of the headers that check for DECC and DECCXX that now need to
also check for __clang__ for the C++ field test, but the rest of them should
be fine.

On Friday, July 15, 2022 at 10:33:46 AM UTC-4, Bill Gunshannon wrote:
> On 7/15/22 09:02, Simon Clubley wrote:
> > On 2022-07-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> On 7/14/2022 12:18 PM, John Dallman wrote:
> >>> Announced today:
> >>> <https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announc
> >>> ed/>
> >>>
> >>> "VSI is also planning on making OpenVMS V9.2 available to hobbyists as
> >>> soon as more native compilers are available."
> >>
> >> https://vmssoftware.com/about/roadmap/ says:
> >>
> >> July
> >> OpenVMS V9.2 (Limited Production Release)
> >> ...
> >> Native compilers with LLVM backend code generator:
> >> BLISS, XMACRO, C++ (Phase 1)
> >> ...
> >> July-November
> >> ...
> >> Additional native compilers
> >> C, COBOL, and C++ (Phase 2 ? VMS Extensions)
> >
> > Interesting that COBOL is a way higher priority than Fortran.
> Might be that the COBOL compiler is easier to port than the Fortran.

Both have their own set of unique features. COBOL needs a bunch of
packed decimal conversion routines but they are all there since a
cross-compiled COBOL app needs them. The compiler itself is pretty
boring. Fortran (and BASIC) use COMMON blocks. As I've mentioned
before, the model of common blocks on VMS is different than how
such things are represented with LLVM. G2L has to look at the GEM
intermediate symbol table from each frontend and decide how to map
those to the LLVM model. For Fortran, we get most of them right at
the moment. For BASIC (the MAP statement), well that's another story
as the BASIC frontend pushes the boundaries

John

On 2022-07-15, John Reagan <xyzzy1959@gmail.com> wrote:
> Part of the reason why Macro-32 was first is that it needed the fewest pieces to get
> it native. It still needed changes since the "assembler" interface to a current
> LLVM is different than the interface for the LLVM 3.4.2 code-base. Plus
> it all relied on a C++ compiler since all of LLVM is in C++ along with a single
> module inside the XMACRO compiler.

Believe me, I am very aware of the fact LLVM is written in C++. :-)

I am also aware that the LLVM team keeps moving to the latest "shiny" on
a regular basis instead of developing LLVM against a C++ standard that
has been available for a long time. I see they are currently at C++14.
I wonder when they will be moving again. :-)

Update: I had a look. It seems they are already talking about moving
to C++17 as the new base. :-(

See:

https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm/59983

Simon.

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

On Friday, July 15, 2022 at 10:29:25 AM UTC-4, John Dallman wrote:
> In article <b53f8203-ba59-4b84...@googlegroups.com>,
> xyzz...@gmail.com (John Reagan) wrote:
>
> > Yes, I plan to put a native assembler on the system too (along with
> > most of the other LLVM tools that fall out of the LLVM build).
> Presumably work will be required to provide headers for VMS system
> services?
>
> John
Simon's post made me think. Are you talking about some headers for
native assembler coding? Like the macros we provide for Macro-32
coding? No. Nothing like that.

We did create a new SDL backend to create native assembler constants
and such but nothing like routine prototypes, etc

On 2022-07-15, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>
> There are hundreds of thousands of lines of Macro32 in just the code that
> I maintain for several third-party applications. In this day and age, it
> is highly doubtful that the companies which own these products would pay
> me to recode it all in your beloved C language and then, go through all of
> the effort to verify that the rewritten code still performs like the old.
> I think there was another company that put forth that same argument. If
> ONLY I could only DECant its name from my vast recollection.
>

C isn't beloved by me Brian. It is however the most practical and viable
language to use in a wide range of applications unfortunately.

As I have made clear _many_ times, I wish something from the Wirth side
of the language ecosystem had become established as a standard and viable
alternative to C. Unfortunately, I have to work with what is available
and viable, not what I would like to use in an ideal world.

Simon.

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

On 2022-07-15, John Reagan <xyzzy1959@gmail.com> wrote:
> On Friday, July 15, 2022 at 10:29:25 AM UTC-4, John Dallman wrote:
>> In article <b53f8203-ba59-4b84...@googlegroups.com>,
>> xyzz...@gmail.com (John Reagan) wrote:
>>
>> > Yes, I plan to put a native assembler on the system too (along with
>> > most of the other LLVM tools that fall out of the LLVM build).
>> Presumably work will be required to provide headers for VMS system
>> services?
>>
>> John
> All of those headers in SYS$STARLET_C.TLB are built by SDL and really
> don't have any LLVM dependencies. We have been making changes to
> some of the headers that check for DECC and DECCXX that now need to
> also check for __clang__ for the C++ field test, but the rest of them should
> be fine.

Based on how he wrote it, I took that as meaning wanting to call VMS
system services from native assembler code.

Simon.

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

On 7/15/2022 2:04 PM, Simon Clubley wrote:
> On 2022-07-15, John Reagan <xyzzy1959@gmail.com> wrote:
>> On Friday, July 15, 2022 at 10:29:25 AM UTC-4, John Dallman wrote:
>>> In article <b53f8203-ba59-4b84...@googlegroups.com>,
>>> xyzz...@gmail.com (John Reagan) wrote:
>>>
>>>> Yes, I plan to put a native assembler on the system too (along with
>>>> most of the other LLVM tools that fall out of the LLVM build).
>>> Presumably work will be required to provide headers for VMS system
>>> services?
>>>
>>> John
>> All of those headers in SYS$STARLET_C.TLB are built by SDL and really
>> don't have any LLVM dependencies. We have been making changes to
>> some of the headers that check for DECC and DECCXX that now need to
>> also check for __clang__ for the C++ field test, but the rest of them should
>> be fine.
>
> Based on how he wrote it, I took that as meaning wanting to call VMS
> system services from native assembler code.

Yeah, people do funny stuff, sometimes just for fun.

Like the time I wrote a rudimentary disk defragger in BASIC.

Yes, it worked, but it had no blade guards, since I wasn't taking out
any of the file system locks.

--
-- Rob

On 7/15/2022 10:35 AM, Bill Gunshannon wrote:
> On 7/15/22 09:08, Arne Vajhøj wrote:
>> On 7/15/2022 9:02 AM, Simon Clubley wrote:
>>> On 2022-07-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> https://vmssoftware.com/about/roadmap/ says:
>>>>
>>>> July
>>>> OpenVMS V9.2 (Limited Production Release)
>>>> ...
>>>> Native compilers with LLVM backend code generator:
>>>>       BLISS, XMACRO, C++ (Phase 1)
>>>> ...
>>>> July-November
>>>> ...
>>>> Additional native compilers
>>>>       C, COBOL, and C++ (Phase 2 ? VMS Extensions)
>>>
>>> Interesting that COBOL is a way higher priority than Fortran.
>>
>> I think that was to be expected.
>
> Wonder where all of these VMS COBOL users are.

You do see COBOL questions here occasionally.

It seems fair to assume that some portion of VMS
sites has some business applications in Cobol
using either index-sequential files or Rdb (or maybe
even traditional Oracle).

Arne