Re: STRDBG/ENDDBG required to prevent Java open exception -- MIDRANGE-L

Hi Scott,

It is puzzling. The link Barbara provided is an example of a C program,and the relevant piece is


/* 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 descriptorsso that IO works." So is the JVM using these? Or only the piece ofthe JVM dealing with I/O?

Using your service program prior to this, I never had a problem writinga new .xls, just opening an existing one. Since STRDBG/ENDDBG solvedthe problem, it would appear that STRDBG is opening the standard I/Ofile descriptors and not closing them.

In the program I was working on, I open them before doing anythingJava-related, on the assumption that the first Java-related thing I dowill automatically create the JVM. I have yet to use a lot of Unix-typeprograms, so I haven't run into the problem of shared file descriptors.What is their open scope? The program? The job? The activationgroup? There are 5 threads in JAVW status after my program has openedthe spreadsheet. It's unclear to me how those threads relate to myprogram. Are they part of my program's call stack entry?

It would help a lot if DSPJOB option 14 showed open stream files, andoption 20 showed how the threads are related to the call stack.


*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /


Scott Klement wrote:

Peter, this bit of the system's Java documentation:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaha/invapiex.htm
mentions that three file descriptors should be opened in the job for
Java I/O to work when the JVM is started by the invocation API (which is
how RPG starts the JVM).  It shows some sample C code that opens the
three descriptors.
I'm struggling to understand when/where this should be used. Are yousuggesting that RPG should always close descriptors 0-2 and open them as/dev/null whenever it uses Java?
How does this interact with QIBM_USE_DESCRIPTOR_STDIO? Or C programs? orQShell scripts? Will it cause havoc for them, or is it only affectingstdin/stdout/stderr for the RPG program?
An RPG version of this code is below; you may notice that the C versionallocates to /dev/null1, null2 and null3. Apparently that is notcorrect; it should be /dev/null as the RPG version does.
Correct. /dev/null is a special file (of type *CHRSF) that simplydiscards any data sent to it. The idea is that an existing program canwork with these streams as normal without knowing that the input/output isbeing discarded.
It is not really necessary (and maybe not advisable, I'm not sure) to
close the file descriptors since they will be closed when the job ends,
but the program can be called with parameter 'N' if you want to close
the files after the Java has completed.
See, what's part of what I'm confused about. If I close these descriptorsand re-open them with /dev/null, what happens when I subsequently call a Cprogram? Will it's input/output (assuming it's using stdin/stdout/stderr)go to/from /dev/null? Won't that break things?
If I close them later, won't that cause an earlier C program in my callstack to fail when control gets back to it? What about subsequentlycalled programs?
I suppose I should test this for myself (and see what happens) rather thanasking you.
If you assume that the RPG program is the only program that's run in thejob, or you don't call anything else that works with descriptors 0-2, thenI guess you'd have no problems. I'm just a little leery of doing thisunconditionally...