ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Gentle <>
Subject RE: <exec> on openvms
Date Thu, 10 Jul 2003 13:07:22 GMT
Guys, if you're willing to introduce a JNI lib for VMS, all the operations 
you wish to perform are available through VMS System Services, including 
getting/setting the Logical Names, and, IIRC, launching a DCL interpreter 
directly, avoiding the need for the DCL wrapper.

It's been a while (like 1997!) since I worked on VMS, and I don't have 
access to a VMS box right now, but I'd be willing to chip in on the JNI 
library if that is acceptable.

Downside is that you'll have to ship the VMS shared library, or the ant 
installation process would need to include the source with instructions on 
how to compile and link it (or a DCL script to do so).

Just another option...


At 08:55 AM 7/10/2003, you wrote:
> >
> > > 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.
> >
> > In either case, we should add some platform specific notes into the
> > Ant manual.
> >
>Certainly, yes.
> > > 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.
> >
> > Do you think we have a chance to tell a VM that works from one that
> > doesn't within Execute?  I mean, we always could use reflection to
> > detect the three arg version of exec, but maybe there is an easier
> > way.
> >
>Well, the three arg version (with a specified working directory) is always
>present, but it only works if the logical JAVA$FORK_SUPPORT_CHDIR is defined
>in the job table, i.e. if prior to launching Java the following has been
>         $ define/job JAVA$FORK_SUPPORT_CHDIR TRUE
>So it's not only a matter of the VM, unfortunately.  But the other
>Runtime.exec() methods (without working directory) should all work.  If the
>logical isn't defined, Runtime.exec() will return with an IOException with a
>message like "function not implemented".
>I assume it will be necessary to implement a VMS specific CommandLauncher
>for launching through the shell.  I'll have to check how to do that.  Its
>implementation could for instance write a temporary DCL script (.COM file)
>and execute the command through that.
>It would also be interesting whether it's possible to get a list of all
>defined logicals (for <property environment="env"/>).  This would probably
>again require writing and executing a temporary .COM file.
>Also, I currently don't know what the VM does with environment variables
>passed to Runtime.exec().  I'll try to find out.
> > Expect Os.isFamily("openvms") to work in a few minutes 8-).
> >
> > >> >  - The Ant <exec> task throws a BuildException if the exit code
> > >> >  is unequal zero.
> > >
> > > 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?
> >
> > Maybe we should provide a Execute.isFailure(int result) method that
> > returns result != 0 on all platforms except OpenVMS (and
> > result % 2 != 0 on OpenVMS).
> >
> > > Or would ExecTask need some modifications?
> >
> > To accompany that, yes.  I'd prefer to keep the platform specific code
> > isolated in Execute.
> >
>That sounds like a very clean approach.  There seem to be some other tasks
>which check the return value of Execute#execute() against zero though,
>including <cvs>, <cvstagdiff>, <cvschangelog>, and <javadoc>.
 Would this
>change be a backward compatibility issue?
>Once I have gathered all the information I'll try to write a patch for
>Execute to get <exec> and friends to work on VMS.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message