Hi Eric,
eric.bachard wrote:
> Glad to read our work is usefull for other ports.
>
> To be more efficient, do you have suggestions to help OpenVMS port more ?
>
> e.g. document more, explain some parts ? This is extremely interesting !
The similarities between our teams are:
* we are small teams, at the moment the OpenVMS porting group has
only to active members
* we port to challenging platforms
Also you were not that far along when we started our port.
Some of the problems we are facing:
We decided pretty early on to use the UNIX like environment provide by
the DII COE effort (HP project). This would provide us with a bash shell
and hopefully the entire POSIX standard command set and update libraries
with (optionally) more UNIX standard behavior.
A small example of this optional more UNIX standard behavior:
The open system call, on UNIX and most other OS's out there, simply
overwrites an existing file when opening a file for write.
On OpenVMS the same open call would create a new version of the file
instead, leaving the original file in tact. The new optional
behavior in OpenVMS allows us to switch between OpenVMS and UNIX
behavior and thus tell open to overwrite the existing file (or at
least the last version of the file).
Some other examples:
* There are runtime options to switch from 32.32 upercase only
filenames to case sensitive, with multiple dots and spaces,
filenames on filesystems that allow it (ODS5).
* Historically OpenVMS added ".DIR" to every directory name. As I'm
told by someone from OpenVMS engineering, there never was a
technical reason for doing this, but people using PDP's an
probably DEC 10's were used to this so Dec decided the keep this
behavior in OpenVMS. At present there is a feature switch that
removes ".DIR" from very directory name reported to a C/C++
program and ads it when sending a command to the filesystem. The
first incarnation of this feature switch did not allow me to
create a file fonts.dir and a directory fonts in the same
directory. Although the filesytem did allow it, he C runtime
libraries didn't. This problem was fixed in the last incarnation
of OpenVMS.
The DII COE effort would allow us to port the missing GNU build tooling
to our system and start the OpenOffice.org port from there.
The biggest problem we currently have is that all these great
improvements are being delivered in small bits and peaces and they
aren't quite there yet to start our port. And while the libraries are
changing in a steady pace, the command set is adopting the newly
introduced features very slowly and could do with a major overhaul by
now. Bash for example is still at version 1.x and its source code is
contaminated by old obsolete hacks. Most of the rest of the basic
toolset is pre GNU coreutils!
All we could do so far was try and port little things, like cvs and
report back to HP.
One of the things we ported early on was dmake. However there was no
documented way to test dmake other than to build something with it. This
is indeed one of the general problems starting porting groups face.
We are currently not the only ones struggling with this HP provided UNIX
like environment for OpenVMS. We know that the perl port, The Apache web
server port, the Mozilla Thunderbird and Firefox port also want to use
this environment. Obviously companies like Oracle are also very
interested in this environment because this could bring down the cost of
porting there products to OpenVMS. On the log run this could bring more
product to OpenVMS and ultimately extend it market share.
We are currently awaiting a major update of bash and command set from HP
and hopefully this will get our port from the starting line.
Regards,
Martin Borgman.
