Re: CLP logging level -- MIDRANGE-L


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 (toclear
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 messagethat
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 situationor
another.

There were no such assumptions in my examples. They monitoredspecifically for the object not found exception. The only way the codecould get to the section 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 Ipresumed you would have one because no-one in their right mind wouldnot--there are too many 'unexpected' things that can happen in anyprogram not to include a 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 possiblyCPF2176 if you've trashed QTEMP somehow). CPF2113 and CPF2114 couldoccur if the user space was in a real library. All the others indicateeither a coding defect (wrong name for object or library) or a systemerror and should be handled 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 thana

CPF) */

RCVMSG MSGTYPE(*LAST) /* Remove object deletedmessage 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 causesthe statement information to be logged in the job log message so youhave a better 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  / \
--------------------------------------------------------------------