Re: Trying to avoid dozens of MONMSG's -- MIDRANGE-L


On 27/07/2005, at 12:49 AM, rob@xxxxxxxxx wrote:

I have a CLP that does numerous lines like:
CHGAUT OBJ('/QSYS.LIB/PAIAVI81F.LIB/*') AUTL(SSA26F)

Occasionally I'll get a message (like on a new library with no filesyet).

CPFA093-Name matching pattern not found.

Instead of adding a LOT of MONMSG's I thought I'd try:
ADDRPYLE SEQNBR(9101) MSGID(CPFA093) RPY('I')
CHGJOBD JOBD(GDISYS/FIXSEC) INQMSGRPY(*SYSRPYL)

Interesting approach ... but so WRONG! You don't want to monitor forthe real exception but instead will let the system default exceptionhandler catch it and then you'll tell it to ignore the exception?That's as bad, if not worse, than the fools who avoid errors bysticking MONMSG CPF0000 as a global exception monitor with no EXECspecified.

First, yes you can get the above to work with a lot of messing aboutbut it's the wrong approach. I'll show you how to do this at the endsimply to prove it can be done.

Now, however, I get:
CPFA093-Name matching pattern not found.
CPA0701-CPFA093 received by FIXSECPAI at 124. (C D I R)

and it autoresponds with a 'D'. I figure it now autoresponds with a'D'

to the CPA0701 message because of the system reply list entry
Message
ID       Reply
CPA0700  D

How can I get it to use the 'I' on the CPFA093?


By:
        o Changing the default reply on the message
        o Overriding the message to one with the desired default reply

Or is this one of those cases where I should skip trying to use thesystem
reply list and just add a generic MONMSG CPFA093 to the top of these
CLP's?

That's a better approach but it's still ugly because there is no way tobranch to cleanup code and then cleanly return to where the erroroccurred.


        MONMSG CPFA093 /* Name matching pattern not found */

as a global exception monitor will cause the exception to be caught,handled, and your program will continue with the command following theone that caused the exception BUT it will leave the exception messagein the job log.


Just bite the bullet and stick:
        MONMSG CPFA093 EXEC(DO)
                RCVMSG MSGTYPE(*EXCP) /* Name matching pattern not found */
        ENDDO

after each CHGAUT command. That solves your problem and cleans messagesyou obviously don't care about from the job log at the expense ofduplicate exception handlers. Avoid the duplication by coding a looparound GRTAUT and change the path names on each iteration. You mighteven be able to use the ILE condition handler APIs to catch and cleanup the exception and return to to point after the error but I haven/ttried those from CL or CLLE.

Now, how to make your original attempt work. Add the following at thestart of your CL program:


        CRTMSGF QTEMP/MYCPFMSG
        MRGMSGF FROMMSGF(QCPFMSG) TOMSGF(QTEMP/MYCPFMSG) SELECT(CPA0701)
        CHGMSGD CPA0701 MSGF(QTEMP/MYCPFMSG) DFT('I')
        OVRMSGF QCPFMSG QTEMP/MYCPFMSG

then do the mucking about with changing the job to use the reply listetc.


Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------