OpenVMS V9.2-3 and compiler updates

[jreagan]

Compiler Topics

To go along with the various compiler updates, you'll notice that BASIC wasn't listed in today's announcement. I'm building the kit right now (the testing looks fine).

The current BASIC V1.9 kit provides a hot RTL on the kit for installations on V9.2-2.

I *HATE* shipping RTLs on compiler kits. Years of experience says it never works out well. V9.2-3 contains the correct BASIC RTL.

I'm going to change the BASIC kit I'm working on to require V9.2-3. It will allow me to get out of the "ship a BASIC RTL on the kit". The longer you try to make it work, the worse it gets.

Speaking of "the worse it gets", the C++ compiler continues to bundle RTLs for installations on V9.2-1 and V9.2-2 systems. V9.2-3 contains the correct C++ RTLs. We tried to get the PCSI generation numbers correct in the C++ kit such that anyone who has C++ V10.1-2 installed on V9.2-2 and then upgrades to V9.2-3 would get the right RTLs. Nope. Doesn't work. If you read the V9.2-3 release notes carefully, you'll see that existing C++ customers have to uninstall C++ before an upgrade from V9.2-2 to V9.2-3, then install C++ V10.1-2 fresh afterwards. Sorry about that.

Also note that V9.2-3 no longer provides any cross-compilers. With all the compilers now available natively, there is no need to use them.

And finally, I think the next round of compilers (other than BASIC) will require at least V9.2-2 and later.

John

[greg@tssolutions.com.au]

Hi Arne

While I sort of agree, it is 30+ years that I have been fighting for full 64bit, yup before AXP was released...

If VSI wants OpenVMS to be sold to new companies it needs all this done, and yes it is a huge effort and yes the work done so far has been incredible engineering effort.

It is a pity, and water under the bridge, that a lot of opportunities has been lost over that 30+ years. For me SSIO is an example of that where a lot of engineering effort was spent for no real return.

The question today is what low hanging fruit can VSI, with its partners and ambassadors, can identify. At the same time have a clear direction to work towards, e.g. DCL64/RMS64(128)...., all with backwards compatibility.

After all these years still am positive about OpenVMS's future.

[arne_v]

I don't understand why you have so much against SSIO.

It solves a specific problem that is relevant for porting some *nix applications to VMS.

Priorities can always be discussed, but porting *nix applications to VMS is a real thing.

[greg@tssolutions.com.au]

SSIO is not a OpenVMS type solution, and it is not Cluster safe.

The much simpler CRTL fix (using RMS...) is much lower cost, and is cluster safe.

[arne_v]

I don't think the problem in question can be solved in CRTL or RMS.

The problem exist as long as the underlying system service - SYS$QIO(W) or SYS$IO_PERFORM(W) - operate on blocks ond not bytes.

[greg@tssolutions.com.au]

it absolutely can be solved in CRTL, I wrote a test sample...

[arne_v]

Without adding extra locking then it is impossible.

And adding extra locking is not good - VMS need faster IO not slower IO.

[greg@tssolutions.com.au]

You keep saying it is not possible
I keep saying I did it.

🫤

[arne_v]

Based on the old slides then it is a totally standard read+write needing sync to prevent concurrency problems.

Process 1 want to write "AB" to byte 0-1
Process 2 want to write "CD" to byte 2-3

With byte IO:

Process 1:
1) write "AB" to byte 0-1
Process 2:
2) write "CD" to byte 2-3

no concurrency problem.

With block IO:

Process 1:
1) read byte 0-511 to process buffer
2) move "AB" into process buffer byte 0-1
3) write byte 0-511 from process buffer

Process 2:
1) read byte 0-511 to process buffer
2) move "CD" into process buffer byte 2-3
3) write byte 0-511 from process buffer

without added synchronization then that is not safe.

[greg@tssolutions.com.au]

So we uae RMS to do the sync
To do that we don't use read/write
Look at what I posted 2 years ago

[arne_v]

Process 1:
1) acquire exclusive lock on block 0
2) read byte 0-511 to process buffer
3) move "AB" into process buffer byte 0-1
4) write byte 0-511 from process buffer
5) release lock

Process 2:
1) acquire exclusive lock on block 0
2) read byte 0-511 to process buffer
3) move "CD" into process buffer byte 2-3
4) write byte 0-511 from process buffer
5) release lock

is safe.

But it both adds locking overhead and wait time.

It does not matter what code does the locking.