[Info-vax] HP wins Oracle Itanium case

[Bob Koehler]

In article <k10u46$iuh$1 at dont-email.me>, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
> 
> 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.

   I've got lots of file systems that don't defrag themselves.

> 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.

   RMS is not a DBMS.

> o RMS files (and disks) don't scale past two terabytes.
> o RMS programming routines have an exceedingly arcane programming interface.

   Like the C RTL?  If you can program in C, you are using RMS.

> o RMS sequential files force the user to deal with slightly different 
> formats, particularly when transferring files around.

   Only when using brain dead network applications.

> o RMS relative files lack sparse storage capabilities; you're pushed 
> over into index files if you need that.

   And byte streams fixes that how?

> 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.

   Not if you're simply using byte streams, or undefined format.

> 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.

   Hm, haven't seen a data replication API that I'd prefer over HBVS,
   or exsiting storage solutions that solve that problem for the host.

> 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.

   RMS is not a DBMS.

> 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.)

   RMS means you don't typically need one.  Using a byte stream API? 
   RMS and the RTLs mean you can access record files anyhow.  Using a
   record oriented API?  RMS and the RTLs let you access byte stream
   files anyhow.

> 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.

   RMS is not a DBMS.

> 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)

   No, it does not.  See above.

> o No built-in tools to assist with file format and data conversions, 
> beyond CONVERT /FDL and friends.
> o It's slllllloooooowwwww.

   That's mostly in buffering control.  VMS lets you control that.  UNIX 
   lets you add code.  They just start from opposite ends on speed vs. 
   reliability.

> ...
> 
> 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.)

   I'd prefer to buy an RMS which has had millions of copies running
   successfully, than write and debug my own.  Or hide one like TOPS-20
   folks did.