[Info-vax] HP wins Oracle Itanium case

[Stephen Hoffman]

On 2012-08-21 20:37:44 +0000, Bob Koehler said:

> In article <zCQYr.12412$7h.10088 at fx23.am4>, ChrisQ <meru at devnull.com> writes:
>> On 08/21/12 17:33, Bob Koehler wrote:
>>> In article<b9NYr.4322$3p2.4259 at fx03.am4>, ChrisQ<meru at devnull.com>  writes:
>>>> 
>>>> As for RMS, a file system is to store bytes and any imposed structure on
>>>> the data should be layered on elsewhere. So yes, you will have to write it
>>>> yourself :-)...
>>> 
>>> "a file system is to store bytes"
>>> 
>>> Nope.  Meaningless hype.
>> 
>> ymmv, but the ideal file system really doesn't want to know about
>> various data
>> formats. It's main function is to store and retrieve data.
> 
>    Nope.  Disks are made to store and retrive data, filesystems to
>    organize it.

And then there are the things I find frustrating about the file system,
and I'm here lumping VMS mechanisms such as mount, RMS, and the XQP, 
together...

o RMS files don't defragment themselves, and indexed files don't pack 
old records.  The programmer or the end-user has to deal with that mess.
o RMS files require an extra license and related coding for 
transactional processing and rollbacks, and the transactional API 
doesn't document any means of synchronization with the other activities 
that might be necessary within an application.
o RMS files (and disks) don't scale past two terabytes.
o RMS programming routines have an exceedingly arcane programming interface.
o RMS sequential files force the user to deal with slightly different 
formats, particularly when transferring files around.
o RMS relative files lack sparse storage capabilities; you're pushed 
over into index files if you need that.
o RMS record and I/O data transfers are limited in size.
o RMS files require you to deal with records, rather than dealing with 
your data; there are no marshalling and unmarshalling APIs.
o Heck, there's no concept of marshalling and unmarshalling anywere; I 
have to roll my own data structures with SDL or {whatever}.
o VMS (and RMS) doesn't implement application sandboxing.
o RMS doesn't implement action routines; there are no built-in triggers 
for activity, short of repurposing the security APIs.
o RMS doesn't have a way to set a default sequential file format.
o RMS lacks an API and storage for application metadata, beyond 
repurposing an ACE.
o RMS lacks a data replication API; HBVS and journaling are it.
o VMS had (has?) a separate shelving package and tools for nearline 
archiving and restoring files.
o VMS (and RMS) lacks the application synchronization primitives for a 
consistent on-line BACKUP.
o RMS lacks a way to modifying the structure of an existing file in 
place; you're left to either implement this record translation yourself 
at run-time, or rewrite the file.  (This made SYSUAF upgrades all the 
more interesting, as there was no good way to do that across versions.)
o And VMS doesn't support variant file systems; there's no API for 
inserting your own file system underneath RMS, or a replacement for RMS.
o Add a key to an existing indexed file.  Or remove it.  Go ahead.  Try 
it.  Make my day.
o RMS forces me to read records in, and to write them out.  Personally, 
I'd rather let RMS deal with that, and just hand me the data.  (See 
marshalling, et al)
o No built-in tools to assist with file format and data conversions, 
beyond CONVERT /FDL and friends.
o It's slllllloooooowwwww.
...

And I am sure I can find a few more things that annoy me about RMS or 
the XQP here, too.

Things that don't annoy me about RMS?  RMS is wicked-good at not 
corrupting itself.  Which is very important.

RMS was a great idea well into the 1980s.   And it's a marvelously 
well-engineered system.  But it's really gotten quite feature-stale in 
the ensuing decades.  And it lends itself to the one-size fits all 
approach of application design, which usually then leads to busted 
applications, difficulty with backups, and other messes.

And yes, there are a number of applications that can (and do) (and 
should) still use RMS.  I have a number of them, and will likely have 
more.

But in the end, I find the Unix approach of allowing me to layer on 
whatever system I need much more flexible.  (The days of rolling my own 
record-level storage system are largely gone, except when I'm working 
on VMS with RMS, and without the benefit of a database in the target 
environment.)


-- 
Pure Personal Opinion | HoffmanLabs LLC