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



Thanks everyone for the responses. Dave and Buck seemed to best
understand what I was after, though it's certainly also possible I
simply misunderstood the other responses.

The basic idea of using MONMSG to "catch" certain classes of *ESCAPE
exceptions, and then if necessary, distinguishing between subclasses
of those exceptions by using RCVMSG to inspect the preceding *DIAG
messages, is what I had figured out before bringing my question to
this list.

I probably didn't express it very well, but the part I was most
interested in finding out was how to make the original *ESCAPE show up
again, if it turns out I can't handle this subclass. Crucially, this
*ESCAPE should put the job into MSGW status, rather than ending the
job abnormally, if the MSGW status is what would have happened had I
not embarked upon my MONMSG in the first place.

(By "put the job into MSGW status" I mean another message shows up
like CPA0701.)

So, nobody mentioned it explicitly, probably because it's too obvious
to everyone who knows what they are doing, but after further
experimentation it seems that the key to this is to specify
TOPGMQ(*SAME) when issuing the SNDPGMMSG that repeats the originally
caught *ESCAPE message.

When I do this, it seems that I achieve what Dave was describing: I
can maintain most of the information in the original *ESCAPE message
(captured using RCVMSG), but the sender of this reissued message is
"myself" rather than the true originator. It finally dawned on me that
if the true originator was sending "me" the message in the first
place, then "I" have to be the recipient *again*, thus *SAME for
relationship, and * for call stack entry.

I still don't fully understand all the ramifications of the various
possible values that go into TOPGMQ, but the default and several other
things I tried either caused the job to end rather than wait, or
introduced other errors having to do with improper use of SNDPGMMSG
rather than reflecting the nature of the original error.

I also would not be at all surprised to find out I'm still doing it
wrong, or at least there's a lot more that I ought to be aware of. So
even though it seems like I found (close enough to) what I want, my
ears are still open.

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.