Java exec env value not working?
Richard
I need to run a VMS command proc from Java (yes, I know I shouldn't do
things like this in Java) Looks like this:
...
String env [ ] = {"a = 25"};
Process p = Runtime.getRuntime.exec ("test.com", env);
p.waitFor ( );
...
test.com gets run ok but the symbol "a" does not exist there. Is this
not the expected behavior?
WillWilliamsosx
Craig A. Berry
wil...@usa.net (Richard) wrote:
> I need to run a VMS command proc from Java (yes, I know I shouldn't do
> things like this in Java) Looks like this:
>
> ...
> String env [ ] = {"a = 25"};
> Process p = Runtime.getRuntime.exec ("test.com", env);
> p.waitFor ( );
> ...
>
> test.com gets run ok but the symbol "a" does not exist there. Is this
> not the expected behavior?
I don't know what the expected behavior is, but are you sure the
environment will be implemented as DCL symbols rather than logical
names? I suggest trying SHOW LOGICAL A in test.com to see what you
get. In the unlikely event that the implementation has bungled its
internal lib$spawn call by not passing reasonable flags for inheriting
the environment, there is purportedly a way to call RTL routines
yourself from java, so you could, for example, call lib$set_logical or
lib$set_symbol before instantiating your Runtime object (I mean, um,
running your command procedure). To say more would require actually
reading the java for OpenVMS documentation ;-).
Richard
WHAT DOCUMENTATION? All there is is release notes which are nice but
don't talk much about JNI and dont' mention Runtime calls at all.
Nope. Logical not set either.
Can't call lib$ or equiv because Java code is not public.
WillWilliamsosx
Craig A. Berry
> "Craig A. Berry" <craig...@nospam.SignalTreeSolutions.com> wrote in
> message news:<craig.berry-D00D...@news.directvinternet.com>...
> > In article <9dbe34c3.02040...@posting.google.com>,
> > wil...@usa.net (Richard) wrote:
> >
> > > I need to run a VMS command proc from Java (yes, I know I shouldn't do
> > > things like this in Java) Looks like this:
> > >
> > > ...
> > > String env [ ] = {"a = 25"};
> > > Process p = Runtime.getRuntime.exec ("test.com", env);
> > > p.waitFor ( );
> > > ...
> > >
> > > test.com gets run ok but the symbol "a" does not exist there. Is this
> > > not the expected behavior?
> WHAT DOCUMENTATION? All there is is release notes which are nice but
> don't talk much about JNI and dont' mention Runtime calls at all.
Well, I was really just indicating that *I* hadn't read any docs or even
looked to see if there were any.
> Nope. Logical not set either.
>
> Can't call lib$ or equiv because Java code is not public.
Hmm. This seems worth a call to the CSC with a small, complete example
with which they can reproduce the problem. My current guess is that
java is just invoking the C RTL to do a vfork() and exec(), passing
along the environment vector as the optional third argument to exec().
I believe (but could be wrong) that this only means something when the
thing you execute in the subprocess is a C program that accepts the
environment as the optional third argument to the main() function. If
that's true I think it is only the C RTL's internal environment array
that is affected, not logical names or CLI symbols.
Have you tried passing something like "pipe a=25 ; @test.com" as your
command argument?
Jan-Erik Söderholm
be local to the sub-process and, of course, be deleted
together with the sub-process.
Maybe defining a JOB-table logical name would work ?
Jan-Erik Söderholm.
Keith A. Lewis
>"Craig A. Berry" <craig...@nospam.SignalTreeSolutions.com> wrote in message news:<craig.berry-D00D...@news.directvinternet.com>...
>> In article <9dbe34c3.02040...@posting.google.com>,
>> wil...@usa.net (Richard) wrote:
>>
>> > I need to run a VMS command proc from Java (yes, I know I shouldn't do
>> > things like this in Java) Looks like this:
>> >
>> > ...
>> > String env [ ] = {"a = 25"};
>> > Process p = Runtime.getRuntime.exec ("test.com", env);
Process p = Runtime.getRuntime().exec ("test.com", env);
>> > p.waitFor ( );
>> > ...
>> >
>> > test.com gets run ok but the symbol "a" does not exist there. Is this
>> > not the expected behavior?
>
>WHAT DOCUMENTATION? All there is is release notes which are nice but
>don't talk much about JNI and dont' mention Runtime calls at all.
My guess is that Java calls the DEC C setenv() function, which sets an
"environment variable" in a place that only C can read -- pretty useless
IMHO. And it isn't passed to any kind of created process. This is a case
where the working Unix code compiles fine on VMS but operates incorrectly.
It's easy to see how it could get by Compaq's VMS Java team.
The DEC C getenv() isn't too hot either. It reads a copy of the symbols and
logicals which is loaded into C space at image start time, so it won't
notice a change unless the change is made by setenv(). I wrote my own
getenv() for that reason.
The good news is that VMS Java *might* use DECC$SHR for those functions.
I wonder if you could rewrite getenv() and setenv() and put them in a
shareable image that replaces DECC$SHR.EXE without re-implementing 98 other
C runtime functions.
IIRC there's an old version of the C compiler which used the logical
name table for all this. If you install the RTL from that you might get a
reasonable behavior; otherwise you just need to wait for Compaq to fix this.
>Can't call lib$ or equiv because Java code is not public.
And that would defeat Java's platform-independance too.
--Keith Lewis klewis$mitre.org
The above may not (yet) represent the opinions of my employer.
Rick Retterer
This all has to do with the CRTL (C-Runtime Library). When you
call the "exec" method in Java, what is called from the CRTL is the C
routine execve().
execve passes the name of an image to be activated in a child process.
This function is non-re-entrant... When the operating system executes the
program, it places a copy of the current environment vector (envp) in the
external variable "environ". From DCL, there is no way to get to the
external variable.
In Unix, this is possible because you are execing a shell, that runs a
script... since the shell is a executable c program, the environment
variables are available from the CRTL.
Now, I'm the first to admit, this isn't documented very well, but in the
DEC C Library Reference manual, in the explaination for execve() briefly
touches this subject at the bottom of the page.
So, is this a short-coming of JAVA, well no not really. This has to do
with the C runtime library and DCL. Since DCL isn't typically used in the
SUN, HP, Tru64 Unix, DOS, or MS-Windows, this is one of the limitations of
using "exec" under OpenVMS.
Here is how I accomplished a workaround:
1)=========== test.com =================
$ reply/user=retterer "ok"
$ open/write o out.dat
$ write o "showing sym P1"
$ write o "''P1'"
$ write o "showing sym P2"
$ write o "''P2'"
$ write o "showing sym P3"
$ write o "''P3'"
$ close o
$ exit
<EOF>
2)========== Test1.java =================
import java.io.*;
class Test1 {
public static void main (String []args) {
try {
String env [ ] = {"test.com", "101", "102"};
System.out.println ("running test.com");
Process p = Runtime.getRuntime().exec (env);
p.waitFor ( );
} catch (Exception e) {
System.out.println ("Caught Exception " + e);
}
}
}
<EOF>
3) =========== Compile Program ============
$ javac test1.java
4) =========== Execute Program =============
$ java "Test1"
5) =========== out.dat file ================
showing sym P1
test.com
showing sym P2
101
showing sym P3
102
The P1 parameter is always going to be the filename.
The P2-P3 parameters, are the arguments you pass along with the filename.
I guess you could call P2 and P3, environment variables, but under VMS they
are symbols or parameters passed to the command procedure.
You could then, (if you wanted) modify your test.com file to manipulate P2
and P3 the same way you would manipulate symbols in a regular DCL program.
6)============= Modified test.com ===========
$ reply/user=retterer "ok"
$ open/write o out.dat
$ write o "showing sym P1"
$ write o "''P1'"
$ write o "showing sym P2"
$ write o "''P2'"
$ write o "showing sym P3"
$ write o "''P3'"
$ sum = 'P2' + 'P3'
$ write o "Sum of the two is: ''sum'"
$ close o
$ exit
7) =========== New out.dat ====================
showing sym P1
test.com
showing sym P2
101
showing sym P3
102
Sum of the two is: 203
I hope this helps.
Rick Retterer
Compaq Global Services
Atlanta, Ga.
Richard
results. Rick tells me that "Colin" is supposed to reply to this
thread and explain what Digital - whoops Compaq Java engineering
thinks of all this.
Richard
found.
When execev creates the subprocess it uses lib$spawn. By default,
lib$spawn creates the new process CLI with all the symbols and
logicals from the parent process.
The Java Runtime exec(prog, env) is calling a Compaq routine (right?).
That called routine (the one that calls execve) could take the
incoming env argument and make multiple calls to lib$set_logical.
This would then allow the program/com to work about like Unix and Win.
I am suggesting that the Java team consider this as a possible change.
Richard