×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.