Resolving Qlik Task Failure Due to CURCHAIN Receiver Limit in DB2 iSeries

[aarun_arasu]

Issue:

Qlik data replication tasks from DB2 iSeries can fail due to communication errors with the source system. A common cause is that log stream tasks fail to resume because the CURCHAIN journal receiver has exceeded its connection limit. Below are the details of this issue and recommended solutions.

Scenario:

A log stream task configured with the Advance Run option, starting from a specific timestamp, failed and returned the following error:

SELECT journal_code, journal_entry_type, sequence_number, commit_cycle, entry_timestamp, object, cast(null_value_indicators as VARBINARY(8000)) null_value_indicators, count_or_rrn, receiver_library, receiver_name, "CURRENT_USER", job_name, program_name, cast(entry_data as VARBINARY(32740)) entry_data FROM TABLE(qlikudtf.qlikrje01_fnc(JrnLIB=>'$$JRN01',JrnNAME=>'DJ010A', RcvLib=>'*CURLIB',RcvName=>'*CURCHAIN', StrTimStmp=>'2024-10-03 05:32:49', JrnCodes=>'CDFRJ', JrnEntryTypes=>'PT,PX,UB,UP,DL,DR,BR,UR,CG,DF,SC,CM,CR,RB,FN,PR', numRows=>'10000', rcvLen=>'4194304', Files=>'F03B11 PDDTA')) AS J

The system logged this error message:

00051632: 2024-10-03T01:39:19:495841 [SOURCE_CAPTURE] Failed to execute the Qlik UDTF. At least one of the captured tables might be exclusively locked. [1022511] (db2i_endpoint_capture.c:1643)

Troubleshooting Findings:

• Behavior When Resuming from Timestamp: When a task is resumed using a specific timestamp, the system references the journal receiver library *CURLIB and the receiver name *CURCHAIN.

  The following warnings were observed:

  00051632: 2024-10-03T01:39:14:491526 [SOURCE_CAPTURE] Execute status=1022502, native=-443 (db2i_endpoint_capture.c:1602) 00051632: 2024-10-03T01:39:14:491526 [SOURCE_CAPTURE] Execute status=1022511, native=-502 (db2i_endpoint_capture.c:1602)

 

Root Cause:

The CURCHAIN journal receiver has a connection limit (in this case, 1024 connections). When the environment exceeds this limit, the task fails if it attempts to resume from a timestamp.

However, if the task is resumed normally (without a timestamp), the system reads from a different receiver name, bypassing the CURCHAIN limit, and the task runs successfully.

Resolution:

To resolve the issue:

• Monitor Journal Receiver Chains: Regularly monitor the journal receiver chain to ensure that connection limits are not exceeded.
• Receiver Management: Implement a cleanup mechanism to detach old or unused journal receivers.
• Increase Connection Limits: If the environment requires it, consider increasing the CURCHAIN connection limit to allow for more connections during data replication processes.