An update to a CA Datacom/DB record places it under secondary exclusive control until a LOGCP request is issued. For online users to wait for updates as little as possible, batch CA Ideal programs should release control by issuing CHECKPOINT statements as often as possible.
This means that you must write batch programs doing database updates so that they are restartable at each CHECKPOINT.
One of the easiest ways to do this is to first load the transaction records onto a CA Datacom/DB table. As each transaction record is successfully processed, a record confirming the successful update is written to another table, the transaction record is deleted, and a CHECKPOINT taken. Any transactions that fail are updated to show this or are transferred to a reject table.
If there is a system failure, you can simply rerun the programs using whatever transaction records remain in the table. These are all of the unprocessed transactions. You can back out any confirmation data from an incomplete update. Finally, you can use the confirmation data to produce a report of the run. Once the report is complete, the table can be cleared.
This method produces the report of the run from a confirmation table after doing the updates. This lets you restart the update without having to restart the report (a report is harder to restart because totals must be resumed, control breaks re‑established, and so on). It also lets you rerun the report, for example, if it is lost after production, without re‑updating the database.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|