Stefan,
Thanks for your quick reply.
>
> > At our company we're developing Ada95 code for various platforms,
> > including OpenVMS.
>
> You are the first person reporting anything about Ant on OpenVMS
> AFAIK.
>
Don't know whether I should be surprised or not... But the VM
implementation provided by HP is actually quite up-to-date. On Alpha there
is even a 1.4.1 version.
> I used to work with OpenVMS about seven to five years ago, but I've
> never done any Java development there. I've often wondered how Ant's
> file handling code was going to work there, given the file name syntax
> that doesn't really fit the notion of a "file separator char".
>
The VM supports both VMS native file path syntax and a Unix style filenames
for most operations. It is configurable how the VM should map between the
two. That way I can work with paths like
/$disk1/smith/test.jtjtj/test.jtjtj.
> I take your problems with <exec> as an indication that the rest of Ant
> seems to work, yes?
>
Well, I haven't run any extensive tests. I'm only using a very limited set
of tasks. But overall, it seems to work.
> > - To use Runtime.exec() the command to be executed usually has to
> > be written into a temporary DCL script first. Then this script is
> > executed using Runtime.exec().
>
> Why? Is this something specific to the VM implementation or a
> limitation imposed by Ant? Can we solve this by an OpenVMS specific
> command launcher in Execute?
>
These limitations are imposed by the VM implementation. In summary you can
run .EXE images using Unix style filenames and .COM files (DCL scripts)
using VMS filenames or relative (to a logical) Unix filenames. DCL verbs
can't be run directly. I'm not sure in what cases arguments can / can't be
passed.
I think it should all be solvable inside Execute. You could restrict users
to only execute .EXE and .COM files on VMS. Another solution is to write
the command to a temporary .COM and then execute that. But I have to do
some more testing here.
Another limitation by VMS is the command line length. In the terminal it's
limited to 256 characters and inside a DCL script to 1024 characters. But
VMS will whine if the command is too long, so I don't think this needs
handling inside Ant.
> > - The Java 1.4 JVM provided by Compaq/HP has some problems with
> > Runtime.exec(). Specifically it doesn't support the variant of
> > Runtime.exec() with a specified working directory
> > (Runtime#exec(String[], String[], File)).
>
> Should be easy to fix. We already special case OS/2 here as IBM's 1.3
> VM for OS/2 ships with a bogus implementation. What does the os.name
> system property look like?
>
The Runtime.exec() with working directory *does* work in more recent
versions of the JVM (1.3.1-6 and up) given that a special symbol has been
defined.
The value for os.name is "OpenVMS". I've been using Os.isName("openvms")
quite a lot. It works.
> > - The Ant <exec> task throws a BuildException if the exit code is
> > unequal zero. On VMS an odd exit code signifies success and even
> > exit codes are errors. (The exit code zero actually signifies a
> > warning.)
>
> I knew that, but I thought that System/Runtime/Process implementations
> would hide it.
>
> This makes Java's System.exit quite a bit inferior to C's exit using
> the EXIT_SUCCESS and EXIT_FAILURE constants from stdlib.h, DEC's C
> compiler used to define them correctly.
>
Do you know how to get around that? Should the Execute class, in the case
of VMS, map the exit status to what's common on Unix systems? Or would
ExecTask need some modifications?
> > I implemented my own <exec> task by subclassing ExecTask to get
> > around these incompatibilities.
>
> I'd prefer an approach that localized the changes in Execute instead,
> if possible.
>
I'd be happy to write some patches for Execute to get <exec> and other tasks
using it working on VMS. Would this be of general interest to the Ant team
or should I just keep those changes to myself?
Regards,
--
knut
