[Info-vax] RMS - Wish list

[Greg Tinkler]

<snip>
> > Even the example given for SSIO was a block of bytes, i.e. a record, needing to be updated somewhere on a disk block(s). That is NOT stream access.
> As Craig as already pointed out, that is not correct. 
Look at "Open Source and UNIX portability" page 10 - 12, "Example victim program", "Block I/O: Lost update problem"

> You are obviously one of those VMS people who are unwilling to 
> accept that the part of VMS they care about (RMS on your case) 
> is somehow limited to the usage models that were in use when 
> their part of VMS was designed. 
> 
> You are coming across as no different to those out of touch people 
> who like to go around claiming that VMS is the most secure 
> operating system on the planet and utterly ignore any evidence 
> to the contrary. 
Please Simon, as I stated before we need to agree to disagree. And no I don't need to justify who I am any more than you do.

> Likewise, you are also utterly ignoring the evidence that RMS is 
> NOT the solution for the new SSIO requirements. 
Strong words. Please see above.

> Times change and requirements change. RMS was designed in an 
> era when records were the unit of access. RMS can still be used 
> when records are the unit of access, but different requirements 
> outside of this require different solutions. 
I agree RMS was designed a long time ago and needs updating.  NB this is why DBMS/Rdb where created 40 years ago.  Such a big loss when they were sold for niks.  (10c on th $)
It is also probably why VSI wants to port PostgresSQL.

That said, what was also raised was the engineering issues VSI are having with SSIO, so my suggestion such as it is, that for a LOT less engineering effort RMS could be cleaned up solve the issues mentioned in the "Open Source and UNIX portability" document.  With benefit to all RMS users.
NB The CRTL was also written decades ago so needs some clean up.

gt downunder