Getting message DC980227 RPI CADSIF06 DEADLOCK
Article ID: 23175
Updated On:
Products
Issue/Introduction
I just migrated to Dispatch r11.7 and now receiving a lot of the following messages:
DC980227 RPI1 CADSIF06 Recovering From Database Deadlock
These messages most often appear when sites have many reports with the same reportname/jobname (and even the same recipient names sometimes) AND they are being processed at the same time by two or three RPI tasks.
The messages do not indicate an error, just that it needed to recover from a deadlock situation.
This document provides a scenario to get back to a correct implementation and prevent the deadlock situation from occurring.
Cause
With Dispatch r11 and subsequent releases, it is possible to run with up to three separate RPI tasks.
However these three RPI tasks should not be processing the SAME class/destination combinations or deadlocks are likely to occur under specific conditions when sites have many reports with the same reportname/jobname (and even the same recipient names sometimes) AND they are being processed at the same time by two or three RPI tasks.
Resolution
Message DC980227 does not indicate an error, just that Dispatch needed to recover from a deadlock situation.
However, running multiple RPI tasks might help to improve the throughput; just make sure the RPI tasks are defined so that they use class/destination combinations, which could be using the same class, different destinations, for example.
In the text that follows, the x in SPLx represents the unique suffix for the CADDSPL task.
To determine the current RPI configuration, enter command F SPLx,STAT; it should display information like:
Task Class Dest RPI1 M DEST1 RPI2 M DEST1 RPI3 M DEST1
and the VSGMU105 SYSGEN screen (option 9.0) should look like:
VSGMU105---------- Dedicated Sysout Control Information Screen COMMAND ==>
Distribution Input Options:
Class Dest Report Input: Input Task 1 (RPI1): ==> M DEST1 Input Task 2 (RPI2): ==> M DEST1 Input Task 3 (RPI3): ==> M DEST1
Assuming that the only criteria for Dispatch to process a report is that the report is spooled out as CLASS=M and DESTINATION=DEST1, only one RPI subtask should be running.
The RPI2 and RPI3 tasks should be deleted from CADDSPL and no longer run or started unless a new and unique report processing class/destination is established.
To that end, access the VOPMI100 screen (option 8.1 from the main menu). Turn off dynamic intercept for any tasks that have intercept ON (turn off by typing an 'I' next to that task).
After turning the intercepts off, end the RPI1, RPI2, RPI3, SAPIRPI1, SAPIRPI2 and SAPIRPI3 tasks by typing an E next to them.
The status of these tasks should be NOT ACTIVE OFF.
Then issue CADDSPL operator commands to update the RPI2 and RPI3 tasks from CADDSPL:
If you wish to update the RPI2 task with a different class/destination:
F SPLx,ADD RPI2,CLASS=M,DEST=DEST2
CADD650I SPLx Adding/Updating Class/Dest information for RPI2
CADD651I SPLx Class/Dest information stored into CADDSPLx
The following command will delete the RPI3 task from CADDSPL:
F SPLx,DEL RPI3
CADD110I SPLx Operator=DEL RPI3 CADD652I SPLx Removing Class/Dest information for RPI3 CADD008I SPLx RPI3 Class M Dest DEST1 has been deleted CADD653I SPLx Class/Dest information removed from CADDSPLx
Then check with F SPLx,STAT the changes are effective.
Once the RPI2 and RPI3 tasks have been updated from CADDSPL, go back into Dispatch and update the definitions for CLASS M next to the RPI2 and RPI3 tasks on the VSGMU105 screen to match the changes:
VSGMU105---------- Dedicated Sysout Control COMMAND ==>
Distribution Input Options:
Class Dest Report Input: Input Task 1 (RPI1): ==> M DEST1 Input Task 2 (RPI2): ==> M DEST2 Input Task 3 (RPI3): ==>
If these two tasks are automatically started, do not forget to update the DSSTARnn startup member and update the corresponding start commands. Then go back to the VOPMI100 screen and turn the needed RPIx and SAPIRPIx tasks back on.
Feedback
