On 08-Jun-2017 08:50 -0600, Paul Roy wrote:
I have a request to automatically save detached journal receiver...
So I have used a watch on CPF7020 ..
this works OK but I only find half of the messages... I have
searched QSYSOPR and History Log and I can only find 1/2 message
for detached receivers...
Journal receivers RCV2234 and *N detached.
Journal receivers RCV2236 and *N detached.
Nothing for RCV2233, RCV2235, etc...
as per from the documentation there should be a CPF7020 for each
receiver... Is this a bug, Something that I misunderstand ?
someone using the same principle?
Is the journal setup system-managed or user-managed? If the former,
the detach may occur at IPL; would not explain the missing messages, not
directly, but the watch presumably is not active until after the IPL
completes and so that implementation already has a potential deficiency.?
In the past I have done similar, but rather than [the more recent
feature of] watches, by processing [IIRC, CPF7099 threshold; and
specifically documented for use with Change Journal (CHGJRN) to attach a
new receiver, and SAVOBJ to save the detached receiver] messages
directly from a specific Message Queue (MSGQ) that is defined as an
attribute of the journal object. I never had a situation [in those older
releases and that implementation] whereby an expected message was not sent.
If the msg CPF7020 gets sent to QSYSOPR, then [unless someone can and
does clear the message queue QHST,] the message that went to *SYSOPR
will be copied to the QHST* log files from the duplicate copy that was
sent to the QHST message queue.
I was under the impression that watches were processed directly by
the Message Handler (MH) feature, at the point of sending the message;
i.e. the MH feature knows the message has a watch, and processes that
watch immediately. If so, then the lack of a message having been sent by
the Journal (JO) feature would seem even more likely to be that the
message was never even sent; even the existence of another QSYSOPR or
QHST [outside of QSYS] message queue would not bypass that watch, even
if that invalid situation would prevent the message from being copied to
QHST. IIRC the QSYSOPR gets cleared during an IPL, but again, the QHST
should get the duplicate copy and the SCPF job that performs both the
IPL and history logging should get the entry from the message queue [as
temporary logging] into the database file [as permanent logging].
I would look for any other messages in the log, between the two
shown/quoted above, that reference the journal or the receiver RCV2235
to check if some other condition [e.g. CPF701A] might have been a reason
[, defect or not,] that the CPF7020 was not sent; DSPLOG for
MSGID(CPF7000 CPD70000 CPC7000 CPI7000 CPA7000) should include all of
the valid message ranges that might be expected to include the object
name [except perhaps /damage/ messages].
I wonder if maybe the change of the receiver occurred at IPL, and
there is something about the IPL [a defect] causing the message to not
be sent or to be lost [in effect]; reviewing all messages between the
two shown in the quoted text, for the text ' IPL', might be helpful, if
only to find the spooled *N/QSYS/SCPF joblog for the IPL in which the
CPF70## message(s) might have been logged despite not appearing in the
*SYSOPR MsgQ.
midrange.com
