Message from discussion ODS5 on Linux
Received: by 10.68.238.67 with SMTP id vi3mr5014291pbc.6.1337153080964;
Wed, 16 May 2012 00:24:40 -0700 (PDT)
From: John Wallace <johnwalla...@yahoo.co.uk>
Subject: Re: ODS5 on Linux
Date: Wed, 16 May 2012 00:24:40 -0700 (PDT)
References: <firstname.lastname@example.org> <13791672.2682.1336952284462.JavaMail.geo-discussion-forums@ynbv35>
X-Trace: posting.google.com 1337153080 21980 127.0.0.1 (16 May 2012 07:24:40 GMT)
NNTP-Posting-Date: Wed, 16 May 2012 07:24:40 +0000 (UTC)
Injection-Info: d17g2000vbv.googlegroups.com; posting-host=220.127.116.11; posting-account=LoTgDQkAAADTKXJ587vuIocn0MiURp6p
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:18.104.22.168)
Content-Type: text/plain; charset=ISO-8859-1
On May 16, 6:55=A0am, David Froble <da...@tsoft-inc.com> wrote:
> johnson.e...@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. =A0But I think the only effective way to do =
> >>> is to broker the access through a VMS node such that the off box acce=
> >>> 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. =A0At the moment, it's not much m=
ore than an idea so there would be some non-trivial code to write. =A0It's =
a solution that would require some serious programming skill, but the harde=
st (and most fun problems!) always do.
> > The solution may not appeal to everyone or fit everyone's needs. =A0So =
I don't want to mislead anyone into thinking it's a silver bullet. =A0I thi=
nk that legacy systems whose run time is mostly cpu bound, rather than IO b=
ound, are the main benefactors. =A0But as with any system, the devil lies i=
n the details!
> > EJ
> If I understand what's being discussed, it's similar to the DECnet FAL (f=
> listener). =A0Basically the host system serving file access to clients. =
=A0But using sockets
> (TCP/IP) as the network transport.
> The details of what's expected would be a first step. =A0It could be as s=
imple as single
> transactions per access, or multiple links that stay up until closed or t=
> I may be doing something similar in the near future. =A0We're getting req=
uests for a windows
> user interface for some customer service functions. =A0The customer hires=
> for the busy season and wants to have minimal training requirements. =A0A=
s to why they think
> one user interface would need different training than another, for basica=
lly the same
> functionally, I don't have a clue. =A0But they are the customer, and they=
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?