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

[Jonathan O'Donovan]

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

[Hein van den Heuvel · Accepted solution]

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

[H.Becker]

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.

[Bill Pedersen]

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.

[H.Becker]

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.

[Stuart Johnson_3]

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!

[Jonathan O'Donovan]

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";

[H.Becker]

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