Re: STRDBG/ENDDBG required to prevent Java open exception

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 you
suggesting that RPG should always close descriptors 0-2 and open them as
/dev/null whenever it uses Java?

No, not at all; it should definitely not close those descriptors.  It
may coincidentally open those descriptors, but it is just as likely to
open descriptors 14-16, or maybe 14, 25, 34.  It just seems to be
necessary to have at least 3 descriptors open for some aspects of Java
I/O to work correctly.  I don't believe the descriptors are actually
used for the 3 I/O streams by Java.  At least, all the evidence I have
seen suggests that they aren't used.

The RPG program isn't closing descriptors 0-2.  It's closing the
descriptors in an array that it earlier filled by calling open().
   for i = 1 to 3;
      closeFile(fd(i));

How does this interact with QIBM_USE_DESCRIPTOR_STDIO?  Or C programs? or
QShell scripts? Will it cause havoc for them, or is it only affecting
stdin/stdout/stderr for the RPG program?

If you use QIBM_USE_DESCRIPTOR_STDIO, the data doesn't get written out
to your files unless the descriptors were opened.  There's no apparent
Java exception in this case, but the output doesn't seem to go anywhere.

I don't think it has anything to do with C's stdin stdout and stderr. 
The normal Java output screen isn't shared with the C stdout screen.  I
believe QShell already opens 3 descriptors when it starts up, so if your
RPG program opens 3 more, it won't affect anything.

An RPG version of this code is below; you may notice that the C version
allocates to /dev/null1, null2 and null3.  Apparently that is not
correct; it should be /dev/null as the RPG version does.

Correct.  /dev/null is a special file (of type *CHRSF) that simply
discards any data sent to it.  The idea is that an existing program can
work with these streams as normal without knowing that the input/output is
being 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 descriptors
and re-open them with /dev/null, what happens when I subsequently call a C
program?  Will it's input/output (assuming it's using stdin/stdout/stderr)
go to/from /dev/null?  Won't that break things?

You shouldn't close descriptors 0 - 2; those might be active for
something completely unrelated.  You should only close the three
descriptors that you opened yourself, if any.

If I close them later, won't that cause an earlier C program in my call
stack to fail when control gets back to it?   What about subsequently
called programs?

Nothing would be using those descriptors, since your RPG program is the
only thing that has access to them.

I suppose I should test this for myself (and see what happens) rather than
asking you.

I only have empirical evidence myself; I have never seen anything bad
happen as a result of doing this.  I have seen it correct problems with
QIBM_USE_DESCRIPTOR_IO and with Java I/O exceptions.  I admit that I had
pretty much the same questions as you are having when I first read about
it in the system's documentation on using the invocation API.

If you assume that the RPG program is the only program that's run in the
job, or you don't call anything else that works with descriptors 0-2, then
I guess you'd have no problems.  I'm just a little leery of doing this
unconditionally...

I would be leery too, if it was explicitly closing the descriptors with
the actual handle 0 1 and 2.