[Info-vax] RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was

[VAXman- at SendSpamHere.ORG]

In article <nke08c$abk$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2016-06-21, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2016-06-21 14:16:50 +0000, lawrencedo99 at gmail.com said:
>>
>>> Of these, none is worth keeping. Except maybe that last one.
>>
>> Your list missed one: if RMS is ripped out, then large chunks of 
>> OpenVMS itself and more than a little third-party and end-user code 
>> either gets rewritten. or an RMS analog layer gets written.  That 
>> latter approach and that latter effort goes nowhere near forward 
>> progress, either.  There are a lot of RMS system service calls around 
>> in VSI and third-party and end-user source code, and a lot of source 
>> code with in-built RMS-based assumptions.
>>
>
>But OTOH, if you wanted to build something which looked like VMS but
>without maintaining strict VMS compatibility, RMS as it currently
>stands is something which would be ripped out with a vengeance.
>
>You would need something RMS like in a new VMS, but it needs to be a
>procedural subroutine style API interface, not a control block interface.
>There's way too much direct exposure of low level details to VMS user
>applications; that kind of thing needs hiding behind an abstraction
>layer which does some of the boilerplate stuff for you.

Which is what many of the HL langages do in their file handling statements.
An OPEN statement with filename is fairly abstracted from the control block
interface of RMS.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.