|
midrange.com
/* Open the file descriptors so that IO works. */
fd0 = open("/dev/null1", O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IROTH);
fd1 = open("/dev/null2", O_CREAT|O_TRUNC|O_WRONLY, S_IWUSR|S_IWOTH);
fd2 = open("/dev/null3", O_CREAT|O_TRUNC|O_WRONLY, S_IWUSR|S_IWOTH);
which they place *before* creating the JVM. "Open the file descriptors
so that IO works." So is the JVM using these? Or only the piece of
the JVM dealing with I/O?
I suspect that there's a class that's trying to write data to the stderr or stdout data stream, and it just assumes that it'll be available for use. When it's not available, it crashes.
Using your service program prior to this, I never had a problem writing a new .xls, just opening an existing one. Since STRDBG/ENDDBG solved the problem, it would appear that STRDBG is opening the standard I/O file descriptors and not closing them.
Yeah, since STRDBG has an F-key to display the output from the program, it'd be logical that it'd need to capture the stdout/stderr streams so that it can display them later. This would be an important tool in debugging C, C++ or Java programs. So it's perfectly reasonable that it'd have to open them. When it's done, it probably just directs them to the normal screen output rather than closing them.
In the program I was working on, I open them before doing anything Java-related, on the assumption that the first Java-related thing I do will automatically create the JVM. I have yet to use a lot of Unix-type programs, so I haven't run into the problem of shared file descriptors. What is their open scope? The program? The job? The activation group?
I'd expect it to be the job -- but I don't know for certain, since most of the work I do that relates to this sort of thing is on FreeBSD (Unix) and not i5/OS.
On a Unix system the open would affect the current process. Any new processes would typically inherit the current processes open descriptors, so they'd be affected too. Normally when you call a program on a Unix system, you'll create a new process, run the program in the new process, and wait for it to complete. This creates something very similar to the "call stack" we have on i5/OS, allowing you to kill the called programs individually, handle their errors, etc. If the caller doesn't want to wait for the called program to complete, it doesn't have to, this allows multiple programs to run concurrently (much like submitting to batch on iSeries).
Anyway... the gist of it is that closing these descriptors would not affect your caller, it'd only affect processes that you create. Typically you'd close FD's 0-2 and open them pointing to /dev/null so that new processes would no longer have a connection to the terminal. This is useful when running what we think of as a "batch job" that doesn't have a connection to a terminal.
On iSeries, I don't know exactly how this works. Would it be scoped to the job, considering the job to be equivalent to a process? That'd make the most sense, but I don't know for sure. If it's scoped to the job, closing them could have repercussions on programs called later. You wouldn't have these problems on a Unix system unless your program that closed the FDs was called in the same process as the caller, which isn't the normal paradigm.
There are 5 threads in JAVW status after my program has opened the spreadsheet. It's unclear to me how those threads relate to my program. Are they part of my program's call stack entry?
I suspect that they're part of the JVM, not your program.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
