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



rob wrote:

I've never been a big fan of default handlers. I'd rather the
program halt on the line in error. If the problem is such an
obscure error then often corrective action can be taken elsewhere
and an R to retry fits the bill nicely.

Now, a detailed MONMSG on a particular error is completely acceptable. By detailed I do not mean
DLTF (MYLIB/MYFILE)
MONMSG CPF0000

I mean
DLTF (MYLIB/MYFILE)
MONMSG CPF2105 /* File not found */

Suggesting that "the developers need to code a generic monitor for unexpected errors in the application, for which the handler effects desired notifications" does not imply that poor coding practices should be introduced. In the above example, the CPF0000 monitor has no _handler_ and thus misses my point. Consider this more appropriate coding to effect notification [while avoiding deferral to the language's default handler, because unexpected messages are being handled]:

QSYS/DLTF FILE(MYLIB/MYFILE) SYSTEM(*LCL) RVMCST(*REMOVE)
MONMSG CPF2105 EXEC(callsubr rmvexcp) /* Ignored expected msg */
MONMSG CPF9999 EXEC(DO) /* Enable DFTPGM() & DMPLST() */
/* optionally callsubr rmvexcp to rid of CPF9999 message */
/* optionally get msgkey from origin for *FC to pass on CALL */
CALL RULES/NOTIFY) /* Notify unexpected msg */
RETURN /* or ENDRQS or SNDPGMMSG *ESCAPE or ?? */
ENDDO /* CPF0000 could've been monitored instead */

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/monmg.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/dfthd.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/esmsg.htm

Specific versus generic monitoring is good coding practice. I agree that the generic monitor CPF000 for an action in order to ignore a failed condition is not only poor coding, I also consider that improperly coded. I also agree and prefer that when an error that is not directly and specifically monitored in my program [a condition either not originally considered or one presumed should /never/ occur], then the language's default inquiry handling is preferable. Preferable because that stops the program and inquires /on the line in error/, and best of all for its offering the opportunity to both correct the problem and then respond with R=Retry to have the program continue. All of that built-in handling, that I do not need to code myself.

Back to the reply list... Any default handling which does not effect a desirable result is an apparent coding error, because only the /desired result/ would meet the business rules. The OP suggested undesirable results were occurring:

>> Jerry Draper wrote:
>> Issue at this shop is that with the autoreply list set to
>> D)ump all RPG and CPA messages the developer group never
>> really knows when something fails unless the user says
>> something. No one actually reviews qsysopr message queue
>> so all looks fine and dandy.

The generic D=Dump reply being enabled via default System Reply List reply handling is in effect, a /default handler/. That is, the default action for an unhandled exception is to inquire but implicitly dump.

I was advocating enforcing what was an alluded business requirement from the OP, that the applications should effect some explicit notification of the error versus the default reply handling. Part of the implied requirement, was that the user should not be able to make the choice for handling errors, because it was made clear that the users already fail to report the Dump failures of the application; making them the arbiter of an inquiry is unlikely to change that behavior. And even another part of the implied requirement was that an operator is not to be expected to deal with inquiries nor reviews for failures, since there is no such entity.

So take the example where the program only handles CPF2105. When the condition is CPF3202 instead of the monitored CPF2105, the program would fail with CPF9999 without any coded /default handler/, and the language will intercept the condition by inquiring for CAP070#. Thus for not having coded any monitor for the unhandled exception, the application will be the victim of the inquiry reply handling; either a default reply from either the message or the system reply list, a user or operator response, or [unlikely] an exit program's programmed response. As I understand it, _we_ prefer that the inquiry handling is *RQD and we get the opportunity to deal with that.

However from the implied requirements from the OP, that is not the preference. That is, the requirements imply that inquiry handling is unacceptable because the users can not be trusted and there is no operator. For that, the application will need to be responsible for intercepting the unexpected messages, instead of the developer having allowed the language run-time from intercepting any of those unexpected messages. Thus the onus is on the developer of the application to code some handling which effects the desired notification. To achieve that, the developer could use the generic global monitor CPF0000 to enable that intercept. The EXEC(CALL RULES/ENFORCE) coded as the handler for the monitor enables ENFORCEment of the rules which require notification. This could even include an inquiry implementation that prevents cancellation by the user, for which resolution by almost anything short of ENDJOB will require that whomever was notified must investigate before the job is allowed to continue; not that I am imply such heavy-handedness is appropriate...

Note: A cancel handler can replace the global monitor, giving the capability to handle various attempts to cancel the program beyond just unmonitored errors.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.