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



On Thu, Jun 22, 2017 at 12:11 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
My understanding is that you're interested in using SNDPGMMSG, MONMSG, and
RCVMSG (or equivalent system APIs) to raise, monitor, and query messages
which may be deposited in program message queues. You've indicated that
this would work better than outputting messages to spool files and cajoling
colleagues to display the spool files.

Um, you're still mixing up two things.

The first sentence, about SNDPGMMSG, MONMSG, and RCVMSG, does relate
to the original point of this thread. It has nothing whatsoever to do
with Python. (To be clear, I was working on a tool in CL for my own
use. I mainly intended to use it in other CLPs.)

The second sentence, about program message queues working better than
printing error text to spooled output for my given work environment,
applies to iSeriesPython, but has nothing whatsoever to do with my
original reason for starting this thread. Python in general naturally
outputs to stdout and stderr. In the case of iSeriesPython, these
manifest as QPRINT spooled files.

There really should have been two threads. I'm sorry I didn't break
off my Python tangent into its own thread right from the start. I
meant it as a kind of throwaway aside. Of course it then took on a
life of its own.

It appears that my suggestions to look at possible alternatives are not
particularly well understood nor well received.

Um, I think I understand them well enough. And they are nice ideas in
and of themselves. I just don't think they are a good fit for my
purposes, in my environment. In particular, your ideas feel (to me)
like building new infrastructure and introducing new workflows; rather
than leveraging and improving existing infrastructure and existing
workflows.

Also, your ideas seem like ways to improve program-to-program
communication or program-to-end-user communication; whereas the common
theme for both branches of this thread (for me) has been
program-to-operator communication.

And I realize your suggestion of a screen-message system could apply
to operators, but I'm not completely sold on this being a significant
improvement. Honestly, though I pretty much agree with you that IBM's
message queues are not that nice for *programs* to work with, I think
they are actually quite good for *IT personnel* to work with
(interactively).

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.