[Info-vax] CRTL and RMS vs SSIO

Craig A. Berry craigberry at nospam.mac.com
Thu Oct 7 12:12:00 EDT 2021


On 10/7/21 9:01 AM, Arne Vajhøj wrote:
> On 10/7/2021 9:51 AM, Craig A. Berry wrote:
>> On 10/7/21 8:40 AM, Arne Vajhøj wrote:
>>> On 10/7/2021 8:50 AM, Craig A. Berry wrote:
>>>> On 10/6/21 11:10 PM, Dave Froble wrote:
>>>>> the real issue is that SSIO was aimed (it seems) at PostgreSQL.
>>>>
>>>> And Apache, and Samba, and other things that have been explicitly
>>>> mentioned as having needed app-specific workarounds due to the absence
>>>> of shared stream I/O support. SSIO *is* the general-purpose solution
>>>> that you seem to be lamenting the lack of.
>>>
>>> Samba I totally get.
>>>
>>> Multiple PC's writing to a file on a Samba share would create
>>> some interesting scenarios.
>>>
>>> But why does Apache need it?
>>>
>>> It should read files to serve - and since it is serving VMS files
>>> then I think it be as VMSish as possible so totally standard RMS.
>>> And it should write sequential text files like access.log.
>>>
>>> What am I missing?
>>
>> log files (and probably the fact that multiple worker processes can be
>> writing to the same logs).
> 
> I still don't get it.
> 
> I thought SSIO was about shared access to byte streams.
> 
> Writing to log files should be fine using good old record based
> writes (somewhere down the call stack SYS$PUT).

Don't ask me, ask the authors of the document to which I linked. Or the
folks at VSI who inherited their work.  I may be wrong and it's not
about log files, but suppose it is.  If you start from the premise that
the log files are stream-oriented and you have multiple writers and
multiple readers at the same time, then that's pretty much the
definition of shared access to a byte stream. Doing it differently for a
platform that prefers records would be extra cost and extra maintenance.

>>                            And I forgot to mention that Java needs it
>> too.  See:
>>
>> <http://de.openvms.org/TUD2012/opensource_and_unix_portability.pdf>
>>
>> Page 16 says:
>>
>> • Java (CIFS too) uses a work-around
>>    − Does open+read/write+close for every read/write!
>>    − Restores current file offset after each close+open
>>    − Significant performance issue
> 
> In this context does "Java" mean "Tomcat"?

You know as much as I do -- probably more ;-).



More information about the Info-vax mailing list