Stefan, > > On the downside a FileUtils#toVMSPath(File) would push the OS > > awareness responsibility up a level, in which case > > Commandline.Argument.setFile(File) would have to check for OpenVMS > > and call this method. > > I agree, Commandline.Argument shouldn't need to be aware of this. > Maybe the better place for toOSPath would still be Execute, even if it > would start stretching the responsibility of that class. >
Yes, Execute is rather large now: 1000+ lines. I have implemented a > > I was thinking about the FileUtils#getSetLastModified(), which using > > reflection returns the File#setLastModified(long) method. Alas, I > > found that exactly this method doesn't have any effect on OpenVMS > > Well at least it won't make a difference whether you invoke it via > reflection or not. > No, not really. It just looks ugly. > One question I asked some time last week in a post with a subject that > didn't catch your interest. Does the OpenVMS VM translate the exit > code? I.e. if your Java application exits with System.exit(0), what > will the return code be? > No, it doesn't. The $STATUS symbol will be set to the return code and $SEVERITY to the return code modulo 8. Although I found that if I run Java inside the bash shell of GNV (GNU is not VMS :-)) then the return code is rewritten by GNV! This is probably because GNV thinks you're running an image following VMS standards. So there even return codes are mapped to 2 and odd ones to 0. But Java shouldn't be subject to this, even if it's running as a child process. So again, the VM doesn't tanslate the return code. Also note that the VM will return with exit code 0 on normal termination (no explicit System.exit() call). I guess the reason for this is that they are in a little bit of a dilemma. They both have to conform to Java (Unix) and VMS standards at the same time. > I've changed <java> to use Execute#isFailure in the forked case, but > that would be wrong if the VM doesn't translate the exit code. > Then it is wrong :-( Cheers, -- knut
