| Summary: | Problems with OSD-5 filespecs and return codes on OpenVMS | ||
|---|---|---|---|
| Product: | Ant | Reporter: | Meg Garrison <Meg.watson> |
| Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 1.7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | HP | ||
| OS: | OpenVMS | ||
We are interested in your test results and in your suggested patches. Are you sure that there are no more systems around wit this ODS-2 format ? I know nothing about OpenVMS. Regards, Antonie Thank you. We're working on testing the changes right now. ODS-5 is a superset of ODS-2 so extending support to ODS-5 will not prevent ODS-2 support from working. I'll post the diffs and the test results (before and after) later today. I also posted a question to the dev mailing list about naming suggestions for a property to control the return status from Ant (small change to isFailure for OpenVMS). Meg |
We're currently looking into some problems with filespecs and return codes on OpenVMS. These are two areas where OpenVMS is very different from Unix-like operating systems. Filespecs on OpenVMS have a different format than standard Unix filespecs. A conversion routine to convert between the Unix-style and OpenVMS-style formats is already in FileUtils.java, but it is out of date since it assumes (older) ODS-2 style OpenVMS filespecs, and the current format is ODS-5 style. We propose to update this routine to support the conversion of ODS-5 style OpenVMS filespecs to/from Unix-style filespecs. In addition, OpenVMS normally returns a 1 for success from functions and system calls, for failures it returns a value which is a predefined error code > 1. However, Java assumes that the return value is the number of errors encountered, which means that 0 is successful. We're proposing changes to Execute.java to control which return style is used (conditionally on OpenVMS systems) by checking the value of a logical name on OpenVMS (like an environment variable). Also in Execute.java, some changes to the way certain DCL commands are built will enable tasks like <exec/> to work properly. At this time, if the argument to <exec/> is an image represented by a Unix-style filespec, the <exec/> will fail. As an example, a test suite that reproduces these problems is Test: org.apache.tools.ant.taskdefs.SignJarTest [test-junit] Tests run: 32, Failures: 2, Errors: 19, Time elapsed: 284.826 sec With your permission we will post the entire test results (from OpenVMS) before and after and the patches here to this bug report.