Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Java: Error opening temporary file, runtime execution

Aaron R. Smith
Occasional Advisor

Java: Error opening temporary file, runtime execution

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,
10 REPLIES
Aaron R. Smith
Occasional Advisor

Re: Java: Error opening temporary file, runtime execution

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

Re: Java: Error opening temporary file, runtime execution

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

A crucible of informative mistakes
Aaron R. Smith
Occasional Advisor

Re: Java: Error opening temporary file, runtime execution

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

Re: Java: Error opening temporary file, runtime execution

@blah$command:com Job parameter.LIS
John Gillings
Honored Contributor

Re: Java: Error opening temporary file, runtime execution

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

A crucible of informative mistakes
Aaron R. Smith
Occasional Advisor

Re: Java: Error opening temporary file, runtime execution

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

Re: Java: Error opening temporary file, runtime execution

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

Re: Java: Error opening temporary file, runtime execution

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

Re: Java: Error opening temporary file, runtime execution

Aaron,
Any results from replacing your real procedure with a diagnostic one?
A crucible of informative mistakes
Craig A Berry
Honored Contributor

Re: Java: Error opening temporary file, runtime execution

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