SM13

[Former Member]

Hello, after a system crash may be many unfinished update records, which are visible in the tx SM13.

Someone may indicate what is the correct way to treat these records to finish well pending transactions once the system is again available?

In other words, there is a procedure to recover after a fall that is not erase records pending and ask the user to enter again movements they were doing at the time of the fall?

There are situations in which even tx tells the user the number of the document, but when you return the system occurs it is not recorded.

saludos,

[Former Member · Accepted solution]

Hello Oscar,

You need to process them on case to case. First try to re-update the incomplete updates shown in Sm13. The ones which cannot be updated need to deleted and the transaction needs to be repeated for them.

Regards.

Ruchit.

[Former Member]

Thanks Ruchit,

As we do not have experience in the use of tx SM13, I have some additional doubts, seems to me that this tx comprises of a "procedure of recovery", that is to say:

1. It is necessary to make this update without connected users?

2. How is complemented the SM13 with the SM12 for the handling of the blocked registries? There is some order that agrees to follow?

3. There are other transactions that we must consider?

If somebody could complement information it will be thankful. I think that this information can be useful to many peoples.

regards,

[Former Member]

Oscar,

Transaction SM13 is a management console for the Update Queue that is both pending, in-process, and failed in the System. Updates are processes that are passed here so the program doesn't have to worry or wait for them to finish - it is the responsibility of the Update process to complete the tasks independently of the calling process. To this effect, you can restart those processes that you see in here as they represent failed attempts to complete a task that was expected to have been completed.

The only areas of inconsistency would be users that entered the system directly after the crash and attempted to review their work and have re-entered the data that is pending in the update. So long as the data is the same, there will be no issue - if the user entered in new data and you are now running the Update afterwards - the change in the update will overwrite those already made. For this reason it is important to make sure that all the pending updates are addressed after the system is restored and before end-users are back in the system.

From the oldest first, restart those that you can and if there are a number that cannot be restarted, then I would have a functional person for the respective area that the udpates belong to in order to review the data in the Update and manually adjust the necessary information - after which you can delete the entry from the SM13 transaction tables.

In respect to SM12 - those transactions that failed to remove their entries should be manually removed after verifiing that the process is no longer present in the system (check on the process, userid of the lock object and if they still exist in the system). This is another item to address immediatly after the restore as part of clean-up. If you are un-sure of which locks need to be adjusted - if there is no real impact to operations, you can wait for a few days and those that are still present with an old creation time should be those that can be removed. If you can take a quick down-time restart that can also provide you with a reference point in which to identify orphaned locks.

Hopefully that answers your questions - if it does, please set this thread to answered, if not, please provide your additional requirements going forward to get your issues resolved.