Re: It doesn't appear there's a way to separate STDOUT from STDERR on QSH
call from what I can tell.

(I'm not working in Python), but 2 thoughts:

Redirecting stdout and stderr in clp/clle
One method
CHGVAR VAR(&ENVCO) VALUE('FILEAPPEND=' *TCAT &LOGF)

ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) VALUE(&ENVCO)
REPLACE(*YES)

2nd, I would think the redirection of stdout and stderr would have to follow
the rules of shell scripting (your executing a command in QSH).
That redirecting would be at the end of the command - I wouldn't know what
shell scripting QSH follows.
Stdout descriptor is 1 stderr is 2 . > is a redirect . and although
just > will assume 1
But try this:

Redirect is after the command ... command 1>file1.txt 2>file2.txt
or to get all in 1 file command file1.txt 2>&1

this call to QSH redirects the stdout to a native file
CHGVAR VAR(&LSCOMMAND) VALUE('LS -lT /bncf/ > +
/QSYS.LIB/' *TCAT 'BNCFIL' *TCAT +
'.LIB/listfile.FILE/listfile.MBR')
QSH CMD(&LSCOMMAND)

If this is not quite relevant - my apologies
Jim Franz


-----Original Message-----
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of
Richard Schoen
Sent: Saturday, August 03, 2019 9:06 PM
To: opensource@xxxxxxxxxxxxxxxxxx
Subject: Re: [IBMiOSS] How to get Python errors to cause MSGW job status?

It doesn't appear there's a way to separate STDOUT from STDERR on QSH call
from what I can tell.

Even when I attempt to write to STDERR from Python the output ends up in
STDOUT. Calling Python script from a CL:

OVRDBF FILE(STDERR) TOFILE(QTEMP/PYSTDERR) OVRDBF FILE(STDOUT)
TOFILE(QTEMP/PYSTDOUT) STRQSH CMD(&CMD) DLTOVR FILE(STDERR) DLTOVR
FILE(STDOUT)

Python:
#Output messages to STDOUT for logging
print(dashes)
print("Start of Main Processing - " + time.strftime("%H:%M:%S"))

sys.stderr.write("spam\n")
os.write(2, b"spam2\n")

all of this output ends up in stdout including the last 2 lines where I
attempt to write to STDERR.

Thoughts ?

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
Phn: (612) 315-1745
----------------------------------------------------------------------

message: 1
date: Fri, 2 Aug 2019 20:29:16 -0400
from: John Yeung <gallium.arsenide@xxxxxxxxx>
subject: Re: [IBMiOSS] How to get Python errors to cause MSGW job
status?

On Fri, Aug 2, 2019 at 7:09 PM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

My super-nice-to-have feature would be for Python calls to be wrapped
in such a way that stderr (which is where the tracebacks go, by
default) goes into the text of a CPF9898. I got the feeling that
Richard's more elaborate Python wrapper could probably be adapted to
do this.

I should note that the particulars of this may be tricky. The most critical
issue is that the size of stderr is unbounded, whereas I'm pretty sure
CPF9898 has a fixed (and comparatively small) maximum size. So it would be
important to (1) just get the tail of the traceback into the CPF* message,
and (2) also send the full traceback somewhere, most likely the job log or a
spooled file. There are other niggling things, like error messages sometimes
counting on a certain character alignment on the screen, but presumably you
can get that kind of stuff from the "proper" full form once you've
accommodated (2).

John Y.

--
This is the IBMi Open Source Roundtable (OpenSource) mailing list To post a
message email: OpenSource@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/opensource.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


This thread ...

Replies:

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].