Re: MONMSG question

[CRPence <CRPbottle@xxxxxxxxx>]

  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.