[Info-vax] HP wins Oracle Itanium case

[Johnny Billquist]

On 2012-08-23 01:17, David Froble wrote:
> Johnny Billquist wrote:
>> 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
>>
>>
>
> On ODS type disks, on VMS, it's my understanding that the directories
> are RMS files, or sort of ..   Thus the impression that VMS and RMS are
> tied together. In a way they are, but, it is possible to have other
> files, I do, and don't depend very much on RMS.  Used RMS for the
> filename parsing, no sense re-inventing the wheel, and if it changes,
> RMS will already be modified for you.  But after that, no calls to RMS.

I can tell that ODS-1 directories are files with 16 byte fixed length 
records. But when you do directory operations in RSX, you read one block 
at the time, and then you do the fiddling yourself (or rather, your 
library do). You might not be using RMS at all, but might be using FCS, 
or you might be using your totally own thing. The attributes of the 
directory file can be used, if you so like, but that would be a rather 
inefficient way to deal with it.

.dsp [0,0]000000.dir

DU:[0,0]000000.DIR;1
                         Size:    8./8.           Created: 08-JUN-2005 00:21
                         Owner:   [001,001]       Revised: <none_specified>
                         File ID: (4,4,0)         Expires: <none_specified>
   File protection:      System:RWED, Owner:RWED, Group:RWED, World:R
   File organization:    Sequential
   File attributes:      Allocation=8, Extend=0, Contiguous
   Record format:        Fixed length 16 byte records
   Record attributes:    None

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol