[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[Stephen Hoffman]

On 2016-06-18 20:59:14 +0000, John Reagan said:

> On Saturday, June 18, 2016 at 3:02:29 PM UTC-4, Stephen Hoffman wrote:
>> On 2016-06-18 18:07:05 +0000, Paul Sture said:
>> 
>>> both XAB$L_EBK and XAB$W_FFB Field are "meaningful for sequential files only"
>> 
>> I'd prefer that any (errant) requests violating that would kick back a 
>> run-time error when used on inappropriate file formats, but that 
>> concept and that capability simply does not exist within the (current) 
>> OpenVMS RMS APIs.
>> 
>> Ugly case would be an explicit NaN/NaT returned in these fields 
>> secondary to an errant access; a Not a Number or Not a Thing response. 
>> OpenVMS and various databases certainly have have examples akin to 
>> that, but OpenVMS has no particularly consistent implementation of 
>> that.  In more than a few fields in the various data structures, RMS 
>> doesn't, though.
> 
> NaNs are floating point.  NaTs don't exist in memory, only in registers 
> (and are Itanium specific).

Okay.  Let me try this a different way.  The RMS interface — and many 
of the other OpenVMS interfaces — has no mechanism for differentiating 
a data field that is invalid or uninitialized from a field that 
contains a valid value, and RMS further has no ready means to flag that 
mere accesses to these fields are invalid at run-time.   This is the 
software equivalent of NaN or NaT that can be implemented in various 
contexts, or of a database field that's marked as null.   This 
differentiation is analogous to what Itanium and other systems are 
using NaN, NaT or such to represent.  Something which really isn't.     
This as differentiated from a data field that's empty, zero or some 
other such explicitly-set value.

As a different and newer and software alternative, passing a message — 
an OO or method invocation — the (entirely hypothetical) OORMS 
framework can detect this access and this condition and can toss back a 
run-time error, rather than leaving the user to read the fine manuals, 
or to get silently bad data.   Which is where the RTFM approach leaves 
developers.   The OO approach also means needing rather less glue code, 
and also avoids revisiting data structure changes such as that from the 
NAM to the NAML.  Beyond reducing the piles of code chunder, the method 
call approach also avoids the need for an analog to NaN or NaT in the 
data structures.  But then the chances of seeing OORMS or OO system 
service calls and frameworks is zilch, and any wholesale replacement 
for RMS unlikely at best.

I don't expect to see either OpenVMS or RMS dragged this far forward 
anytime soon (if at all), however.  But this is what other operating 
systems are using now, so it's what many developers are already 
familiar with.




-- 
Pure Personal Opinion | HoffmanLabs LLC