How to solve dump LOAD_VERSION_LOST and dump LOAD_PROGRAM_LOST

This has been an issues very common in the SAP Circle where the dumps occurs whenever user_exit being changed or a new program being transported to production system.

Normally the solution is the revert to old program and fix the program if there are quick fix. However there are SAP notes clearly defining steps on how to resolve such issues , another method is to clear the dialog buffer or sometimes of there are no programs changed the always SAP system being restarted instead of wasting enormousness time in resolving such issues.

SAP Note : 2385919 - How to solve dump LOAD_VERSION_LOST and dump LOAD_PROGRAM_LOST

However below are some steps of my own, lets see if it works for you.

You must ensure that the programme load is loaded in the programme buffer before you can run an ABAP programme (PXA).

When you run a programme load, this is locked to prevent it from being relocated from the buffer.

The programme locks may not be kept for extended wait durations because the programme buffer is restricted in capacity (for example, user interaction). As a result, during the deployment, all previously configured locks are freed.

The programme load may be moved from the buffer after a short time if the system works actively on the application server.

If you now alter the programme before the application continues (for example, due of a transport), the database identifies that the programme has changed (the total time stamp is newer) when you reload the programme (RELOAD).

The system prompts the brief dump " LOAD PROGRAM LOST" to avoid inconsistencies when executing the programme (the programme may have changed so significantly that follow-on issues occur).

You must not alter the software that has been terminated.

This can also be caused by changing a dependant object.

The report RSDEPEND can be used to determine when the programme was last created and which change caused the total time stamp to be set. This could be the case, for example, if the DDIC types or programme inclusions used have changed.

Search the RSDEPEND result list for objects with the same or similar time stamp as the total time stamp. This method makes it simple to locate the trigger. These dependent objects were then updated using either a transport or a direct system change.

If the short dump occurs frequently, you should take steps to reduce the likelihood of it happening again.

Increase the programme buffer to prevent any further swaps.

Make sure you only import transports when there is no or a minimal load. Especially in a manufacturing environment.