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
midrange.com
