Error in changing table EASTL

[Former Member]

there is a job which is getting failed and the log shows error E9016 " Error in changing table EASTL". I found out that there is a FM being used ISU_S_DEVICERATE_CHANGE  under which ISU_DB_EASTL_UPDATE is being called and it updates the table EASTL and failing which it throws error. I tried to put COMMIT AND WAIT but it still fails. Can you please help me on this, also it fails for different point of delivery every time and even after reshecduling it fails for different point of delivery.

[Private_Member_7726]

Hi,

I see nothing of interest in SAP OSS. What is your IS-U Release and SP level?

Is there perhaps some other useful information in the "log"?

If it's not IS-U standard program running in that job, you'll just have to debug it. You could try to post source code, but I doubt SCN would be able to simply guess the source of the problem. With code, one can at least verify, that there are no obvious problems prior to calling CHANGE function (like EXCEPTIONS checked after PROVIDE call, etc.).

cheers

Jānis

[Former Member]

Hi Jānis,

It's not a IS-U standard program, and i tried to debug the job with jdbg tcode but it gets successfully executed every time hence cannot identify the cause of error.

[Private_Member_7726]

Is the ISU_S_DEVICERATE_PROVIDE used in  the program?

What update mode is being used (X_UPD_ONLINE = 'X' ?)

Please post at least the relevant code...

Welcome to the world of integration problems arising out of the use of SAP internal APIs one should not have been using in the first place...

cheers

Jānis

[Former Member]

Hi Janis,

Yes the FM is being used in the program. As per your request please find the attachment.

Thanks,

Abhishek

[Private_Member_7726]

Are the exceptions properly checked and processed - in both calls?

What does the error processing look like?

What is the program actually trying to change?

All this is pure guesswork... Is the function group even capable of processing multiple API calls in one internal session..? Or in other words: is ISU_O_DEVICERATE_CLOSE cleaning the internal state of function group properly..? What happens when exceptions are raised - do the functions clean the state of function group themselves..? Always? Or does the caller need to take care of it? No documentation, nothing...

[nishantbansal91]

Hi Abhishek,

You have to check why the update or modify statement fails,

there is no need to mention the commit work inside standard code.

Thanks

Nishant

[Former Member]

Hi Nishant,

The commit and wait was put after the FM. I tried to debug it but it runs in debug mode everytime but fails as a background job

[nishantbansal91]

Dear Abhisek,

Sometimes it happens, i think there must be issue for the wait statement.

Suppose there is one database table TAB1. has an dependency of tab2.

modify tab.

modify tab1 " if entry exist in table tab.

so in debug mode when you are debugging system get time to update the tab table and your program run successfully. but in background mode tab table is still in update process and tab1 is statement is  executed.

I have faced the same issue 2 years backs.

So for checking this put the break-point ISU_DB_EASTL_UPDATE  after this FM . First time its not executed .

run second time put the breakpoint before ISU_DB_EASTL_UPDATE  then it will execute.

Thanks

Nishant

[Former Member]

Hi NIshant,

I found that ISU_DB_EASTL_UPDATE is being called under ISU_S_DEVICERATE_CHANGE . If according to you isse is with wait statement should delay of few seconds fix this? How did you fix your code then?

[nishantbansal91]

Hi Abhishek,

In my case I have used 2 bapi in custom program. The dependencies of second based on first input.

Sometime it was stuck due to that issue(Not everytime). It took 10 days to understand what is the issue.

So I have used wait for 5 second in my custom program.

Please confirm the issue is same or it's different.

You have to do enhancement in code.

Thanks

Nishant

[Former Member]

Yes its same issue, the job started to fail recently and when i try to restart the job it fails for different POD, but in foreground it works perfectly. There is a custom table which also gets updated along with standard one. Hence there is dependency as u explained earlier.

[nishantbansal91]

Hi,

Is this is the standard program.

Can you please paste the code in sequence manner.

Thanks

Nishant

[Former Member]

Hi Abhishek,

Please check the parameter passed. Also if there is any sort of update.modify.

Thanks,

Swet

[Former Member]

Hi ,

Thanks everyone for ur comments, The issue is resolved nw. The internal table was not getting refreshed and hence incorrect serial number was passed resulting in invalid exception.

Thank you.