- Starting V2 updating
- Deleting successfully executed update requests
- Reorganizing the update tables
- Deleting old update requests
Starting V2 update
Normally, V2 updating starts directly after V1 updating. You can useparameter rdisp/vb_v2_start =2 to change this. A reason for changingcould be performance bottlenecks during daily operation. To startjammed V2 updates, start RSM13002 with the parameter STARTV2 = 'X'.
If V2 is not updated directly, the update should be started as often aspossible (several times a day). Otherwise, the update tables can getvery large.
Deleting successfully executed update requests
Normally, uodate requests are deleted after they have been successfullyexecuted. However, this can cause performance bottlenecks. To solvethis, you can switch off the delete function using parameterrdisp/vb_delete_after_execution =2. In order to delete, then, you mustrun RSM13002 every so often, using parameter DELETE = 'X'.
If deletion is not carried out directly, it should be carried out asoften as possible (several times a day).
Reorganizing the update tables
If transactions in progress are terminated, this can lead to incompleteupdate requests in the update tables. To delete these, start RSM13002every so often, using parameter REORG = 'X'.
A reorganization of the update tables is only occasionally necessary(once a day is sufficient).
Deleting old update requests
Terminated update requests are only retained for a limited period oftime. The parameter rdisp/vbdelete shows the maximum period in days.Old update requests are deleted when the update server is started.Report RSM13002 and parameter DELOLD = 'X can also be used to deleteold update requests.
Only incorrect update requests are not automatically deleted.Therefore, it is sufficient to delete old update requests once a week.