[Info-vax] VMS Software Q1 '23 Update

[Arne Vajhøj]

On 2/3/2023 1:49 PM, Dave Froble wrote:
> On 2/3/2023 1:34 PM, Arne Vajhøj wrote:
>> On 2/3/2023 12:54 PM, John Dallman wrote:
>>> In article <trj153$1epoa$1 at dont-email.me>, arne at vajhoej.dk (Arne Vajhøj)
>>> wrote:
>>>> Either "enterprise database on OpenVMS" means "PostgreSQL client on
>>>> OpenVMS accessing PostgreSQL server on Linux" or he believes
>>>> PostgreSQL server on VMS will show up.
>>>
>>> It is possible for organisations other than VSI to port software.
>>
>> That is in theory a possibility as well.
>>
>> I am very skeptical about that being the case here.
>>
>> I cannot see the PostgreSQL open source community
>> spend time on a VMS port.
>>
>> The VMS port depend on the SSIO thing that VSI will
>> need to provide.
> 
>  From the little I understand, I've got to say there are options.
> 
> PostgreSQL appears to depend upon some numeric range locking that is 
> implemented in something (I'm not knowledgeable about such) called 
> SSIO.  But locking can be provided in more than one manner.  I've been 
> involved in locking capabilities in the past.  It ain't rocket science.
> 
> Locking as required by the database could be implemented and the 
> database code modified to use the alternate locking provided.  Without 
> SSIO and/or the VMS DLM.
> 
> Nor does it need to be VSI that provides the locking capabilities.
> 
> That mentioned, the cluster stuff in the VMS DLM would be rather 
> difficult to replace, and I'd bet any alternatives would not provide 
> what the DLM does for a cluster environment.

My understanding of the problem based on the PPT linked to
in previous discussions then the core of the problem
is that the API between process code and kernel code
need to be byte centric not block centric.

Both SYS$QIO(W) and SYS$IO_PERFORM(W) specify
block number not byte number.

Which can cause concurrency problems for IO's with
no overlapping byte range but overlapping blocks.

Arne