[Info-vax] CRTL and RMS vs SSIO

[Dave Froble]

On 10/7/2021 1:01 PM, Stephen Hoffman wrote:
> On 2021-10-07 16:18:28 +0000, Dave Froble said:
>
>> A while back we were discussing doing away with I/O to buffers, and
>> accessing the data in place.  Slower access perhaps, but doing away
>> with the reading and writing to/from buffers.  Haven't heard much
>> about that lately.  I don't get out much.
>
> Ayup. Nonvolatile byte-addressable storage hardware is available now,
> and is in use in various applications.
>
> Compatible memory hardware will be rather more available for OpenVMS
> x86-64, for folks interested in investigating this for their apps.
>
> Carving out a hunk of persistent storage will be interesting topic for
> app developers on OpenVMS, though I can think of a couple of ways to try.
>
> Here's an HPE overview from a few years ago on the topic:
> https://www.pdl.cmu.edu/SDI/2016/slides/keeton-2016-10-19-memory-driven-computing.pdf
>
>
> I see some B-Tree work for this area in a newer paper, and a number of
> other discussions.
>
>> Such type of activity would really benefit from having the capability
>> of locking just the required data, and, would need the capability of
>> reading and writing just the required data.
>
> Locking access to the contents of a global section, or locking access to
> hardware-backed storage for external devices, is the same issue.
>
> Whether DLM overhead is too high for that to be workable is another
> discussion that the app developers will want to ponder.
>
>> I'm aware of how useful something like SSIO would be.  I'm just
>> appalled by the design and implementation.  As mentioned, it seems
>> aimed at just a few current uses, and totally ignores how useful it
>> would be for many more future uses.  This is rather consistent with
>> the long time apathy with which VMS has been treated.  It's more a
>> patch than an enhancement.   This is what I lament.
>
> Alas, there's no other outcome when upward-compatibility is an
> overarching goal for the platform.

Now I''m just a dumb polock, wandered down out of the woods.  But I just 
don't see where upward compatibility has anything to do with 
enhancements to the DLM.  If existing calls continue to work as before, 
and only when an optional extra parameter would enable new capabilities, 
then upward compatibility just cannot be an issue.  At least for this.

The optional parameter might be a "lock type", and if not present, 
existing logic would be used, and if present, new code could be executed 
to process the new lock type.  Stuff a couple of quadwords into the 
resource name for the numeric range.  It would add one new piece of data 
to the DLM data structure(s).

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486