Fantastic to see a release of OpenVMS on X86-64, huge effort by a lot of people.

My question is whats next?

There is a large list of things on the wish list, and interestingly as soon as the release announcement was made the first thing people mentioned was the 32 vs 64 confusion that exists.
This has been an ongoing point of contention for over 10 years, just look back at some of the older posts. For me it has been ongoing for 30 years, this year.

I had previously posted about not using SSIO, rather fixing CRTL. I then wrote from sample 32bit code as a proof of concept. This code has now been altered use RAB64, i.e. cc/point=64. Well that was a whole heap of fun, and underlined for me as to the importance of OpenVMS becoming a PROPER 64 bit OS. It also made be realize that call RMS a record manage system is incorrect, it has 3 parts (read the doco) file handling, record management, RAW IO. A much better name to avoid confusing the lx/Ux group is VMSIO.

Any well done John etl, look forward to even more improvements.
gt, downunder

On 2022-07-20, Greg Tinkler <tinklerg@gmail.com> wrote:
> Fantastic to see a release of OpenVMS on X86-64, huge effort by a lot of people.
>
> My question is whats next?
>

Some will ask for it to be easier to get software created elsewhere
running on VMS.

Some will ask for it to be easier to get VMS to interact with the other
operating systems people are running these days.

Some will ask for a new VMS filesystem.

Some will ask for fork().

Some will ask for VMS on ARM.

Some will ask for security enhancements so VMS is brought up to the
security standards expected these days.

Some will ask for a decent version of DCL that has the standard features
you see elsewhere in shells like bash.

Some will say, sod all that, I've got my Macro-32 compiler.

Some will ask for a VMS desktop and a VMS native web browser.

Some will ask for a version of TECO for x86-64 VMS.

Many will ask for permanent production licences or some form of guaranteed
legal escrow to stop their companies going bust if VSI goes bust.

> There is a large list of things on the wish list, and interestingly as soon as the release announcement was made the first thing people mentioned was the 32 vs 64 confusion that exists.
> This has been an ongoing point of contention for over 10 years, just look back at some of the older posts. For me it has been ongoing for 30 years, this year.
>
> I had previously posted about not using SSIO, rather fixing CRTL. I then
> wrote from sample 32bit code as a proof of concept. This code has now been
> altered use RAB64, i.e. cc/point=64. Well that was a whole heap of fun,
> and underlined for me as to the importance of OpenVMS becoming a PROPER 64
> bit OS. It also made be realize that call RMS a record manage system is
> incorrect, it has 3 parts (read the doco) file handling, record management,
> RAW IO. A much better name to avoid confusing the lx/Ux group is VMSIO.
>

At this point in time a pure 64-bit environment isn't going to happen.
Unfortunately. It would break way too much, and with not enough reward
for the effort involved.

BTW, calling RMS VMSIO would be confusing because of the QIO interface.

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-20 07:59, Greg Tinkler wrote:
> I had previously posted about not using SSIO, rather fixing CRTL. I then wrote from sample 32bit code as a proof of concept. This code has now been altered use RAB64, i.e. cc/point=64. Well that was a whole heap of fun, and underlined for me as to the importance of OpenVMS becoming a PROPER 64 bit OS. It also made be realize that call RMS a record manage system is incorrect, it has 3 parts (read the doco) file handling, record management, RAW IO. A much better name to avoid confusing the lx/Ux group is VMSIO.

Admittedly, my RSX knowledge is going to shine through here again. But
actual file handling is, I believe, part of the Files-11 ACP (and XQP).
Not RMS. Now, I don't know if you can do things totally dodging RMS
under VMS. But in RSX, you certainly can. The QIO interface to deal with
files is rather different than what RMS gives you, but this is where
actual file processing takes place. RMS depends on that layer, and are
just operating on files as such. The actual handling of the file is done
outside of the file (things like managing protection, access, allocating
blocks to files, or free them, and so on...).

Johnny

On 7/20/2022 7:32 PM, Johnny Billquist wrote:

> Now, I don't know if you can do things totally dodging RMS under VMS.
Yes, you can use the documented ACP QIO interface (named before the XQP
existed), but if you expect standard VMS utilities, like TYPE, to be able to
display the contents of the file, you must adhere to the expected record format.

--

--- Rob

On 7/20/2022 7:32 PM, Johnny Billquist wrote:
> On 2022-07-20 07:59, Greg Tinkler wrote:
>> I had previously posted about not using SSIO, rather fixing CRTL. I then
>> wrote from sample 32bit code as a proof of concept. This code has now been
>> altered use RAB64, i.e. cc/point=64. Well that was a whole heap of fun, and
>> underlined for me as to the importance of OpenVMS becoming a PROPER 64 bit
>> OS. It also made be realize that call RMS a record manage system is
>> incorrect, it has 3 parts (read the doco) file handling, record management,
>> RAW IO. A much better name to avoid confusing the lx/Ux group is VMSIO.
>
> Admittedly, my RSX knowledge is going to shine through here again. But actual
> file handling is, I believe, part of the Files-11 ACP (and XQP). Not RMS. Now, I
> don't know if you can do things totally dodging RMS under VMS. But in RSX, you
> certainly can. The QIO interface to deal with files is rather different than
> what RMS gives you, but this is where actual file processing takes place. RMS
> depends on that layer, and are just operating on files as such. The actual
> handling of the file is done outside of the file (things like managing
> protection, access, allocating blocks to files, or free them, and so on...).

Long ago when implementing a database product, we used the RMS routine(s) for
parsing a filespec. Hey it was already there, why re-invent it? But that was
all of the usage of RMS. The file I/O was totally QIO. Another thing that was
available is the DLM, and of course we used that, even though we already had
some locking software based sort of on RSTS locking.

--
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 7/20/2022 7:32 PM, Johnny Billquist wrote:
> On 2022-07-20 07:59, Greg Tinkler wrote:
>> I had previously posted about not using SSIO, rather fixing CRTL.  I
>> then wrote from sample 32bit code as a proof of concept.  This code
>> has now been altered use RAB64, i.e. cc/point=64.  Well that was a
>> whole heap of fun, and underlined for me as to the importance of
>> OpenVMS becoming a PROPER 64 bit OS.  It also made be realize that
>> call RMS a record manage system is incorrect, it has 3 parts (read the
>> doco) file handling, record management, RAW IO.  A much better name to
>> avoid confusing the lx/Ux group is VMSIO.
>
> Admittedly, my RSX knowledge is going to shine through here again. But
> actual file handling is, I believe, part of the Files-11 ACP (and XQP).
> Not RMS. Now, I don't know if you can do things totally dodging RMS
> under VMS. But in RSX, you certainly can. The QIO interface to deal with
> files is rather different than what RMS gives you, but this is where
> actual file processing takes place. RMS depends on that layer, and are
> just operating on files as such. The actual handling of the file is done
> outside of the file (things like managing protection, access, allocating
> blocks to files, or free them, and so on...).

You can open, read, write and close files using SYS$QIOW.

It is block based and you need to both handle the record
format in application code and for write remember to extend
the filed when needed.

It is work but not that bad.

What is really bad is to get from file name to FID. Which I
think even in this case it is common to use RMS to get the FID
and then use SYS$QIOW from there.

Arne

<snip>
Using $QIO is fine for us old VMSers, but if you want to play in the 'new' commercial pack then you need higher level programming.
Hence why VSI has I believed VSI has rightly focused on C/C++ and getting it more up to date with the current standards. Fantastic effort by John R.

Now, well once the dust has settled a little with the compilers, to focus on the next layer which is the RMS (VMSIO) layer, then the $QIO/XQP/XFC layer.
As part of that will need to be DCL64, just to support VMSIO-64/RMS64.

Yup there is a huge range of thing that would be good to have done, but all depends on getting RMS/$QIO to 64 bit.

gt

On Friday, July 22, 2022 at 6:21:01 AM UTC+2, tink...@gmail.com wrote:
> <snip>
> Using $QIO is fine for us old VMSers, but if you want to play in the 'new' commercial pack then you need higher level programming.
> Hence why VSI has I believed VSI has rightly focused on C/C++ and getting it more up to date with the current standards. Fantastic effort by John R.
>
> Now, well once the dust has settled a little with the compilers, to focus on the next layer which is the RMS (VMSIO) layer, then the $QIO/XQP/XFC layer.
> As part of that will need to be DCL64, just to support VMSIO-64/RMS64.
>
> Yup there is a huge range of thing that would be good to have done, but all depends on getting RMS/$QIO to 64 bit.
>
> gt

Some may think RISC-V is a decent target, with the hypervisor of course.

^P

On 22/07/2022 12:20 pm, Greg Tinkler wrote:
> <snip> but if you want to play in the 'new' commercial pack then you
> need higher level programming. Hence why VSI has I believed VSI has
> rightly focused on C/C++

Disbelief!

On Saturday, 23 July 2022 at 11:39:41 am UTC+10, Richard Maher wrote:
> On 22/07/2022 12:20 pm, Greg Tinkler wrote:
> > <snip> but if you want to play in the 'new' commercial pack then you
> > need higher level programming. Hence why VSI has I believed VSI has
> > rightly focused on C/C++
> Disbelief!

Disbelief???

If you want almost any open source app you need c/c++, and also need CRTL to appear as close to Linux as possible.

gt

On 7/24/2022 8:51 PM, Greg Tinkler wrote:
> On Saturday, 23 July 2022 at 11:39:41 am UTC+10, Richard Maher wrote:
>> On 22/07/2022 12:20 pm, Greg Tinkler wrote:
>>> <snip> but if you want to play in the 'new' commercial pack then you
>>> need higher level programming. Hence why VSI has I believed VSI has
>>> rightly focused on C/C++
>> Disbelief!
>
> Disbelief???
>
> If you want almost any open source app you need c/c++, and also need CRTL to appear as close to Linux as possible.

Almost any open source app *in native code*.

Excluding the 3/4 that are in script languages, JVM languages
and CLR languages.

Arne

And what are those scripting engines written in?

gt

On 2022-07-24, Greg Tinkler <tinklerg@gmail.com> wrote:
> On Saturday, 23 July 2022 at 11:39:41 am UTC+10, Richard Maher wrote:
>> On 22/07/2022 12:20 pm, Greg Tinkler wrote:
>> > <snip> but if you want to play in the 'new' commercial pack then you
>> > need higher level programming. Hence why VSI has I believed VSI has
>> > rightly focused on C/C++
>> Disbelief!
>
> Disbelief???
>

Yes. There's a major COBOL base on VMS.

> If you want almost any open source app you need c/c++, and also need CRTL to appear as close to Linux as possible.
>

In this case, your comment seemed to be talking about application
programming languages in use on VMS, not the languages that open source
tools to be ported to VMS are written in.

Simon.

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

On 7/25/2022 4:38 AM, Greg Tinkler wrote:
> And what are those scripting engines written in?

That is a good point.

While C/C++ is a relative small part of the open source
development today, then practically all the interpreters,
VM's and runtimes available that run non-native code
are C/C++ based.

Arne