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



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.

As an Amazon Associate we earn from qualifying purchases.

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.