Re: CLP logging level -- MIDRANGE-L

I learn something new every day - CPF9999, eh?

Of course, there's always more than one way to do it (the PERL motto -TMTOWTDI). When using CPF0000, I like using, in the global handler, themessage handling APIs to get the recent diagnostics, as well as resendingthe last exception. This is cleaner than doing a bunch of RCVMSG commands.It uses QMHMOVPM & QMHRSNEM to do the job - here's some sample code, basedon a "using APIs" book--


DCL        VAR(&MSGKEY) TYPE(*CHAR) LEN(4)
DCL        VAR(&MSGTYP) TYPE(*CHAR) LEN(10) VALUE('*DIAG')
DCL        VAR(&NBRTYP) TYPE(*CHAR) LEN(4) VALUE(x'00000001')
DCL        VAR(&PGMMSGQ) TYPE(*CHAR) LEN(10) VALUE('*')
DCL        VAR(&STKCTR) TYPE(*CHAR) LEN(4) VALUE(x'00000001')
DCL        VAR(&ERRCODE) TYPE(*CHAR) LEN(8) VALUE(x'0000000000000000')

/* Send all errors to error handling routine */
MONMSG     MSGID(CPF0000) EXEC(GOTO ERROR)

/* your program code goes here */

ERROR:
/* Move all *DIAG messages to previous program queue*/
CALL       PGM(QMHMOVPM) PARM(&MSGKEY &MSGTYP &NBRTYP +
             &PGMMSGQ &STKCTR &ERRCODE)

/* Resend last *ESCAPE message */
CALL       PGM(QMHRSNEM) PARM(&MSGKEY &ERRCODE)


At 06:50 PM 7/27/2005, you wrote:

On 26/07/2005, at 1:19 AM, rob@xxxxxxxxx wrote:
If I was to leave it in one process then I would really have to think
about it.  Assuming that I always want to delete the user space (to clear
out old data if there is any).
A properly written user space application will not process old data sothere is no real reason to delete an existing space--just reuse it.
I'd want to monmsg the DLTUSRSPC to remove
the message if it wasn't there.  I'd also want to remove the message that
said it was deleted if it was.  But I'd not want to remove any other
messages (however doubtful they are for objects in QTEMP).  I just hate
assuming that if something doesn't work it's because of one situation or
another.
There were no such assumptions in my examples. They monitored specificallyfor the object not found exception. The only way the code could get to thesection to remove the completion message was if:
        a) No error occurred
        b) The only error was object not found
In the examples I did not show a global exception monitor but I presumedyou would have one because no-one in their right mind would not--there aretoo many 'unexpected' things that can happen in any program not to includea generic exception handler.
The only expected things that can go wrong with DLTUSRSPC are:
        1) Authority problem (CPF2182 and CPF2189)
        2) Object not available (CPF2113 and CPF2114)
        3) Existence problem (CPF2105 and CPF2110)
        4) Damage to the library (CPF2176)
        5) Errors on objects satisfying a generic name (CPF2117 and CPF2125)
Of these the only likely one in your case is CPF2105 (and possibly CPF2176if you've trashed QTEMP somehow). CPF2113 and CPF2114 could occur if theuser space was in a real library. All the others indicate either a codingdefect (wrong name for object or library) or a system error and should behandled by a global exception monitor.
Perhaps that could be done by something like:
                 DLTUSRPSC lib/space
                 MONMSG CPF2105 EXEC(DO)
                                 RCVMSG MSGTYPE(*EXCP) /* Not found */
                         ENDDO
                 MONMSG CPF0000 EXEC(GOTO OHCRUD)
             /* Object was deleted (unless we got a message other than a
CPF) */
                 RCVMSG MSGTYPE(*LAST) /* Remove object deleted message to
declutter joblog */
...
OHCRUD:
...
Ok, then you'd be much better served by:

        MONMSG CPF9999 *N GOTO FAILED /* Global exception handler */
...
        DLTUSRSPC lib/space
        MONMSG CPF2105 *N DO
                RCVMSG MSGTYPE(*EXCP) /* Not found */
        ENDDO

        RCVMSG MSGTYPE(*LAST)   /* Object deleted */
...
FAILED:         STDERR  TYPE(*CLP)
...
A global default exception handler is better than jumps throughout thecode caused by MONMSG CPF0000 EXEC(GOTO OHCRUD) and it's much cleaner.CPF9999 as a global monitor is better than CPF0000 because it causes thestatement information to be logged in the job log message so you have abetter idea of where the error occurred.
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  / \
--------------------------------------------------------------------


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.