Java Runtime.exec()

[Nicholas Beeson]

I am writing a Java program which needs to run
Runtime.exec(). I have gotten it to work but it only works if I issue it *twice* ! What it that about?

I know that Runtime.exec() must have a command procedure filename as its parameter, and that on OpenVMS it will execute the command procedure file.

An earlier answer said "look at the documentation for the Java r.exec mechanism... the r.exec ... expects a filename, and not a DCL command."
http://h71000.www7.hp.com/wizard/wiz_9903.html

"You cannot exec() a DCL verb in the OpenVMS Java environment. For details of this and for a potential workaround, please view the Java 1.2.2 release notes for OpenVMS, available via:
http://www.compaq.com/java/"
http://h71000.www7.hp.com/wizard/wiz_6733.html

I cannot find any other information. I have read the *entire* current "Java Release Notes" and found nothing about this.

[EdgarZamora_1]

Could you show us your actual line of code?

[Hoff]

ATW has been shut down for five or so years now; I'd not tend to assume details there are the most current.

To enable tracing:

$ define/job JAVA$EXEC_TRACE true

Here's some doc on what syntax works:

http://h18012.www1.hp.com/java/documentation/1.5.0/ivms/docs/user_guide.html#workingwruntimeexec

And in addition to the r.exec command, what's in the procedure you are invoking?

[Nicholas Beeson]

Thank you.

I saw that a month ago and could not find it today. I spent all morning looking. I do not know why I did not find it.

[Jan van den Ende]

Nicolas,

to begin with:

WELCOME to the VMS forum!

On how to thank those that helped you in this forum, please review

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Proost.

Have one on me.

jpe

[Nicholas Beeson]

proc = theRunTime.exec(cmdFileName);

cmdFileName is a file created on the fly by the Java program. It contains:
$ set file $1$D26:[adir.thedir]*.*;* /protection=(OWNER:RWED)
$ delete $1$D26:[adir.thedir]*.*;*
$ EXIT

This is unreliable. Every other time it run this Java program these files do not get deleted.

Is this because OpenVMS does not recognize the process created by the Java Runtime.exec() as being owned by me?

That is I am the owner of the files, the dir, and the Java program. When the Java program runs the Runtime.exec() method, who does OpenVMS think the owner is?

[Hoff]

>>>
$ set file $1$D26:[adir.thedir]*.*;* /protection=(OWNER:RWED)
$ delete $1$D26:[adir.thedir]*.*;*
$ EXIT
<<<

Try this:

$ set noon
$ set file $1$DGA26:[adir.thedir]*.*;* /protection=(OWNER:RWED)
$ delete $1$DGA26:[adir.thedir]*.*;*
$ exit

Two changes: the file is protected against an error exit (due to a file conflict, for instance), and second change is the full specification of the target device (with $1$DGA26: assumed here).

I'd probably have a system-level logical name referencing the $1$DGA26:[adir.thedir] path, so that I didn't have the physical path coded all over the place.

And I'd expect an unlink or other more direct file deletion call would be useful; dropping down to DCL to delete files seems like Real Work.

>>>This is unreliable. Every other time it run this Java program these files do not get deleted.

Is this because OpenVMS does not recognize the process created by the Java Runtime.exec() as being owned by me?<<<

If it were protections or ownership involved here, the failure would be more consistent. The delete command would fail every time, for instance. I'd tend to guess this might be a collision with other activity within the directory. Possibly the Java code that's running right now, or possibly some other code operating in parallel.

Specific suggestion: enable the tracing and see what's going on. Or have the DCL procedure itself wrap the actual commands, and go look there. Something akin to the following:

$ set noon
$ call foo/out=ddcu:[dir]log
$ exit
$foo: subroutine
$ set noon
$ set verify
$ set file $1$DGA26:[adir.thedir]*.*;* /protection=(OWNER:RWED)
$ delete $1$DGA26:[adir.thedir]*.*;*
$ endsubroutine

I don't know that the above will work in this run-time context, but it's what I would try if tracing didn't show what I needed. Change ddcu:[dir] to be a directory path that is (for the purposes of this test) globally accessible and globally writable.

[Nicholas Beeson]

I am all set. The problem I was having was due to not consuming the output of OpenVMS as it ran the Command Prodedure. It says in the Java Runteim.exec() documentation "Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock."

I have run tests and have demonstrated that this was what was causing my problem.

Thanks to eveyone who responded. (I posted points.)