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

[David Froble]

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

Dave whines "if you're dealing with data, why would you care about the metadata?"

In general, you don't care.  I have to admit that there have been times when 
I've played with the descriptors / metadata, which means maybe I'm dealing off 
the bottom of the deck.

:-)

Yeah, doing so in Macro32 is easier than in Basic.