Hello Lim,
I really want to throw it away without flasing if possible.
There are two mechanisms (three if you count QShell, but you probably
don't want to use QShell) that will let you control the output from Java
routines called by RPG.
Method 1:
You can use overrides. For example:
OVRDBF FILE(STDOUT) TOFILE(QTEMP/DISCARD)
OVRDBF FILE(STDERR) TOFILE(QTEMP/DISCARD)
The idea here is that you'd create a temporary PF named "DISCARD" in
QTEMP, and you'd use OVRDBF to send standard output & standard error to
those files.
Likewise, you can use OVRPRTF if you want to put the output in the spool.
OVRPRTF FILE(STDOUT) TOFILE(QSYSPRT) HOLD(*YES)
OVRPRTF FILE(STDERR) TOFILE(QSYSPRT) HOLD(*YES)
The tricky part about these options... The overrides only apply to the
OPEN of the files, and the files are opened when the JVM starts, and
closed when the JVM ends. That means that if you use the OVRDBF method,
you can't delete the files from QTEMP -- you have to wait til they're
deleted automatically when the job ends. It also means you have to be
sure to set the OVRDBF/OVRPRTF command before the JVM is started, and
it'll be started with the first RPG program (or other language) that
uses Java.
I use method 1 a lot for troubleshooting because it's a simple way to
see the messages that otherwise might scroll off my screen before I can
see them.
Method 2:
This is the way that IBM documents in the ILE RPG Programmer's guide.
It requires you to set the following variables before the JVM is started:
ADDENVVAR ENVVAR(QIBM_USE_DESCRIPTOR_STDIO) REPLACE(*YES) +
VALUE(Y)
ADDENVVAR ENVVAR(QIBM_RPG_JAVA_PROPERTIES) REPLACE(*YES)
VALUE('-Dos400.stdout=file:/dev/null;+
-Dos400.stderr=file:/dev/null')
This tells Java to write the standard out stuff to /dev/null (which
causes it to be discarded) and also standard error is set to /dev/null.
You can also specify an IFS path name for a normal file if you want
the data to be written to that file.
Like the other option, this has to set before the JVM is started.
This method also has the ability to direct the output to a TCP port...
useful if you're writing client/server software where you want the
output to go to a GUI program.
midrange.com
