[Info-vax] VMS enhancement suggestion: Add a "read regardless" file open option.

[Stephen Hoffman]

On 2020-11-09 13:30:23 +0000, Simon Clubley said:

> What would be involved in adding a "read regardless" file open option 
> to VMS which would allow the opening of files for read only even if 
> they are already open for write, and then adding a qualifier to $ TYPE 
> to use this new option ?
> 
> How useful would others here find this capability ?

Not all that useful, as I'm not usually looking to access what can be 
inconsistent data.

For override access, use CONVERT /SHARE when access to a sharing-locked 
log file is required. Or BACKUP /ALLOW=DATA_INCONSISTENCIES, err, 
BACKUP /IGNORE=INTERLOCK, otherwise. Or one of the previously-discussed 
tools.

For me, adding an OPEN /SHARE=OVERRIDE, and/or TYPE /SHARE, and/or TYPE 
/SHARE /TAIL option or otherwise exposing FIB$M_NOLOCK isn't all that 
interesting, as I just don't have to deal with reading locked files.

Not for very long, if at all.

With batch, use SET OUTPUT to increase the write frequency, and/or 
redirect the interesting stuff to a log elsewhere. Elsewhere with 
sharing enabled. Logging app data into batch is... it works.

That batch processing default-caches 30 seconds of data per write is an 
interesting optimization from a previous era of I/O performance. This 
given batch output is a negligible fraction of typical SSD and NVMe 
bandwidth.  But I digress.

Or write your own app logs, as you can set the sharing access to those 
as required. Or variously better for storing logging data rather than 
mixing together logging data and app data as is typical with how some 
folks use batch logs, writing the log data to a database, or to a 
syslog server, or... and write the app data to your own files or 
databases or servers.

Put differently, I usually fix whatever I'm needing access into, if 
it's blocking that access. And yes, it's also possible to intercept and 
shim the non-shareable open API call into a shareable open I/O call. 
I've not had to resort to that in many years, though. I typically have 
the app source. I've fixed countless numbers of apps over the years 
that have had unnecessary file locks specified at open. Apps written in 
C are notorious for this too, due to the non-sharing defaults on fopen 
et al.

This whole area reeks of old designs, and an inability to look under 
the proximate rocks, with an inability to actually fix the problematic 
app code (for reasons), leading to ever-more-complex work-arounds in 
OpenVMS itself.

*Ponders whether somebody will then eventually request a 
DOUBLE-SECRET-NON-SHAREABLE-FILE option that can then prevent 
overriding and accessing a non-shareable file. That might seem 
humorous. But there have been similar requests made elsewhere. Object 
access controls that can selectively override privileges is one case 
that's been discussed around here.*

I'm not sure what sort of change might be appropriate here. TYPE /SHARE 
is probably the smallest and thus most manageable and most likely, but 
it seems there are rather larger re-designs available here. OpenVMS 
batch and job scheduling and the class scheduler and logging and 
operator communications—all features related to keeping production 
running and for recovering from production failures—are somewhere 
between problematic and absent, and these particular older designs are 
probably less reflective of where many of us find ourselves now working.

-- 
Pure Personal Opinion | HoffmanLabs LLC