× 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 02-Sep-2015 13:31 -0600, James Rich wrote:
We want to send an email if our nightly closing/backup stops on any kind
of error. I thought about monitoring for CPF0000 but I think that will
prevent the job from stopping with a MSGW. I still want the job to stop
with MSGW on the line where the error occurred, I just need some
facility to notice that a MSGW condition exists and send an email. Any
suggestions?


The job could be established with an option to force a reply via the Inquiry Message Reply Handling (INQMSGRPY) parameter specification [i.e. *DFT or *SYSRPYL if the inquired condition is represented], along with a user-exit program that could be defined for the Reply Handling Exit. The exit-program could, I expect, be coded to send the email [and if necessary, also to reset the handling to Required (*RQD) from whatever was the original InqMsgRpy setting] and then reject that reply value, which should then "cause the inquiry message to be left as unanswered" and thus presumably the job remains in MSGW for the original inquiry message?

Because according to the docs the "original reply will be sent" if the reply gets replaced, and the value of the "original reply" would be what was determined per the original INQMSGRPY setting, a more complex alternative would be for the user-exit to send an inquiry in place of the one provided by the Default Handler for the HLL, and await a reply; an inquiry reply for that inquiry message would want the exit program to recognize that condition of recursion. The program is thus still pending at the original MSGW, even though there is an additional stack entry since also awaiting a reply. So as to be able to override the reply for the earlier invocation, the exit program would want to know how to accept the desired value for the reply-value replacement; if for example the *DFT handling were originally chosen and the default for CPA0701 were 'C' but the desired replacement is 'R', the system would have determined that 'C' should be sent unless the exit program replaces that "original reply" value.

[http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/XREPLY.htm]
_Reply Handling Exit Program_
"...
Exit Point Name: QIBM_QMH_REPLY_INQ

Exit Point Format Name: RPYI0100

..."


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.