Java: Error opening temporary file, runtime execution

[Aaron R. Smith]

Hi Receiving the error: Error opening temporary file.
When I attempt to execute a .com passing a parameter, with the syntax:

Runtime rt= Runtime.getRuntime();
Process p = rt.exec("sys$command:comJob parameter.LIS");

Do I need to set my permissions to an admin account? If so what is the syntax to do so?
Any help would greatly appreciated.

Thank you,

[Aaron R. Smith]

sorry about that, the spacing messed up on the post:


Runtime rt= Runtime.getRuntime();
Process p = rt.exec("sys$command:comJob parameter.LIS");

[John Gillings]

Aaron,

Are you sure "SYS$COMMAND:comJob" is the correct filespec? Usually SYS$COMMAND points to the terminal. Maybe it should be "SYS$LOGIN:comJob"?

[Aaron R. Smith]

Yeah I'm sure.. Sorry for the confusion I changed the first part for security reasons....

you can consider it blah$command

and yes I know that it works, when I execute
the line

$ @blah$command:comJob parameter.LIS

It works just fine, this is why I believe that it could be some type of permission issue. Some additional information:

The .COM job reads a file that the java file produces.

Thank you in advance for the help.

[Aaron R. Smith]

@blah$command:com Job parameter.LIS

[John Gillings]

Aaron,

OK, so what's the EXACT and COMPLETE error message you're seeing? Is it from rt.exec, or from within the procedure itself?

I'm not sure I understand the reference to "temporary file". Is the filename you're passing somehow classed as "temporary"? To diagnose, try replacing your procedure with one that does:

$ DIRECTORY/FULL 'p1'
$ SHOW DEVICE/FILE 'p1'
$ TYPE 'p1'

(ie: make sure the procedure can see the file, and make sure it's not opened by someone else).

If you have trouble capturing the output from inside Java, try changing the command to:

Process p = rt.exec("blah$command:comJob/OUT=test.out parameter.LIS");

[Aaron R. Smith]

I am receiving the error from the VMS side via reading the process' InputStream.
Here is the exact last two lines from the stream:

%DCL-I-SUPERSEDE, previous value of RECON_DETAIL_COMMAND_FILE has been superseded
Error opening temporary file.

However, when I run the job passing the parameter interactively via:

@blah$command:comJOB paraFile.LIS

The job executes and completes successfully.
In an attempt to clear up everything:

paraFile.LIS is created by java app.
java app. kicks-off comJob
comJob reads the paraFile.LIS

I have closed the BufferedWriter. It does not have an exclusive lock on the file. So this is not an issue (out.close()).

[Brian Reiter]

Does the location of the temporary file exist when the command procedure is run from Java? If it does exist does the java process have access to it?

Just wondering if a logical is missing somewhere.

[Aaron R. Smith]

The funny thing is, that the file is not temporary. That is just what the error is saying. The java app. creates the .LIS file.

[John Gillings]

Aaron,
Any results from replacing your real procedure with a diagnostic one?

[Craig A Berry]

The short answer is "use standard debugging techniques." The long answer is, well, longer.

Is your working directory for your Java process the same working directory your DCL procedure needs and are you sure you've created the file in the same place where the procedure will look for it? (Look at your Java docs and note that exec has an optional third parameter to specify the working directory for the subprocess.)

Make sure that the close-on-delete flag is not set on the temporary file. It is possible that closing the file in order to avoid locking is also deleting it, depending on what method is used for creating the file.

Look at your DCL procedure and consider beefing up the error checking so it tells you why it can't open the temporary file (file not found, directory not found, insufficient privilege, etc.). Review the error handling to make sure DCL exits with an error when it gets one and that an error exit from the subprocess is propagated and handled correctly by your try/catch block in Java.

Assuming the subprocess does exit with an error but you're not throwing an exception in Java that you can do anything with, use the ACCOUNTING utility to examine the final exit status of the subprocess.

Assuming an adequate test sandbox, try and see if elevating privileges gets you anywhere. You shouldn't need that in production, but it's a quick way to confirm whether it's a privilege problem.

Use SET WATCH FILE/CLASS=MAJOR (turn off with /CLASS=NONE) to see what exactly is being accessed at the time the error occurs. (This requires privs, so only does you any good if you still see the error with elevated privs).

Put the following line in the DCL procedure:

$ SHOW LOGICAL */OUTPUT=LOGICALS.TMP

then run it both without Java and from within Java and do a DIFFERENCES on the two versions of LOGICALS.TMP to see if there are any significant differences in your environment. You can control environment variables with an optional second argument to exec().