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

[Stephen Hoffman]

On 2020-11-09 18:17:31 +0000, Simon Clubley said:

> On 2020-11-09, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> 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.
> 
> Stephen, have you ever worked in commercial data processing ?

Yes.

I'm familiar with commercial data processing code, having written and 
maintained and refactored and enhanced that, and with the development 
and management and administration and politics of same.

Also familiar with the benefits and trade-offs that can arise with 
enhancement requests, too. And familiar with requests that are 
fundamentally escalations of local political and policy limits and 
workarounds, too.

> There are plenty of uses for such a facility, none of which involve 
> data integrity issues.

Some interlocks exist for a reason. Some don't. Some exist because 
developers didn't know better and/or didn't care and/or accepted poor 
defaults.

And have worked with entities that absolutely could not change and 
could not upgrade their configurations for reasons, and some of those 
for decades. Then management toggled the organizational write-lock bit 
off somewhere, and, wow, all those previously-impossible upgrades and 
source code fixes and the rest of the backlog all arrived.  Some 
enhancements are attempts to work around a developer- or management-led 
policy, and for these sorts of cases I'm more skeptical about 
enhancements. Those developers and management folks may well have 
reasons for those policies, and often do. Whether those reasons and 
related justifications are valid under broader review is another 
discussion, and one best held among local staff.

If the TYPE with FIB$M_NOLOCK is implemented, I would then foresee a 
few requests arriving for double-interlocks to prevent this override 
from working, because somebody had some reason to want to prevent 
access to data in progress. (I've used this to stage data, for 
instance.) But then FIB$M_NOLOCK does currently require system 
privilege or control access, so that's potentially more tractable than 
some of these cases.



Inevitable Digression 1: a slightly less inelegant hack might allow 
specific file open operation defaults to be overridden, akin to how 
default protections can be specified for file operations.

Inevitable Digression 2: some folks use TYPE to review indexed file 
data. I've met that usage in production more than once, too.



TL;DR: I'd prefer to re-code the app (slightly) to allow sharing, 
rather than adding FIB$M_NOLOCK to TYPE. From the vendor side of this, 
I'd prefer work toward the bigger issues latent and lurking within 
OpenVMS be addressed—job scheduling, operator communications, batch 
logging, system logging and filtering and automation, etc. This whole 
area of OpenVMS—displaying log files, scheduling and rescheduling and 
handling errors, etc—is not far enough past 1980 for my own production 
preferences.



-- 
Pure Personal Opinion | HoffmanLabs LLC