Skip to end of metadata
Go to start of metadata

 

Purpose

In case you have update requests remaining on SM13 transaction, you may want to know what can be done with them.

Deletion of update requests

By default, updates which have finished successfully are deleted after execution has correctly ended. This is done due to parameter rdisp/vb_delete_after_execution (default value is 1), which determines whether update requests are deleted after they have been successfully executed. That means, that updates remaining on SM13 did not ended up correctly, due to different reasons.

What should be done with those updates?

1) Check with corresponding application team why did this update failed.

More information about the update failure can be found on Update Header (Goto > update Header):


Status information (in this case, Update was terminated) and UD Ret. Code (9 for this example) may be different, depending on the update “Status”.
Error details section provide deeper explanation about the root cause.

Involve application team to analyze the root cause for the update failure, and ensure it’s solved accordingly.
Once this step has been completed, what will happen to those updates remaining on SM13?

2) Can those updates be re-processed?

Refer to Note: 1510367 - Re-processing failed update records via SM13

Scenarios when "Repeat Update" is not possible: 

  • Update record with status "Error(no retry)" ("STOP" icon in SM13)
  • Update record with stauts "Stopped(no retry)" 
  • Update records generated from "Batch Input" or "CALL TRANSACTION" 
  • Update records with status "Error" and "Enqueue released"

In those cases, it’s needed to involve colleagues from application area to check what can be done with those pending updates. They cannot be re-processed from SM13.

Once all the relevant information has been collected; and root cause of the update failure has been identified; you may decide to delete those update requests remaining.

3) Can they be deleted?

Parameter rdisp/vbdelete

This parameter specifies the duration in days after which an update request is deleted. After this duration, has expired, the update requests are deleted irrespective of their status.
When the application server restarts, it checks all the update requests remaining older than parameter rdisp/vbdelete. Default value is 50; which means that remaining update requests will be deleted, if they are pending for more than 50 days, counting since server restart.

Delete updates manually from sm13

In case you need to delete those updates before those 50 days (by default) have passed, they can be manually deleted from SM13.
(Select the update request, then Menu Update Requests > Delete)

Report RSM13002 (DELETE set to X).

It can be scheduled in the background with the parameter DELETE = X, to avoid the update tables becoming too large. Or, it can be manually executed.


 

  • No labels