×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
length.)
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.
As an Amazon Associate we earn from qualifying purchases.