[Info-vax] HP wins Oracle Itanium case

[Johnny Billquist]

On 2012-08-22 15:05, ChrisQ wrote:
> In the end though, what get's stored on disk is a stream of bytes at the
> lowest
> level. To make the most flexible use of that, an interface to that
> stream should
> be provided, even if there are other structures eg: rms, above. Someone
> else
> said that the qio interface could be used, but seem to remember that as
> being
> fairly arcane at the time.

Uh... No. At the lowest level of a disk, you do *not* store a stream of 
bytes. Where on earth did you get that from? At the lowest level, a disk 
deals with disk *blocks*. You read/write one block at a time.
Blocks are typically 512 bytes, or possibly 2048 or 4096 bytes nowadays.

I don't offhand feel safe enough to comment VMS specific here, but 
atleast in RSX, QIO *is* the interface used to read/write blocks. RMS is 
a library on top of this, and RMS uses QIO internally to actually 
perform the disk activities.

As such, you can also implement any other file structure in RSX pretty 
easily. You only need provide the same interface specified at the QIO 
level, and you're set.

And actually, all the I/O operations done by RMS is done to the disk 
device, but are in reality caught by the ACP, which then do the physical 
I/O operations to the disk.
So, write another ACP, that implements your file system, and just plug 
it in, and off you go.

> I guess the argument is whether structure like rms should be integrated
> into the
> filesystem, or whether it should be a separate layer. Provided it's done
> right,
> either approach should be equally valid afaics...

I'm sure there must be some way of going around RMS in VMS, so is it 
really integrated in the file system? Can't you dump a file as the disk 
blocks doing analyze, for example. What relation do RMS have there, 
since you are ignoring the file attributes, and process the blocks 
exactly as they happen to be stored on the disk?

	Johnny