ODS5 on Linux

[Single Stage to Orbit]

Recently I found this page: http://www.vms2linux.de/ods5fs.html which
provides the ability for Linux to read those ODS[2,5] disks.

Unfortunately I could not find the source code - does anyone knows where
I can locate and download the sources?

Thanks,
Alex
--
Tactical Nuclear Kittens

[Paul Sture]

On Wed, 09 May 2012 01:37:41 +0100, Single Stage to Orbit wrote:

> Recently I found this page: http://www.vms2linux.de/ods5fs.html which
> provides the ability for Linux to read those ODS[2,5] disks.
>
> Unfortunately I could not find the source code - does anyone knows where
> I can locate and download the sources?
>

Try sending the author an email? According to the above page that's:

ods5 at vms2linux.de



--
Paul Sture

[Single Stage to Orbit]

On Wed, 2012-05-09 at 19:57 +0200, Paul Sture wrote:
> > Unfortunately I could not find the source code - does anyone knows where
> > I can locate and download the sources?

> Try sending the author an email? According to the above page that's:
>

> [ email address snipped ]

Thanks for that, will drop them an email.

Regards

[johnso...@gmail.com]

On Tuesday, May 8, 2012 8:37:41 PM UTC-4, Single Stage to Orbit wrote:

> Unfortunately I could not find the source code - does anyone knows where
> I can locate and download the sources?

Hopefully you'll get access to it and you can give it a whirl to see if it meets your needs.

One of the things that I had noticed when I saw others play with this is that it falls short of what you might really want. For example, because it doesn't coordinate with the VMS lock manager, there's no safe way for it to share even read access. This limits the solution to only offline access where the volume is fully dismounted from any VMS node.

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.

-EJ

[Single Stage to Orbit]

On Sun, 2012-05-13 at 16:38 -0700, johnso...@gmail.com wrote:
> On Tuesday, May 8, 2012 8:37:41 PM UTC-4, Single Stage to Orbit wrote:
>
> > Unfortunately I could not find the source code - does anyone knows where
> > I can locate and download the sources?
>
> Hopefully you'll get access to it and you can give it a whirl to see if
> it meets your needs.

Sadly, the source code is not available but the author is more than
happy to build the kernel module and associated files on request.

> One of the things that I had noticed when I saw others play with this
> is that it falls short of what you might really want. For example,
> because it doesn't coordinate with the VMS lock manager, there's no
> safe way for it to share even read access. This limits the solution to
> only offline access where the volume is fully dismounted from any VMS
> node.

Eh? ODS5 can't write to the VMS disk image anyway.

> 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.
--
Tactical Nuclear Kittens

[Arne Vajhøj]

On 5/14/2012 7:55 PM, Single Stage to Orbit wrote:
> On Sun, 2012-05-13 at 16:38 -0700, johnso...@gmail.com wrote:
>> On Tuesday, May 8, 2012 8:37:41 PM UTC-4, Single Stage to Orbit wrote:
>>
>>> Unfortunately I could not find the source code - does anyone knows where
>>> I can locate and download the sources?
>>
>> Hopefully you'll get access to it and you can give it a whirl to see if
>> it meets your needs.
>
> Sadly, the source code is not available but the author is more than
> happy to build the kernel module and associated files on request.

Has he put in a shim between his stuff and the kernel?

If not he is violation of the GPL license!

Arne

[Single Stage to Orbit]

On Mon, 2012-05-14 at 20:10 -0400, Arne Vajhøj wrote:
> > Sadly, the source code is not available but the author is more than
> > happy to build the kernel module and associated files on request.
>
> Has he put in a shim between his stuff and the kernel?
>
> If not he is violation of the GPL license!

Actually, no he isn't. As he wrote the code, he's perfectly entitled to
put restrictions on his work.
--
Tactical Nuclear Kittens

[Arne Vajhøj]

No - he is not, because he is using somebody else's code
and has to comply with their license.

A driver without a shim is linked with the kernel.

The kernel is under GPL.

Any code linked with GPL code has to be under GPL itself.

When the code is under GPL then anyone that get a binary has
the right to the source.

Arne

PS: Besides the shim trick a few has gotten exception permissions
when the driver code was not written for Linux but ported to
Linux.

[Single Stage to Orbit]

On Mon, 2012-05-14 at 22:56 -0400, Arne Vajhøj wrote:
> >> If not he is violation of the GPL license!
> >
> > Actually, no he isn't. As he wrote the code, he's perfectly entitled
> to
> > put restrictions on his work.
>
> No - he is not, because he is using somebody else's code
> and has to comply with their license.
>
> A driver without a shim is linked with the kernel.

A module isn't necessarily linked into the kernel. It's loaded into
memory and gets used for whatever purposes the user requires it for.

> The kernel is under GPL.

Correct.

> Any code linked with GPL code has to be under GPL itself.

Not really.

> When the code is under GPL then anyone that get a binary has
> the right to the source.

If it was linked into the kernel itself then yes the GPL covers it.
--
Tactical Nuclear Kittens

[Paul Sture]

On Tue, 15 May 2012 04:04:27 +0100, Single Stage to Orbit wrote:

> n Mon, 2012-05-14 at 22:56 -0400, Arne Vajhøj wrote:
>> >> If not he is violation of the GPL license!
>> >
>> > Actually, no he isn't. As he wrote the code, he's perfectly entitled
>> to
>> > put restrictions on his work.
>>
>> No - he is not, because he is using somebody else's code and has to
>> comply with their license.
>>
>> A driver without a shim is linked with the kernel.
>
> A module isn't necessarily linked into the kernel. It's loaded into
> memory and gets used for whatever purposes the user requires it for.

http://www.vms2linux.de/ods5fs-overview.html

---
The ods5 file system comes as a kernel module and is usually loaded with

# insmod path-to/ods5.ko
---

What is insmod?

http://linux.about.com/od/commands/l/blcmdl8_insmod.htm

DESCRIPTION

insmod installs a loadable module in the running kernel.

--
Paul Sture

[Arne Vajhøj]

On 5/14/2012 11:04 PM, Single Stage to Orbit wrote:
> On Mon, 2012-05-14 at 22:56 -0400, Arne Vajhøj wrote:
>>>> If not he is violation of the GPL license!
>>>
>>> Actually, no he isn't. As he wrote the code, he's perfectly entitled
>> to
>>> put restrictions on his work.
>>
>> No - he is not, because he is using somebody else's code
>> and has to comply with their license.
>>
>> A driver without a shim is linked with the kernel.
>
> A module isn't necessarily linked into the kernel. It's loaded into
> memory and gets used for whatever purposes the user requires it for.

Linus Torvalds has actually answered the question:

<quote>
And I claim that binary-only kernel modules ARE derivative "by default",
by virtue of having no meaning without the kernel.
</quote>

So you are wrong - kernel modules are as starting point derivative of
(which is the legal term for linked with) the kernel.

So they need to be under GPL.

>> The kernel is under GPL.
>
> Correct.
>
>> Any code linked with GPL code has to be under GPL itself.
>
> Not really.

Yes.

That is the main characteristic by strong copyleft like GPL.

>> When the code is under GPL then anyone that get a binary has
>> the right to the source.
>
> If it was linked into the kernel itself then yes the GPL covers it.

It does.

See above.

Arne

PS: One of the last companies that thought they could avoid GPL
for a driver was actually MS. After being notified about the
problem and probably consulting their lawyers they released
their Hyper-V drivers under GPL.

[johnso...@gmail.com]

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

[David Froble]

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.

[John Wallace]

On May 16, 6:55 am, David Froble <da...@tsoft-inc.com> 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.

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?

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

[johnso...@gmail.com]

On Wednesday, May 16, 2012 2:17:21 PM UTC-4, David Froble wrote:

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

By deficiencies, are you referring to the slow performance? I've always found the TCP/IP stacks on VMS to be incredibly sluggish. It's not just a bandwidth problem, it's very slow (relatively speaking) at reading and sending very small packets. The situation on a platform like Linux is quite different. It's very tragic.

EJ

[Paul Sture]

That sounds like Attunity's offerings, which are pretty comprehensive.

http://www.attunity.com/products/attunity-cdc/rms-change-data-capture

I see the OP's requirement as more akin to the ODS-2 Freeware package
which was useful for reading things like VMS documentation CDs on non-VMS
systems.

--
Paul Sture

[Bob Koehler]

In article <31253581.2713.1337216810906.JavaMail.geo-discussion-forums@yncd3>, johnso...@gmail.com writes:
>
> By deficiencies, are you referring to the slow performance?

Which stacks have you tried. As many people know, I'm not
particular fan of UCX (under any name). I have seen it used in
anger.

[Single Stage to Orbit]

Is it possible to obtain Multinet on the Hobbyist licence?
--
Tactical Nuclear Kittens

[Paul Sture]

Yes.

http://www.process.com/openvms/hobbyist.html



--
Paul Sture

[Single Stage to Orbit]

On Thu, 2012-05-17 at 17:58 +0200, Paul Sture wrote:

> >> Which stacks have you tried. As many people know, I'm not
> >> particular fan of UCX (under any name). I have seen it used in
> >> anger.
> >
> > Is it possible to obtain Multinet on the Hobbyist licence?
>
> Yes.
>
> http://www.process.com/openvms/hobbyist.html

Thanks, much appreciated.
--
Tactical Nuclear Kittens

[John Wallace]

A good place to start looking when things seem "very slow (relatively
speaking) at reading and sending very small packets", regardless of
the OS in question, is the Nagle algorithm, and its relative in code,
setsockopt(... TCP_NODELAY...). Supported on VMS and elsewhere. See
also TCP_NODELACK. This isn't the place for a lesson in the tradeoffs
between bandwidth and latency and efficiency, but these things are
reasonably well documented although not always as well known as they
should be. Anyway until those things have been set appropriately, it's
not really appropriate to criticise any given implementation.

[JF Mezei]

someone wrote:
>> By deficiencies, are you referring to the slow performance? I've always found the TCP/IP stacks on VMS to be incredibly sluggish. It's not just a bandwidth problem, it's very slow (relatively speaking) at reading and sending very small packets. The situation on a platform like Linux is quite different. It's very tragic.

At one point, I thought I was having IP performance problems on the link
and was using FTP as a means to check upload and download speeds (since
VMS doesn't have a working flash which is used for most speed tests).

ftp tests showed poor performance.

I did the same tests on my xserve (OS-X) and low and behold, the
performance difference was very drastic and make full use of the line
speed (showing the line had no problems).

I had already set a large TCPIP$FTP_WINDOW_SIZE (if I recall correctly)
and it didn't seem to make a difference.

There may be some paarmeters that can be set in TCPIP$ETC file
(systemconfig or something akin to this), but out of the box, the
performance was significantly lower than on OS-X (which came from freeBSD)

It is also possible that the FTP application was not properly ported and
fails to use any performance enhnacements possible on VMS.

The end result is that the peformance was sigificantly slower on VMS
than on OS-X.

[John Wallace]

Back in the days before dslreports had their crash, they had some
interesting writeups on the behaviour of TCP slow start across
differering implementations. Maybe they still do e.g. there's a brief
mention at http://www.dslreports.com/speed.

Anyway, unless a bulk data speed test runs for many seconds AND the
link is sufficiently error free that there is no packet loss AT ALL
at low level, it is entirely possible that the results of an arbitrary
speed test can be dominated by the behaviour of TCP slow start rather
than by the actual usable bandwidth between sender and receiver. Not
saying it always will be, just that it can happen.

DSLreports tweak test tells you a lot about your IP settings but
didn't comment on "slow start" incompatibilities as such last time I
looked (a long time ago).

I like the maxspeed test at www.numion.com; you can get a graph from
it which potentially illustrates "slow start" and packet loss effects.

[David Froble]

Ooops! Possibly a bad question. If I don't contain myself, there might result a rant of
epic proportions on c.o.v ....

The HP TCP/IP stack is basically a port of a Unix (T64) product. As such it seems to want
to do things in a Unixy manner. One of those Unixy things is the concept of a Inet damon
(demon) that wants to intercept all connection requests and create a process to accept the
connection. On VMS this piece of shit is called the auexlery processor (see, I hate the
concept so much I cannot spell it).

I've had applications running for years now, that streamed the connections one at a time.
But now we're looking at increased traffic, and I feel that streaming connections in
such a manner will in time give us a serious bottleneck.

As for your question, performance is not an issue. We're servicing connection requests
in fractions of a second. But that really depends upon what the application needs to do
to service the request. For an inventory stock inquiry, we can reply to a list of a
hundred parts in a fraction of a second. Some other types of requests take a few seconds,
but as I wrote, that's the application, not TCP/IP.

What really burns me is, when a listener gets a connection request, and you grant the
connection, it does it on THE SAME SOCKET THAT WAS LISTENING !!! No chance to work with
the client while going back to listening for another connection request.

I've seen much better, and brace yourself Brian, it was a Weendoze 3rd party product.

If I mentioned the problems with getting this to work with the HP port of OpenSSL, the
rant would grow far beyond epic.

Anyway, I guess that much of this is basically that if I was implementing socket
communications, the design would be different.

As for Process, I mentioned my problem to Hunter, and he never got back to me, so I'm
wondering if their TCP/IP stacks have the same problem.

[johnso...@gmail.com]

On Thursday, May 17, 2012 4:15:46 PM UTC-4, JF Mezei wrote:

> The end result is that the peformance was sigificantly slower on VMS
> than on OS-X.

I've also noticed the lousy performance of FTP and TCP and the stacks in general on VMS especially when compared to other OSes. In my case, I was comparing to Linux.

Yes, I know about TCP_NODELAY and the other ACK related issues.

When I was researching the topic, I decided to switch to UDP because it has a simpler model with fewer knobs to twist or choices the stack can make.

To look at the performance, I wrote a simple program which would issue a small UDP packet. It did this in a tight loop. The basic question I was trying to answer was - "How much time does it take to go from user-mode, into the stack, to send a packet, and come all the way back up". I recall sending something like a 64 byte UDP packet.

On a 1 Gbps card, that's a measly 84 bytes (64 + 20 from IP's header). If my math is correct, transmission time for that should be under a microsecond.

I no longer have access to a VMS box, but as I recall, it took VMS several orders of magnitude more time to send a single UDP packet than it did on something like Linux. My memory is fuzzy, but I recall the Linux box being able to blast out nearly a million UDP packets in a second, but the VMS box struggled to hit 20,000 in a second.

The situation became more curious if you pointed that UDP packet blaster at a VMS node! Some of the stacks on VMS are configured to send an ICMP message back to the sender IF there was no receiver for that UDP packet on that host. This of course travels back to the senders box and further interrupts the stack and causes the sender program to take even more time to send a single packet.

The impact of the ICMP message coming back into the stack likely resembles the impact of an ACK in the case of TCP.

Lastly, if you run that UDP blaster program from a Linux box and point that at a VMS box, you can watch the VMS node became quite busy trying to service those UDP packets. While saturating any stack on any operating with a 100k+ packets a second is a mean thing to do, the pain on VMS seems quite high by comparison.

Again, going by memory, if you run something like sys$examples:spl.com while this is happening, you will see locks, such as IOLOCK8 and whatever locks your stack uses, operating under heavy contention. I recall Multinet's stack experiencing more pain than the HP/UCX flavor. But both compared quite poorly to Linux.

If there's interest, I can write a fresh version of the UDP blaster program so you can try it out for yourselves. Might be interesting to compare results. Unfortunately, I no longer have access to a VMS box so I can only produce linux based results.

EJ

[Paul Sture]

On Thu, 17 May 2012 16:15:46 -0400, JF Mezei wrote:

> At one point, I thought I was having IP performance problems on the link
> and was using FTP as a means to check upload and download speeds (since
> VMS doesn't have a working flash which is used for most speed tests).
>
> ftp tests showed poor performance.
>
> I did the same tests on my xserve (OS-X) and low and behold, the
> performance difference was very drastic and make full use of the line
> speed (showing the line had no problems).

ISTR coming across a similar performance difference with FTP between VMS
and OS X.

It might not be just FTP of course. I have definitely achieved better
performance on large files by tweaking the RMS_EXTEND_SIZE dynamic SYSGEN
parameter or using SET RMS_DEFAULT/EXTEND_SIZE.


--
Paul Sture

[Bob Koehler]

In article <1337265364.3...@lithium.local.net>, Single Stage to Orbit <alex....@munted.eu> writes:
>
> Is it possible to obtain Multinet on the Hobbyist licence?=20

Process provides a hobbyist license for both Multinet and TCPware.
I use Multinet on my home cluster.

[Bob Koehler]

In article <4fb55c73$0$17647$c3e8da3$a8a6...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>
> At one point, I thought I was having IP performance problems on the link
> and was using FTP as a means to check upload and download speeds (since
> VMS doesn't have a working flash which is used for most speed tests).

Which stack?

On UCX we found performance very dependent on buffer settings that
only a privileged user could modify.

Fourtunately, we owned the SYSTEM account.