RE: Using RCVJRNE for replication process of specific tables with specific filters - how to monitor it ?

Hello Jean-Paul,

The RCVJRNE command completes normally when the current journal receiver is detached. Consequently, there is no exception message to monitor for. The exit program processing the journal entries received by the RCVJRNE command is explicitly informed by the command about the ending of the journal entry processing. This information is provided in the exit program's second parameter, where the second byte contains the value '3' at that point (when termination is caused by the current journal receiver being detached).

Rather than somehow passing this information back to the program running the RCVJRNE command - which would also be an option - I normally infer this situation being the case, if no exception is received when the RCVJRNE command ends. If an exception is returned, I handle that specific situation, and if not, I simply use the RTVJOBA command to check the current job's End Status (ENDSTS). If the job is currently being ended (controlled) I end the program and allow the job to complete, as requested.

If not, I assume that the normal completion of the RCVJRNE command was due to the current journal receiver being detached. I therefore update the RCVJRNE command parameters by means of the RTVJRNE command, which I'll use to retrieve the (now) current entry sequence number and journal receiver name. I then loop back to the RCVJRNE command again, and the journal entry processing will continue where it left off.

I normally use a user space to keep track of current journal entry sequence number as well as the qualified name of the current journal receiver (to handle a possible sequence number reset correctly). A data area would of course also work, but I prefer being able to address the storage location by a pointer in the exit program, rather than having to explicitly update a data area.

In order to simplify things, as a standard approach I specify all files for which to process journal entries on the RCVJRNE command, and make the exit program light weight in terms of only handing off the journal entries by writing the relevant data to either a file or a data queue. I then have specific jobs and/or programs/modules to perform the actual processing, all depending on the given volume of journal entries compared to the performance and scalability requirements that needs to be met.

If you want, I can send you some sample CL and RPG/IV code demonstrating the basics of what I have outlined above.

Cheers,
Carsten

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jean Paul DELPIRE
Sent: 27. februar 2017 10:44
To: midrange-l@xxxxxxxxxxxx
Subject: Using RCVJRNE for replication process of specific tables with specific filters - how to monitor it ?

Hello,

I would like to put in a place a never ending replication process with some filters to apply on a set of tables (3).
I have a problem with the rcvjrne command.
I have one exit program for each tables.
Each time a detach of the journal receiver occur my program stop.

What message(s) do I have to monitor in the cl program in order not to stop the process and not to miss any transactions ?
Do you advice to use a data area for storing the sequence number ?
This is an example of my cl program.

DCL VAR(&SEQ_NUMBER) TYPE(*DEC) LEN(10 0)
DEBUT: RTVDTAARA DTAARA(TMEVT_FAST) RTNVAR(&SEQ_NUMBER)
CHGVAR VAR(&SEQ_NUMBER) VALUE(&SEQ_NUMBER + 1)
RCVJRNE JRN(JRNDEV) EXITPGM(RCVTMEVT_1) FILE((TMEVT)) +
RCVRNG(*CURCHAIN) JRNCDE((R)) ENTTYP(PT PX UP +
DL) ENTFMT(*TYPE3) DELAY(*NEXTENT) +
FROMENT(&SEQ_NUMBER) TOENT(*NONE)
MONMSG MSGID(CPF7062 CPF7054) CMPDTA(*N) EXEC(DO)
RcvMsg MsgType( *EXCP ) Rmv( *YES ) */
GOTO CMDLBL(DEBUT)
ENDDO
ENDPGM

This communication is intended only for use by the addressee.It may contain confidential or privilegedinformation.
If you receive this communication unintentionally, please inform us immediately and delete this e-mail and any attachments.
Warning: Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept
responsibility for any loss or damage arising from the use of this email or attachments.