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

[John Reagan]

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).

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

The compiler has no way of knowing if the file you'll eventually open is sequential or not.

> 
> 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.
> 

Consider a ZIP file or some other file system that compresses the on-disk file for space reasons.  Asking "how many octets of data are in that file" is only somewhat related to how much physical disk space the file system requires to store and retrieve your data.  Lets think back to early Macintosh days with separate data forks and resource forks.