[Info-vax] Unexpected DECnet Phase IV functionality with possible captive account implications

[Arne Vajhøj]

On 5/12/2021 12:23 PM, Stephen Hoffman wrote:
> On 2021-05-12 13:19:37 +0000, Arne Vajhj said:
>> On 5/11/2021 4:57 PM, Stephen Hoffman wrote:
>>> What you're doing with RMS and FAL is entirely feasible, though 
>>> through different means.
>>>
>>> MOUNT the remote system, and access it locally. With newer systems, 
>>> that'd usually be an SMB mount, though OpenVMS lacks modern storage 
>>> connections. On OpenVMS, it'd be NFS, or maybe DFS. Then aim SQLite 
>>> at it, etc.
>>>
>>> Or with newer applications, the access would be ODBC, or a message 
>>> queue, or—closest to what you're doing—with the database directly 
>>> e.g. MariaDB and the mysql -u RemoteUser -p -h 203.0.113.13 command, 
>>> etc.
>>
>> There are obviously many ways to access data on other servers.
>>
>> But neither the ability to mount a remote file system or access a 
>> remote database server is a 1:1 substitute for transparent file access 
>> to remote file system.
> 
> I've encountered folks using FAL to access files within an OpenVMS 
> Cluster, BTW. And sacrilegious as it might be, SMB shares aren't that 
> far off of SCS MSCP served storage within a Cluster, either. Though that 
> then descends into discussions of locking. Which then descends into 
> discussions of why some RMS apps can't be migrated into 
> network-remote-capable databases. Which descends into why new-to-OpenVMS 
> folks just aren't picking OpenVMS for new app work. I've undoubtedly 
> skipped a few intermediate steps in the usual discussion there, though.
> 
> And for the three or twelve folks still using this particular part of 
> DECnet and RMS and FAL for remote direct and unencrypted database 
> access, I'd suggest starting to work on refactoring and redesigning this 
> particular part of the implementation. In this case, API and 
> abstraction-related work toward removing this is also work toward 
> allowing a migration to a different and more capable database than the 
> features that RMS offers, too.
> 
> Encrypted SMB shares are endemic and inexpensive and effective, too. 
> OpenVMS Clusters, and DECnet, not so much.

Yes.

But "refactoring and redesigning" is work.

>> But in the real world starting with a blank piece of paper is pretty 
>> rare.
> 
> Of the various app ports off of OpenVMS that I've worked and of those 
> others I'm familiar with, I've met none blocked by a lack of FAL-like 
> storage access.

That quote from me was about file vs database not about FAL vs other
file access.

You may have encountered projects where file to database was
a real issue.

Arne