[Info-vax] HP wins Oracle Itanium case

[David Froble]

Stephen Hoffman wrote:
> 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.

I agree with Bob ..

I'll also point out that for your data, there is no need to use RMS if you 
desire not to do so.  QIO works for reading and writing data.  Mount /Foreign 
and roll your own if you don't like ODS.

On the other side, providing RMS allows various languages to access data files 
without the requirement of providing the underlaying file system.

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

Oh, good, I finally get to be the devil's advocate, not the defense :-)

> o RMS files don't defragment themselves,

Short of some Relational databases, is there any file system anywhere that does 
this?  And even in something that does, can it be done without copying the data 
elsewhere?

> and indexed files don't pack 
> old records.

Give ya this one, my DAS database system doesn't either.  I've looked at it more 
than once, and the hassle doesn't seem worth the effort.  However, a programmer 
can re-use a deleted record.

< The programmer or the end-user has to deal with that mess.

It was ever thus ..
Isn't that why we have programmers ??

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

Some people consider marketing decisions a technical issue.  I don't.  But I can 
consider it a royal PITA.

Sychronizing any database software with an application has always been a tough 
nut to crack.

> o RMS files (and disks) don't scale past two terabytes.

Did any pre-1990 OS?  Maybe ever any pre-2000 OS?  Let's be fair in case we're 
doing any comparisons.  Or if we're just listing lack of updating when it should 
happen, well, isn't that what these discussions are all about?  HP not 
continuing VMS development?

> o RMS programming routines have an exceedingly arcane programming 
> interface.

If calling RMS directly, I got to agree.  If using RMS from a HLL, then I don't 
agree.  RMS benefits the VMS HLLs.

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

That's more like, the rest of the world came up with something different, and if 
there was to be interchange of data, RMS needed to implement that used by 
others.  At least it can adapt.  How well do other OS handle RMS files?  They 
are the ones having trouble adapting.

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

Is there any method to do this?  If the record can be found only by it's 
position in the file, then the calculations to find a record need some fixed 
information, such as record length.  Now, if you're going to have some pointer 
to each record so it can be found, well, isn't that an index?

Are you suggesting that there are data storage models that can have variable 
length relative records without some type of pointer?  If so, I'd be interested 
in knowing about them.  That would be very educational.

> o RMS record and I/O data transfers are limited in size.

As are most things in this universe.  At some time in the past 32767 bytes was 
considered quite large.  Time changes all things.  Did Unix in 1970 have any I'O 
limits?  If so, and they were modified, then that just takes us back to lack of 
ongoing development of VMS.

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

As I'm not sure what "marshalling" is, I'm assuming it's defining and accessing 
the pieces of a data record.  That's always been one of my complaints about RMS, 
that the data file system doesn't know a dang thing about what's in the records.

The DAS database system I mentioned above contains this "marshalling" 
information within the file, and the database routines assign labels, if 
desired, to the data fields in a data record when the record is read.  This 
dynamic labeling is more labor intensive, but, allows for many utility programs 
for manipulating the data files, records, and data fields.

> o VMS (and RMS) doesn't implement application sandboxing.

Without having huge amounts of memory available, what does?

My preference is development and testing systems.

> o RMS doesn't implement action routines; there are no built-in triggers 
> for activity, short of repurposing the security APIs.

Examples?  What would such be used for?

> o RMS doesn't have a way to set a default sequential file format.

Well, it did once, until it had to be modified to support multiple formats.  But 
yeah, being able to have a consistent default would be a good thing.

> o RMS lacks an API and storage for application metadata, beyond 
> repurposing an ACE.

Ya know, I don't get out much, so, just what would this be, and what could it be 
used for?

> o RMS lacks a data replication API; HBVS and journaling are it.

Agreed.

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

I've heard this many times, and I agree that it is a problem.  But how large of 
a problem.  Assume that you could journal all activity that didn't make a 
backup, and then included that data with the backup.  Sure, you could restore as 
of the point in time when the backup finished, but for a 24 x 365 application, 
just how much does that help?

As mentioned before, I don't get out much, so I'm asking, is there any system 
anywhere that can perform an online backup and always get it 100% right, and if 
it does, what about subsequent activity?

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

And the reason DAS has this offline capability is to allow quick and easy 
modification.  It's still copying data from a source to a destination.

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

As for file storage, you're correct.  Does any other OS allow multiple file 
systems on the same disks?  I frankly don't see how this could be done.  One 
file system per disk, yes, I can see that, and that is might be useful, if the 
tools to use multiple file systems existed.

I guess an example would be Weendoze handling both NTFS and FAT.  I'm assuming 
that there is different code for each.  Or possibly different code for certain 
operations.

Would ODS-2 and ODS-5 be considered different file systems?

> o Add a key to an existing indexed file.  Or remove it.  Go ahead.  Try 
> it.  Make my day.

That was always another of my problems with RMS.  In an indexed file, the bottom 
level keys were actually the data record.  To change the primary key, you needed 
to move the entire data record.

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

Like paging, huh?

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

Anything that resides on disk is slow.  Cache it all up in memory and you'll see 
a difference.  RMS was designed and implemented in a time where memory was 
measured in KB, not MB, and GB was unthinkable.

> 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 can appreciate the concept of having more than one file system available, and 
more than one database system available.  On VMS I've practiced that, using both 
RMS and DAS.