Re: What's the proper way to "reraise" in a CLP?

Buck, I haven't combed through your sample code that carefully, though
I think I get the basic gist, and I definitely picked up a bonus that
I hadn't asked for:

On Thu, Jun 15, 2017 at 1:48 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

if (&expected *eq 'N') do
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) +
msgdta('Scan backup joblog for CPF3761, CPF3771, +
CPF3741') +
MSGTYPE(*info) tousr(HELPDESK)
MONMSG (CPF0000 MCH0000)
enddo

Since I'm not too familiar with the system message files (or really
any message files, and the whole messaging system), I didn't realize
IBM provided a designated system CPF message suitable for impromptu,
highly customized and informative, high-severity messages!

Sure, I can see the value of building your own custom message file.
But it's not very impromptu, and it's less "portable". (It's another
piece you have to remember to migrate.)

CPF9898 (and perhaps CPF9897? maybe a few others?) could be very handy
for general CL programming.

Not only that, I'm starting to envision it living in a CLP wrapper
which, if I can get it to work well enough, could drastically change
the way my colleagues interact with iSeriesPython.

Right now, all my Python stuff relies on Python's exception system.
It's quite a good system, but it is expecting to write to stderr or
stdout, not to IBM's message queues. How this manifests in
iSeriesPython is that the Python exceptions get printed to QPRINT and
you thus have to inspect the spooled files, not the job log. What
shows up in the message queue when an iSeriesPython program causes the
job to MSGW is either on the mysterious/scary side (appearing to be a
pointer or memory corruption issue) or the generic side (general
application error); either way, not easy to diagnose, and not
encouraging the viewer to look any further.

This is frustrating, because I actually do craft quite readable error
messages, and a lot of Python's own messages shouldn't be very scary
to programmers. If only my colleagues would bother to look at the
spooled files, they would see that the problem is often something they
can fix, or at least something useful they can relay back to the user.
For example, I recently had a case where my boss, had he looked at the
spooled file, could have told the user "hey, you entered an address
that our software couldn't validate, and this is the offending
address" rather than what he actually told the user, which is "sorry,
it's a Python problem; you'll have to wait until John gets back".

I'm trying to get people to be less afraid and mystified by Python,
but I'm sure you know how hard that can be. If I can at least get a
meaningful error message in front of their eyeballs, that might go a
long way.

John Y.