HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Java Runtime.exec()

 
Nicholas Beeson
Occasional Visitor

Java Runtime.exec()

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.
7 REPLIES
EdgarZamora_1
Respected Contributor

Re: Java Runtime.exec()


Could you show us your actual line of code?
Hoff
Honored Contributor

Re: Java Runtime.exec()

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
Occasional Visitor

Re: Java Runtime.exec()

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
Honored Contributor

Re: Java Runtime.exec()

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
Don't rust yours pelled jacker to fine doll missed aches.
Nicholas Beeson
Occasional Visitor

Re: Java Runtime.exec()

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
Honored Contributor

Re: Java Runtime.exec()



>>>
$ 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
Occasional Visitor

Re: Java Runtime.exec()

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.)