[Info-vax] ODS5 on Linux

[David Froble]

John Wallace wrote:

> 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.

I think you are correct, as to the original question.

I'm thinking that if there is an ODS-5 disk, then there is a VMS system.  Leaving out the 
locking issue, it's my opinion that nothing else is going to access an ODS-5 disk as well 
as VMS, thus the curve in the discussion.  Having VMS serve the disk, or files, seems to 
be a reasonable thing to do.

> 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?

For my future needs, I don't think any of what you mentioned would work.  It's not that 
I'm going to need to just access files, I'm going to need to access data, which is in a 
3rd party database.  It's not just a case of file access, it's a case of accessing the 
data in a specific manner.  Again, my opinion is, let VMS (and the database) do what it's 
already set up to do, and just serve (and update) the data.

Aside with putting up with the deficiencies in HP TCP/IP, I'm getting slightly decent with 
socket communications.