Re: Redirect 5250 RUNJVA output

On Thu, Aug 6, 2015 at 8:53 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Yes, running in batch this puts the Java output in the PF:
OVRPRTF FILE(QPRINT) TOFILE(QTEMP/FILENAME)
RUNJVA CLASS() PARM() OUTPUT(*)

The same app via 5250 directs the output to the display. I tried this but it just gave me a QPRINT spooled file:
OVRPRTF FILE(QPRINT) TOFILE(QTEMP/FILENAME)
RUNJVA CLASS() PARM() OUTPUT(*PRINT)

I didn't understand until now that one was batch, and that the other
was interactive. Now that I do, things make a little more sense to me.
I mean, it's still kind of annoying, but you can work around it. I
don't think there's anything you can do to meaningfully change the way
it works. (When I wrote my first response, I thought there might be
some kind of error or inconsistency to track down. But now I think
it's all Working As Designed.)

Hmm... actually, now I'm remembering that Buck once mentioned that he
changed the default behavior of stdout, maybe some environment
variable or something? It was causing some of his Python stuff to
behave differently than my Python stuff. I don't remember the
specifics, but maybe it could be leveraged to make the Java app behave
the way you want without having separate "batch mode" and "interactive
mode" invocations. Though honestly, testing for batch vs. interactive
is pretty simple and common, so I wouldn't sweat it. The solution you
outlined in your later post seems fine to me. Another possibility is
to make sure any interactive invocation submits a job, so either way
the work is being done in batch mode.

John Y.