I have worked on systems where new Run Controls, whose IDs contain either a date or sequence number, are generated for each process. The result is that the Run Control tables, especially child tables, grow quickly and if not regularly managed will become very large. On one system, I found 18 million rows on one table!
RECNAME FIELDNAME NUM_ROWS BLOCKS --------------- ------------------ ---------- ---------- TL_RUN_CTRL_GRP RUN_CNTL_ID 18424536 126377 AEREQUESTPARM RUN_CNTL_ID 1742676 19280 AEREQUESTTBL RUN_CNTL_ID 333579 3271 XPQRYRUNPARM RUN_CNTL_ID 121337 1630 TL_TA_RUNCTL RUN_CNTL_ID 112920 622 …
I have written a simple Application Engine process, GFC_RC_ARCH, that purges old Run Controls from these tables. It can be downloaded from my website.
Run Control records are easily identified. They are characterised by:
- the first column of these tables is always OPRID, and the second is either RUNCNTLID or RUN_CNTL_ID,
- these two columns are also the first two columns of the unique key,
- the Run Control tables appear on pages of components that are declared as the process security component for that process.
I have chosen to make these two Application Engine processes mutually exclusive, so the Process Scheduler will not run both at the same time, but that configuration cannot be delivered in an Application Designer project.