Message Received, But Not Understood

Published: November 18, 2009

Hey, Ted:

I had a problem last week. I was monitoring for error messages after an Add Physical File Member (ADDPFM) command in a CL program. Well, OS/400 sent two CPF messages when ADDPFM failed. MONMSG would only trap the second message, but I wanted to trap the first one because that's the one that tells me what went wrong. What do I need to do?

--Chris

This seems like a good time to review some messaging fundamentals. Chris is not a newbie programmer, so if he doesn't understand, there are probably others who don't understand either.

When a CL command fails, it often sends more than one message. All messages except the last one are diagnostic messages. Their purpose is to provide more information about the error. The last message is an escape message. Its role is to notify the caller that the command failed, but it may also, like the diagnostic messages, impart information about the error.

For example, if ADDPFM tries to add a member, but the file already has the maximum number of members, the system sends two messages: diagnostic message CPF3213 (Members for file DOGPOUND more than maximum allowed); and escape message CPF7306 (Member PHIDEAUX not added to file DOGPOUND in THEBIGCITY).

Likewise, if ADDPFM tries to add a member that already exists, the system sends two messages: diagnostic message CPF5812 (Member PHIDEAUX already exists in file DOGPOUND in library THEBIGCITY); and escape message CPF7306 (Member PHIDEAUX not added to file DOGPOUND in THEBIGCITY).

Notice that the same escape message is sent in both instances.

Chris wanted his program to determine why the ADDPFM command failed so that his program could pursue different courses of action according to the cause of the failure. The escape message, the only one he could monitor for, told him only that the command failed. The reason why it failed was in the diagnostic message.

It is necessary to use the Receive Message (RCVMSG) command to get the diagnostic message. The following example shows one way to achieve this goal.

PGM        PARM(&MBR)

   DCL        VAR(&MBR)        TYPE(*CHAR) LEN(10)
   DCL        VAR(&ERRORMSGID) TYPE(*CHAR) LEN( 7)
   DCL        VAR(&MSGTYPE)    TYPE(*CHAR) LEN( 2)

   ADDPFM     FILE(DOGPOUND) MBR(&MBR)
   MONMSG     MSGID(CPF7306) EXEC(DO)

      RCVMSG     MSGTYPE(*LAST) RMV(*YES) MSGID(&ERRORMSGID) +
                          RTNTYPE(&MSGTYPE) /* escape msg */
      RCVMSG     MSGTYPE(*LAST) RMV(*YES) MSGID(&ERRORMSGID) +
                          RTNTYPE(&MSGTYPE) /* diagnostic msg */

      IF         COND(&MSGTYPE *NE '02') THEN(DO)
         /* Do something here; the last message should have */
         /* been a diagnostic message, but it wasn't.   */
         CHGVAR     VAR(&ERRORMSGID) VALUE(' ')
      ENDDO

      SELECT
         WHEN       COND(&ERRORMSGID *EQ 'CPF5812') THEN(DO)
            /* The dog is already there */
            /* Do something */
         ENDDO
         WHEN       COND(&ERRORMSGID *EQ 'CPF3213') THEN(DO)
            /* The pound is full; no room for one more */
            /* Do something */
         ENDDO
         OTHERWISE  CMD(DO)
            /* Something else went wrong */
            /* Do something */
         ENDDO
      ENDSELECT

   ENDDO

ENDPGM

The MONMSG kicks in when the ADDPFM fails. The first RCVMSG retrieves the last message that was sent to the program message queue, which is the escape message, CPF7306. The second RCVMSG retrieves the message before that, which should be the diagnostic message. I've included an IF that verifies that the message was a diagnostic message (message type 02), just in case, because I'm the epitome of conservatism.

Besides retrieving the message type, the second RCVMSG command also retrieves the message ID. This is the information that Chris wanted, the one he needs in order to decide how to proceed.

--Ted

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot