Re: MONMSG question

Should we infer the problem, an obviously illogical effect, persists?

FWiW the effect could reflect an abnormal [logical or data damage] condition with the Data Queue object. That is, a condition for which the generic object /touch/ of only the LIC header rather than the "data portion" of the object will not experience an error, but an attempt to actually /use/ the object will experience a failure. The API needs to be able to utilize effectively the full capability of the object, including the data portion, because that request is to add a message\entry to the queue. It is possible that the notification of a LIC condition as a LIC exception, is manifest in a manner which causes the QSNDDTAQ to "accidentally" diagnose that condition as CPF9801; that would be a likely outcome, for a MCH3402. If so, a trace would expose that [maybe only as an INTXHINV; i.e. the exception may not be visible with "data" in the trace record], and a DMPOBJ might also manifest an indication of the same issue. There is also the more mundane potential that the *DTAQ object is a DDM data queue and the error is diagnosing that the target object is missing; I do not recall enough about those objects to recall if that would make sense with what was given in\by the OP.

Regards, Chuck

On 20 Jun 2012 06:59, Smith, Mike wrote:

Ah, nice catch. So as for the code:

<<SNIP and edit>>
EOFAUT:
GRTOBJAUT OBJ(&LIB/&ATFILE) OBJTYPE(&TYPE) +
USER(*PUBLIC) AUT(*EXCLUDE) /* This works fine */
NOCHG:
CHKOBJ &QUELIB/&QUENAME *DTAQ /* This works fine */
MONMSG CPF9801 EXEC(GOTO EXIT) /* no *EXCP; cont. to CALL */
CALL QSNDDTAQ (&QUENAME &QUELIB &DTALEN &DATA)
/* Above failed msgCPF9801 F/QSNDDTAQ x/03B0 T/thisPgm */

Notice, the variable names are the same for both. Guess that's why
the CHKOBJ was coded just before the call to the API.

On 19 Jun 2012 15:18, Robert Houts wrote:

Notice that in the job log the message CPF9801 is being sent by
program QSNDDTAQ, so what seems to be happening is that whatever
value is in &NAME is not the same value that is being passed on the
call to QSNDDTAQ. As you are not showing us these parameters, I can
only guess. But it is clear that the error is being issued from the
API and not the CHKOBJ.