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

I am not disagreeing with the some what simplified logic, I am simply getting RMS to do it.

The locking cost is a cluster issue, and welcome to VMS. Ideally there should be some optimization around the use of locks, e.g. if the file is lock exclusive don't bother.

Also like all bucket/buffer locking there would be a sequence number in the lock VALBLK, that way we know if we need to read it or not. Again RMS already does this, for non $READ/$WRITE access.

And of course if the record goes over the block boundary, that needs to be handled. And RMS already does this...

My RMS wish list:
1) $READ/$WRITE do buffer sync
2) $READ/$WRITE with byte offset, i.e. not just block
3) proper 64 bit addressing for all pointers (RAB/FAB/FIB...)
4) while we are at it, builtin longer term support for 128 bit byte ranges/file systems
i.e. future proof RMS/VMS

1 & 2 would solve the C read/write/pread/pwrite issues

If SSIO was cluster safe then use it for $READ/$WRITE, so everyone can benefit.

PS you gave some pointers to the RMS solution using $MODIFY()

[arne_v]

I don't think anyone consider SSIO to be a solution for everything.

It is a solution for a very specific problem that probably only is a problem when porting a certain category of applications from *nix to VMS.

It has changed priority a few times low->high->low.

RMS could definitely use some enhancements. I think the 32 KB limits are a significant problem.

But as usual there are backwards compatibility issues. VSI can't change existing data structures or routines. So they will need to create new data structures and routines.

The good thing is that HLL RTL's can hide the switch and that both ORG and RFM has available bits to support changes in on disk format.

Just a lot of work for VSI. It will take time and money.