[Info-vax] ODS5 on Linux

[John Wallace]

On May 16, 6:55 am, David Froble <da... at tsoft-inc.com> wrote:
> johnson.e... at gmail.com wrote:
> > On Monday, May 14, 2012 7:55:59 PM UTC-4, Single Stage to Orbit wrote:
>
> >>> I suspect that what people would really want (at least those drawn to
> >>> this driver) would be a way to get real time access to all files
> >>> through all native APIs.  But I think the only effective way to do that
> >>> is to broker the access through a VMS node such that the off box access
> >>> points look and feel like equal players in the clustered relationship
> >>> with the file system.
> >> It would be nice to have that sort of thing, agreed.
>
> > If there's interest, I can outline a set of ideas that can achieve real time access brokered through a VMS node.  At the moment, it's not much more than an idea so there would be some non-trivial code to write.  It's a solution that would require some serious programming skill, but the hardest (and most fun problems!) always do.
>
> > The solution may not appeal to everyone or fit everyone's needs.  So I don't want to mislead anyone into thinking it's a silver bullet.  I think that legacy systems whose run time is mostly cpu bound, rather than IO bound, are the main benefactors.  But as with any system, the devil lies in the details!
>
> > EJ
>
> If I understand what's being discussed, it's similar to the DECnet FAL (file access
> listener).  Basically the host system serving file access to clients.  But using sockets
> (TCP/IP) as the network transport.
>
> The details of what's expected would be a first step.  It could be as simple as single
> transactions per access, or multiple links that stay up until closed or timeout.
>
> I may be doing something similar in the near future.  We're getting requests for a windows
> user interface for some customer service functions.  The customer hires seasonal workers
> for the busy season and wants to have minimal training requirements.  As to why they think
> one user interface would need different training than another, for basically the same
> functionally, I don't have a clue.  But they are the customer, and they are paying

Is it me or is there some level of ambiguity in this discussion?

It started in respect of some kind of service that would allow a Linux
implementation of ODS2 or ODS5 to read the contents of such a VMS-
originated drive, as files (preferably integrated within a Linux file
system). But it would be difficult (at best) to incorporate that into
a live VMS environment. Locking etc would be interesting at best, non-
existent  integration with the drive offline from its VMS origins
would be far far easier.

A service that served files as files with all the expected
implications (files are live on a live VMS system, locking works, etc)
is a different option but in some circumstances may address the same
requirement. The traditional DECnet way of doing it would be FAL, but
DECnet for Linux seems to have become mature? Other already existing
options at one time including DECdfs, and presumably current options
would still include SAMBA or similar.

Is something like SAMBA relevant to some of the requirements here, if
not why not?