On Wed, Aug 5, 2015 at 4:16 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:
I have an app that uses a number of RUNJVA commands with the output directed to a QTEMP PF, via an OVRPRTF FILE(QPRINT) TOFILE(QTEMP/FILENAME).

Let me stop you right there. How is this working for you? Do you
actually get output in QTEMP/FILENAME?

I'm now trying to run the same app via 5250 and I can't get the RUNJVA output to go to a PF. If I specify OUTPUT(*PRINT) on the RUNJVA, it goes to a QPRINT. If I don't specify that, it goes to the display. I tried OVRPRTF FILE(STDOUT) TOFILE(QTEMP/FILENAME), but the output still went to the display.

QPRINT *is* the stdout when you do OUTPUT(*PRINT).

It doesn't really make sense in the stream-based world (which includes
Java, and pretty much any mainstream language) to redirect stdout to a
PF. PFs have an inherent concept of "record" and streams don't.
Actually, QPRINT is already not a perfect fit for stdout, because
QPRINT's lines are a finite length also. (So QPRINT really has records
as well, and indeed this can cause problems when using a stream-based
language to output a line which is longer than QPRINT's record

What you want to do if you really want your stdout to go to a PF is to
simply copy the resulting QPRINT to a PF using the CPYSPLF command.

Better still, if you have control over the Java code, is to modify the
Java code so that it outputs to a file other than stdout. But I
believe CPYSPLF is by far the simplest way to get the closest to what
you're asking.

John Y.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].