It's worth noting that the PASE libc "syslog" function (which Python
most likely wraps) will output to the system operator log, given enough
of a fatal condition. For example, this PASE C program will produce
(given what's passed to it on the command line as the first arg):

```c
#include <syslog.h>

int
main (int argc, char **argv)
{
syslog(LOG_ALERT, argv[1]);
return 0;
}
```

Will produce:

```
Display Message Details

Message ID . . . . . . : Severity . . . . . . . : 80
Date sent . . . . . . : 08/02/19 Time sent . . . . . .
: 22:44:21
Message type . . . . . : Information
From . . . . . . . . . : CALVIN CCSID . . . . . . . .
: 819

From job . . . . . . . . . . . : QP0ZSPWP
User . . . . . . . . . . . . : QSECOFR
Number . . . . . . . . . . . : 971489

From program . . . . . . . . . : QP2USER2

To message queue . . . . . . . : QSYSOPR
Library . . . . . . . . . . : QSYS

Time sent . . . . . . . . . . : 22:44:21.346138
Time zone abbreviated name . : UTC
```

Unfortunately, this isn't the job log, but perhaps the right flags
passed to syslog will elicit something. I'd have to cross-reference
PASE specific documentation to be sure.

On Fri, 2019-08-02 at 14:49 -0400, John Yeung wrote:
Though IBM's Python 3.6 for PASE is a significantly better language
overall than iSeriesPython 2.7, there are still some aspects of
iSeriesPython that I like better.

One of them is that when an exception occurs in an iSeriesPython
program, it registers as a WRKACTJOB-visible error. The error itself
isn't particularly informative; it's just "application error" and then
you have to dig further. Or maybe the job ends automatically but
abnormally. In any event, you get *some* kind of system-level
indication that something went wrong.

I've been using Python 3.6 for PASE, and all the jobs end "normally",
no matter what. It's been difficult for me to get into the habit of
always verifying every single job by looking at the spooled output.
Even if I do eventually get to the point that it's a habit, it's still
pretty damn annoying and productivity-sapping.

So, one brainstorming challenge for myself and anyone else who is
inclined to think about this is: Can we build a Python calling system
that detects Python exceptions and causes MSGW?

I would be remiss if I didn't point out that Richard Schoen's "Python
on i" library does at least make it easy for Python output to go to
the job log. He deserves credit for what is the current "Cadillac of
Python wrappers". But if the job ends normally, how do I know to check
the job log? It's essentially the same issue I have now, just that my
output goes to spooled files named QPRINT instead of to the job log.

Now, I haven't really dissected Richard's library. Perhaps it could be
adapted so that output to stderr triggers an error message or abnormal
end.

John Y.


This thread ...

Follow-Ups:
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].