On one fine morning, faced with a problem which was resulted from the bad bad coding. Read on to walk through the events.

Problem

Update terminate while creating/changing the Sales Orders. Since it involves the core business, it was categorized as very high priority.

Update was terminating because of the Run-Time error. From checking the dump analysis, it is apparent that it is while generating the Specific output on the Sales Order. Since the output is “issue immediately on saving of transaction”, it was getting generated right away in the Update Task. That SmartForm was never touched in last few years. Next place to check for changes is the driver program – it is also not changed in last few years. Than how in the world it has started complaining. Dump analysis points to the parameter length mismatch in one of the parameter.

What happened which led to this Update Terminate

Driver program was created to call the SmartForm for outputs. Data is prepared in the driver program and sent to the SmartForm using the TABLES parameter. An internal table was created with a local TYPE declared in the program by Developer1. Since you can’t use the local type to define the SmartForm Interface, Developer1 has created a DDIC structure and used that structure to define a TABLES parameter using LIKE. This was performed in past. Everything was working ok in production.

A new project started to bring another business unit (BU) onto SAP system. The new BU also has a requirement to generate an output similar to other existing BUs on SAP. So, Developer2 copied the driver program and created a new SmartForm as it has a different format. Now, since he copied the same program, the local TYPE was also copied to this new program. SmartForms was designed and built, tested successfully and went to production with other code for the new BU. Everything worked well.

New requirement came along the way, to add a new field in the Form of the new BU. Developer3 started working on the Form. He figured out that he would need to add the field to local type in program2 and in the DDIC type used to reference the TABLE parameter in the SmartForm. Added Field, Tested for the BU, passed and moved to Production. And BOOM..! As soon as it moved to production, form developed for other BUs were dumping and generating the Update Terminate. No new Sales orders Manually or from EDI for the old BUs.

So, you must have figured out that where problem was. It was with the overall design but it was also with the latest changes. Due to the latest changes, the one for new BU, the old BUs were stopped working. The root cause is the field added to the DDIC structure. The local TYPE in the old driver program used for other BUs was never adjusted to have that field added to the local TYPE. Local Type of that driver program doesn’t match with DDIC structure and hence it ended up in Update Terminate.

Developer3 should have done where used to avoid this
Developer2 could have removed the local TYPE from the driver programs and referenced it with table
Developer1 could have used the DDIC to begin with

Lessons from the story

Here are the obvious lessons from this incidents:

• Don’t use different types to refer the variables used in the same program.
• Where used should be used more frequently than you might thought
• Outputs should be processed in Batch process so, it would at least record Business Transaction, if business agrees for it

PS – I referred developers as He, but there could be a She involved here.

Share your experience with Disaster Recovery

I’m sure you must have came across the these type of scenarios where you faced similar problems because of bad coding practice. I would like you to share your story. Please send it via Write a Post page.