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



Nathan, I'm afraid I understand very little of your post. Buck seems
to have understood you, though.

I will try to explain my best guesses:

On Tue, Jun 20, 2017 at 4:46 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
It appears that you may be interested in a generic (i.e. common, standard)
way of returning messages from Python scripts to CLPs. The use of IBM
call-stack message queues, *DIAG and *ESCAPE messages in that regard is too
confusing and problematic in my experience.

Buck seemed to focus on the second sentence there. I think I
understand that sentence, and I mostly agree. I think it is a
double-edged sword. It's developed and robust, but complex. So it's
potentially very informative, but it is not easy for the uninitiated.

I am very hazy on the first sentence. Are you saying that you think I
am looking for a way to allow a Python program to issue SNDPGMMSG?

If so, then you are partially correct. That wasn't the reason I
started this thread, but it is something that might be useful to me.
No matter how arcane the IBM i message queues may be, that is the
interface that midrangers, especially of a certain age, are used to.
They don't even know where else to look. I spent most of a lengthy
post already explaining that I think Python's own messages, and
certainly the Python messages that I write myself, are much simpler,
clearer, and more helpful than *DIAG and *ESCAPE and so forth. But my
colleagues don't see them and don't seem inclined to learn how to look
for them.

Another consideration is that it is impractical to integrate Python's
exception system into the operating system messages in the way RPG's
messages are. The effort would be enormous, and I'm not sure the
result would be Pythonic anymore. That is, it would likely make it
actively harder and uglier to program in Python. I think what makes
sense is something superficial: Just a single MSGW-causing message
where appropriate. And now that I'm exposed to CPF9898, I have that.

When users embed code in CLPs to receive messages from call-stack message
queues, it's never really clear to them what they may be looking for,
because so many possibilities exist for finding messages in call-stack
message queues. A new release of an OS may add new messages. Some messages
may percolate up to other call-stack message queues, others may not. A new
release of a Python script may add new messages. That pretty much forces
end users to literally read job logs, and figure out for themselves what
your program may be trying to tell them.

I mostly did not understand the above. I think the gist of it is just
expounding on the "IBM message queues are too confusing and
problematic" idea from earlier. I definitely do not know where the "a
new release of a Python script may add new messages" comment comes
from. I thought it was established that Python doesn't do SNDPGMMSG;
and if it did, then I would be the one who adds those new messages.

Have you considered just writing a program that can be called at relevant
points in the CLP, to return messages (if any) via return parms? Likewise
provide a program that can be called from Python, to generate messages? Let
the CLP developer decide how to pass them along to end-users?

I am lost regarding the above. Just completely lost. I can read all
the words you wrote. I cannot understand how to fit them together
coherently.

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.