topic Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl in Operating System - OpenVMS

.com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

Jonathan O'Donovan — Wed, 09 Jun 2010 14:50:27 GMT

Hi,
I am trying to use java to invoke a dcl .com file which takes 4 parameters.

This file is working properly when invoked from the command line, as follows :

$@findme.com p1 p2 p3 p4

When I use java.lang.Runtime as follows there is a problem :

package XXX.filerelease;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

import org.apache.log4j.Logger;

public class FileReleaseVmsImpl implements FileReleaseIntf{
private String DUMMYEMAIL = "\"Test@test.com\"";
public String searchForFiles(FileReferenceVmsImpl fileReference) {
String result = "";

String command = "findme.com"
+ " " + DUMMYEMAIL
+ " " + fileReference.getFormattedDateString()
+ " " + fileReference.getBatch()
+ " " + fileReference.getSequence();

Runtime run = Runtime.getRuntime();
Process pr;
try {
pr = run.exec(command);
BufferedReader buf = new BufferedReader(new InputStreamReader(pr.getInputStream()));
String line = "";
while ((line = buf.readLine()) != null) {
result += line + "\n";
}
} catch (IOException e) {
result = MHConstants.FILE_RELEASE_SEARCH_FOR_FILES_VMS_ERROR;
return (result);
}
return result;
}
}

What is happenign is that in the findme.com file, the parameters are being assigned as follows :

p1 = findme.com
p2 = DUMMYEMAIL
p3 = fileReference.getFormattedDateString()
p4 = fileReference.getBatch()
[ignored] fileReference.getSequence();

So the parameters are all offset by one.

I have tried setting the command variable as follows (using a String[]) but the result is exactly the same :

String[] command = {MHConstants.FILE_RELEASE_SEARCH_FOR_FILES_COM_FILE_TEST,
DUMMYEMAIL,
fileReference.getFormattedDateString(),
fileReference.getBatch(),
fileReference.getSequence()};

I can get around this using an intermediary wrapper file but perhaps I am causing the problem.

Thanks in advance

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

Hein van den Heuvel — Wed, 09 Jun 2010 15:36:41 GMT

This is not an area i know much about, but apparently you indeed want to use a write DCL which activates the real thing.
The wrapper would contain something like:

$ 'p1' 'p2' 'p3' 'p4' ...

Maybe alter findme.com to open with:
$ write sys$output f$environment ("procedure")

Check out:

http://h18000.www1.hp.com/java/documentation/1.4.2/ovms/docs/user_guide.html#UsingtheRuntimeexeMethodonOpenVMSAlpha

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1226409

Also be aware of DCL$PATH 'helping you'.

hth,
Hein

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

H.Becker — Wed, 09 Jun 2010 15:51:12 GMT

It's a feature and it is documented. The intention is to mimic Unix script behavior, where the parameter $0 hold the script name.

I don't think that there is a feature logical to disable this behavior. But checking the Java for VMS documentation is always a good thing.

If you need the DCL behaviour, you need a wrapper (no, there is no DCL shift command to rename parameters). Another DCL command procedure seems good enough.

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

Bill Pedersen — Wed, 09 Jun 2010 16:04:53 GMT

Jonathan:

I think this thread on comp.os.vms explains the situation best for you:

http://groups.google.com/group/comp.os.vms/browse_thread/thread/2ddac093d4522755/fa48b1496a27623b?q=runtime.exec+env&_done=%2Fgroup%2Fcomp.os.vms%2Fsearch%3Fgroup%3Dcomp.os.vms%26q%3Druntime.exec+env%26qt_g%3D1%26&_doneTitle=Back+to+Search&&d#fa48b1496a2762

Basically runtime.exec calls the CRTL routine execve and follows those rules.

What you are seeing is expected behavior according to the thread.

Bill.

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

H.Becker — Wed, 09 Jun 2010 16:33:22 GMT

Passing the DCL command file name to P1 is a Java feature:

http://h71000.www7.hp.com/doc/83final/5763/5763profile_014.html
...
For a DCL command procedure, the exec functions pass the first eight arg0, arg1, ..., arguments specified in the exec call to the command procedure as P1, P2, ... parameters, preserving the case.

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

Stuart Johnson_3 — Thu, 10 Jun 2010 02:13:40 GMT

As I recall, we solved a problem like this by execing sys$system:loginout.exe and passing the command procedure name, etc. as parameters.

I don't have the details close at hand as I've been retired a while, but if you can't take it from here let me know and I'll look through my source archive.

What running it via loginout does for you is to allow your command procedure to be in the same DCL environment as you are when you login.

Good luck with this!

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

Jonathan O'Donovan — Thu, 10 Jun 2010 09:49:10 GMT

Thanks to all for the great help offered - I am really impressed by this forum! As suggested, I have used a wrapper .com file as follows to solve the problem :

java_dcl_wrapper.com :

$ @'p1' 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'

I have used up to 8 parameters just so that I can reuse this wrapper for any .com file that needs to be invoked from Runtime.exec().

Now my FileReleaseVmsImpl class looks as follows :

package ie.interfusion.portal.business.remote.filerelease;

import ie.interfusion.portal.business.MHConstants;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

import org.apache.log4j.Logger;

public class FileReleaseVmsImpl implements FileReleaseIntf{
static Logger log = Logger.getLogger("ie.interfusion.portal.rmi.RmiFileRelease");
private String DUMMYEMAIL = "\"Test@test.com\"";
public String searchForFiles(FileReferenceVmsImpl fileReference) {
String result = "";

String[] command = {
MHConstants.JAVA_DCL_WRAPPER,
MHConstants.FILE_RELEASE_SEARCH_FOR_FILES_COM_FILE_TEST,
DUMMYEMAIL,
fileReference.getFormattedDateString(),
fileReference.getBatch(),
fileReference.getSequence()
};

log.info("Searching for file: " + fileReference);
Runtime run = Runtime.getRuntime();
Process pr;
try {
pr = run.exec(command);
BufferedReader buf = new BufferedReader(new InputStreamReader(pr.getInputStream()));
String line = "";
while ((line = buf.readLine()) != null) {
result += line + "\n";
}
} catch (IOException e) {
result = MHConstants.FILE_RELEASE_SEARCH_FOR_FILES_VMS_ERROR;
log.error(e.getMessage());
return (result);
}
return result;
}
}

The values of the MHConstants strings are as follows :

public static final String JAVA_DCL_WRAPPER = "XXX:[java]java_dcl_wrapper.com";
public static final String FILE_RELEASE_SEARCH_FOR_FILES_COM_FILE_TEST = "XXX:[JAVA]findme2.com";

Note that it seems that you have to put the '@' in the wrapper .com file - I get a

%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character

error returned if I omit the '@' from the wrapper and instead put it in the FILE_RELEASE_SEARCH_FOR_FILES_COM_FILE_TEST string as follows :

public static final String FILE_RELEASE_SEARCH_FOR_FILES_COM_FILE_TEST = "@XXX:[JAVA]findme2.com";

Re: .com file invoked from java.lang.Runtime.exec() not same as when .com file invoked from dcl

H.Becker — Thu, 10 Jun 2010 12:26:52 GMT

As already said in another thread, Java can run executable files. On VMS these are (main) images and command procedures. The "@XXX:[JAVA]findme2.com" does not specify a command procedure, it is a DCL command to invoke a comand procedure. Java should return a "java.io.IOException: Child creation error: no such file or directory".

In the wrapper, you want to invoke the target command procedure, so you usually need the @. However, if a logical DCL$PATH is defined in the context of the Java subprocess running the wrapper, you do not need the @ sign to invoke the target command procedure. In your case the DCL$PATH should include the directory XXX:[JAVA].