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

[Stephen Hoffman]

On 2016-06-19 02:57:05 +0000, David Froble said:

> Stephen Hoffman wrote:
>> 
>> 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.
> 
> Ok, dumb Dave is having a problem with this.  And yes, I had problems 
> with the concept of Null in Visual Basic.
> 
> A data field is a place where data is stored.  Even if it is zeros, or 
> whatever, it's still data.  An application can determine if it doesn't 
> like the value of the data.  I'm not sure anything else can do so.

The NaT/NaN/null stuff is metadata.  It is data that describes the 
data.  In this case, that there is no data.

Other metadata common on OpenVMS lurks in string descriptors, for 
instance — data that describes data.

Having that metadata separate or out-of-band or otherwise 
differentiated from the data means you can unambiguously tell when you 
have data and when you don't.

The design of the RMS data structures and APIs don't allow that to 
happen, which leads long-time users to point to RTFM as "the answer".

This is the "you should have known not to look in that data cell", 
rather than having the operating system flag the coding error.

Using a non-sensical constant is an older form of this, but that 
assumes the field can never be or can never become {zero, negative, 
whatever}, and it assumes that the user is paying attention to those 
values, and it's really effectively impossible to add new non-sensical 
constants if (when?) changes are required — you've largely pushed the 
error detection and error handing into the user code and into the 
documentation, after all — and there's no single non-sensical error 
constant that works across all APIs because the valid ranges inherently 
varies.

Newer systems don't tend to use OpenVMS-style descriptors, but various 
systems and frameworks do use objects for this.  Objects are an updated 
and opaque data structure that's very much a variant of an OpenVMS 
descriptor, and usually also "containing" the referenced data.  Why 
opaque?  Because once you've established a set of descriptors, you 
can't change those as the user code knows about the contents and format.

The BASIC compiler and run-time largely "hides" the use of descriptors, 
so that's somewhat more akin to an object reference than is typical 
when working with descriptors in C, C++, Macro32, Bliss or such; in 
languages where you often have to work more directly with the 
descriptor metadata.




-- 
Pure Personal Opinion | HoffmanLabs LLC