Coordinating the Vms porting efforts

[labadie_1]

Hello

I see regularly various freeware ported to Vms a second time by another person.
I think this is a pity, as there is a real need to have some software ported urgently.
Some years ago, Mysql was the important piece missing on Vms.
It is now available.

In your opinion, what is the most urgent freeware to port ?
I think some SAP-light may be useful (Baan, Bpcs...), when I see more and more companies leaving Vms because they go for SAP or any other ERP.
While there are many interesting languages to port, having a good language is not enough: you need to be able to read a Vms indexed file, to access an Oracle or Rdb database, use all the Vms system services...
We need more than printing Hello World :-)
So Haskell, Erlang, Ocaml, LUA, Lisaac may wait a little.

Several Wiki and CMS (content management system) are available, so this is not at the top at the list IMHO.

What do you put at the top of the list ?

[David Jones_21]

When I re-port things, it is usually because the existing port is several versions out date and/or sub-optimal choices were made in how to accommodate OS incompatibilities in the freeware version.

[labadie_1]

I was more thinking at some recents ports, like bzip2 ported, when it was already available.

I think there are few people porting free software to Vms, so such thing should be avoided.

[Hoff]

I was party to a recent email discussion on a nearby topic; a discussion basically related to coordinating and maintaining an open source depot and open source ports.

No future Freeware distro is known to me.

Contact me off-line and I'll send along the information on who was thinking about this project. I'd rather not post the names here.

I know of only a few folks actively porting open source wares over to OpenVMS.

There are certainly larger porting efforts available for consideration, whether you look at a business practices environment (SAP, et al) or at PostgreSQL or the Ingres community release databases.

That written, it is often easier to use the existing tool ports -- or existing and supported packages -- on the particular platforms that have ports or packages. Or for folks with specific requirements and/or particularly for larger-scale packages, to simply pay for a port.

What package(s) are appropriate or are needed can and does vary widely, and whether or not incorporating support for native OpenVMS features and APIs such as indexed files is considered appropriate also varies. Widely.

And empirical evidence shows duplication of effort is an inherent feature of open source and open source porting -- the definition of "best" is always highly localized.

Contact me offline and I'll get you in touch with the folks that were here ruminating most recently.

Stephen Hoffman
HoffmanLabs.com

[Steven Schweda]

> I was more thinking at some recents ports,
> like bzip2 ported, when it was already
> available.

> the definition of "best" is always highly
> localized.

Exactly. I like my bzip2 better, naturally.
On the bright side, the more people who do a
job, the better the chance that one of them
will get it right.

[Jansen_8]

To Take bzip2 as example:
Probably I was the first to port the stuff. But when I got aware of Steven's port, I recognized his work was better and changed the links on my web-page.
Recently I cam across Alexey Chupahin's port He added some good idea's but was nor aware of Steven's port. So I urged him to look at it and merge the two versions to get a better one. (I'm not sure what the status is).

IMHO : the more people work on VMS-porting the better. But avoid inventing the wheel many times. So merge good ports into one version.

[Jansen_8]

Oh, and I forgot to mention that I'm normally in favor of including the VMS-port into the "original" distribution. This has the advantage that if the package evolves some of the VMS stuff is automatically updated and there is only one version.

However, in the case of bzip2 the author of bzip2 was not very cooperative (some 10 years ago).

[Steven Schweda]

> However, in the case of bzip2 the author of
> bzip2 was not very cooperative (some 10
> years ago).

That was my experience in 2006-2006, too, but
he did fix a problem I reported in the UNIX
installation procedure.

The new wget maintainer has expressed at
least a weak interest in adding some
VMS-related changes. I've been trying for
years to figure out which release is that
"next" release, where all the good stuff will
happen.

[Craig A Berry]

In my view the best way to keep a package up to snuff on VMS is to get involved in the community or project that maintains it. Learn to speak their language and learn their submission policies and procedures, their coding standards, their tools, and their workflow. If it's a single-author packge (like bzip2) and that author is not open to it, there's not much you can do, but in my experience that's rare.

Some of the typical dos and don'ts when participating in open source projects would be:

Don't view porting as a one-way, one-time effort: get your changes into the authoritative repository and use whatever tact, diplomacy, and technical prowess you have at your disposal to make that happen and keep them up-to-date.

Do submit changes against the latest development snapshot, not the last stable release.

Don't make changes that will work only on VMS unless it's really necessary (such as providing VMS-only functionality).

Do make your VMS-specific changes in a way that minimizes the cost of maintaining a separate port. For example, take advantage of existing build infrastructure if possible.

Don't make the mainline code a jungle of "#ifdef __VMS" statements. Use OO-type overrides, macros, LIB$INITIALIZ sections, and/or separate modules and procedures to abstract out platform differences where possible.

Do make changes that upgrade the code to comply with some published standard, such as ANSI C, the Open Group Single Unix Spec, or some relevant RFC. There are times when standards compliance makes the portability problem go away.

Don't make changes that break functionality on other platforms -- test everywhere (or at least on one non-VMS platform) before submitting.

Do submit changes as GNU uniified diffs, not as VMS DIFFERENCES output (though this varies by project).

Don't override missing CRTL functions in a way that will break if a new CRTL begins to provide them. Either do your own prefixing or do a configure-time test for the presence of the functions and define macros accordingly.

Do port, support, and run any test suite available with the package when at all possible.

Well, this could go on for pages, but it's a start.

[Ian Miller.]

I think openvms.org could be involved in this in a publicity role or hosting a poll or perhaps hosting a forum (with limited members). I don't think there is enough disk space to hold the projects.

[USO]

Some remarks :

* The OpenVMS community is very conservative (the french one) and is not strongly interested by opensource softwares.

* We are only a few folks porting opensource softwares on OpenVMS. I port during my spare time. So, I must be selective. I have choosen to port mainly Java applications because it's often easier than C or C++ and I focus on the area of middleware (JOnAS, Jetty...) and network tools (HasItHAppens, Mibble Mib Browser, JavaRDP...) because it's related with my job.

* As noted by Gerard, there is clearly a lack in the area of opensource ERP/CRM because these applications (i) are big and not easy to port and (ii) often need sofware components which don't exist on OpenVMS (PHP5, Zope application server, Postgres...).

* A directory of OpenVMS ports like java-source.net would be great and openvms.org a good place for it.

Thierry Uso.

[Ian Miller.]

creating a page on openvms.org listing sites that have unix opensource ported to vms would be simple enough. If that would help then send me email.

[labadie_1]

Hello Ian

May be a list of "wishes", with various freewares that people would like ported to Vms could help too.

Having categories would be great, e.g.
- languages
- wiki
- databases
- ERP
- CMS
- monitoring tools
- network tools
...

[Ian Miller.]

There is a porting open source to VMS forum on the hobbyist web site.

http://www.openvmshobbyist.org/phpbb2/viewforum.php?f=9

Perhaps this would be the place ?

[labadie_1]

May be.

Some interesting info would be the failures to port a software, with the reasons.

[Martin Vorlaender]

All,

>>>
* A directory of OpenVMS ports like java-source.net would be great and openvms.org a good place for it.
<<<

I volunteer to hack up something like java-source.net (i.e. not a repository, but rather a list that includes pointers). Give me a week or so, and have an eye on de.OpenVMS.org.

cu,
Martin

[Ian Miller.]

Thank you Martin and do send me an email when its available so it can be announced.

The hobbyist forum previously mentioned could still be used for discussions.

[Martin Vorlaender]

A first version of the OpenVMS Ports list (with some contents taken from the more recent announcements on OpenVMS.org) is online at http://de.OpenVMS.org/OpenVMS-Ports/

I hope I don't have to take it offline too soon (or secure it by some means) due to dummies filling the database with crap...

Suggestions, criticism, praise, money (just kidding) to martin -dot- vorlaender -at- t-online -dot- de .

cu,
Martin

[Jean-François Piéronne]

I have worked on various ports of libraries/tools on OpenVMS, include fairly large system like Python, MySQL, Webware, MoinMoin,...

When I have had to re-port stuff reasons are:
- complex building procedure, for example extract from tarfile, apply patches, compile, link, build an instalation procedure, etc...

I think it would be nice to have PCSI kit which just install the stuff.
Now I also build LD image which just contains all the necessary material.

- More important, about libraries:
* One of the problem is that you can build libraries using:
. mixed case names or upper case names, this can be hide using a sharable which export both names.
. G_FLOAT or IEEE float
. 32 or 64 bits
. object libraries or shareables.

If you want to port code, mixed case, IEEE with 32 and 64 bits is a good choice.
If you just want to use the libraries inside existing program upper case, G_FLOAT is probably better.

So if you want to cover all cases you will have to provide 8 olb libraries or at least 4 shareables.

And if you provide shareable, it would be important to maintains compatibility with older version which can be sometimes difficult to achieve for some large library.

All the libraries I have packages use IEEE float and in most case provide 32 and 64 bits versions, olb and shareables exporting mixed and upper case names. They are all package as PCSI kit.

So it should be nice to have a repository which show what is provide and in which format.

Also I suspect that a wiki would be interesting.

It should be also interesting to defined a common structures (directories, olb, shareable,...) for all these libraries/tools, this will, I hope, reduce duplicate work and may allow to find some person in charge of maintain the port (usable by others) up to date.

Just my 2 cents...

JFP

[labadie_1]

To illustrate what JF has said, read this thread

http://www.pi-net.dyndns.org/piforum/viewtopic.php?p=462#462

[Ian Miller.]

I've announced the list Martin has done

http://www.openvms.org/stories.php?story=07/10/11/1361291

Do have a look if you have not already.