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

[Stephen Hoffman]

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.

Best case would be a compile-time error flagging the error, but that's 
likely not happening here.

But yes, within the usual way OpenVMS works (now), It'd certainly be 
useful to have an exact count of user data in the object as well as an 
exact size of the container, though.  But I'd still prefer to not (have 
to) deal with that differentiation; around how OpenVMS works here and 
how OpenVMS stores the file.  I'd prefer to just deal with the data and 
preferably with my data structures, and — best case — not have to 
(write the code to) marshal or unmarshal the data.

As for the discussion that started this off, it'd be handy of OpenVMS 
cleaned up that cache skew by itself.   Autonomously.   But that's not 
likely happening anytime soon, either.  (But this being OpenVMS, I'm 
sure there are folks that cannot or will not want these sorts of 
autonomous repairs, or OO interfaces, or code that marshals and 
unmarshals data.  For any of various reasons.)



-- 
Pure Personal Opinion | HoffmanLabs LLC