Steve Loughran:
>>If there are some executables with unix result code logic, and other
bits with VMS rules, then its essentially >>>impossible to
"automatically"
>>>make the right decision.
>>>We could switch to unix-policy-everywhere, with a per-<exec> flip to
VMS if you want run VMS-specific apps. My >>>concern there is cvs and
SVN: what kind of exe are they?
I'm not 100% but I think the cvs and SVN on OpenVMS are Java
implementations.
After spending several weeks fighting the JBOSS ant testsuite (on
OpenVMS) it is starting to feel as if we need to have an ANT default
(Unix success==0), then have a per-<exec> status code option that could
redefine the success. Or maybe an OpenVMS dcl task to handle true
"native" OpenVMS executables (Just a thought but I'm sure this is a
great idea).
Let's face it, most of the Ant environments of the world expect Unix
style status codes. To make matters worst your environment could be
distributed across different operating systems (svn or cvs for example).
I'm not sure I can answer the question "What is a success value in a
distributed environment?"
I can tell you this is why rmic (Java apps in general) on OpenVMS
still returns Unix style status codes. I guess instead of saying
"returns Unix style status code" I should say "returns Java style status
codes".
Recently, OpenVMS Java engineering has been asked to change Java
applications to return a more traditional OpenVMS status code, however
in the world of Java "Write once, run everywhere" development there is
not a "isFailure" method; thus Java on OpenVMS needs to continue to
return the same status code as Hp/UX, Solaris... so the same status
value means the same across platforms.
For example Javac has 5 different status codes:
http://www.cs.duke.edu/csed/java/src1.3/sun/tools/javac/Main.java
/**
* Exit status.
* We introduce a separate integer status variable, and do not
alter the
* convention that 'compile' returns a boolean true upon a
successful
* compilation with no errors. (JavaTest relies on this.)
*/
public static final int EXIT_OK = 0; // Compilation
completed with no errors.
public static final int EXIT_ERROR = 1; // Compilation
completed but reported errors.
public static final int EXIT_CMDERR = 2; // Bad command-line
arguments and/or switches.
public static final int EXIT_SYSERR = 3; // System error or
resource exhaustion.
public static final int EXIT_ABNORMAL = 4; // Compiler terminated
abnormally.
With the current isFailure method the values of EXIT_ERROR and
EXIT_SYSERR would be success.
Status codes are just the tip of the iceberg if we really want Ant to
internally support OpenVMS. The next area of concern could be the file
system. For example:
value="${env.JBOSS_HOME}/lib/ant.jar"/>
Internally Ant is expecting something like
"/usr/jboss/jboss-4.0.3sp1-src/lib/ant.jar
However the OpenVMS file system is a little bit different:
$ show log jboss_home
"JBOSS_HOME" = "swdisk:[JBOSS_src.jboss-4^.0^.3SP1-src.]"
(LNM$PROCESS_TABLE)
Resulting in "swdisk:[JBOSS_src.jboss-4^.0^.3SP1-src.]/lib/ant.jar"
Instead of Ant being asked to interpret VMS file syntax, it would be
best to have the VMS specific "env" return the correct Unix style
filename (which Java on OpenVMS understands).
Regards,
Powell
OpenVMS/Java engineering
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
