Internal session terminated with a runtime error MESSAGE_TYPE_X

[former_member219179]

Hello PP Guru’s,

I have observed Update failures for different users in Production environment.

The updates got failed in the function module CO_FW_AFFW_POST with a runtime error MESSAGE_TYPE_X.

Unfortunately I am not able to get the transaction details for this update termination so that I need your guidance to resolve this issue.

From one of the dump I also observed error message - RU803.

I also got a reference SAP note: 323429 - MESSAGE_TYPE_X during goods movements from confirmations from SAP portal but I am not sure how to proceed on this problem.

Please let me know from the forum experts so that I can take it up with our technical team and analyze this issue further why system is throwing internal session terminated with a run time error MESSAGE_TYPE_X for the Function Module - CO_FW_AFFW_POST.

Revert back in case of any additional information required from my end.

Cheers,

Kumar S

[former_member184666]

Hi Kumar,

Refer the below threads with similar issue.

Thanks & Regards,

Ramagiri

[former_member219179]

Thanks Ramagiri for sharing the link.

Will discuss with ABAP & BASIS and get back to you.

Cheers,

Kumar S

[former_member209265]

Hi Kumar,

Yes. Just check whether a single order is being confirmed at the same time the goods movement is happening. This will create a system lock.

Better to take help of an ABAP person as this type of locking is little difficult to capture.

Regards,

Krishnendu.

[Caetano]

Hello

The problem with the error messages RU803 and RU805 is often related to

a locking situation in the update processes, when system is trying to

post goods movements during order confirmation. If the termination with

this dump occurs randomly and if you are able to post again without

dump, there is no problem.

The runtime error MESSAGE_TYPE_X occurs in the update task when the

system is trying to delete entries from table AFFW which have already

been deleted before. e.g. by another task that tried to process the

same AFFW records.

In general, this problem occurs only when the system performance is

very slow and therefore, the system has severe problems in updating

database tables. It isn't an incorrrect entry in database table AFFW,

but a performance problem of updating AFFW. Generally, the short dump

does not cause any subsequent problems or inconsistencies.

If, in transaction OPKB, if you have maintained parallel processors this

problem may arise. In that case, either you have to remove the parallel

processors or use a wait statement in the code if you are posting the

confirmation using BAPIs.

Please consider the following note, which contains relevant information:

- 577368: Deadlock due to blocked update processes

Please read it carefully note. This note has no code to implement, only

provides you some customizing settings.

In order to give recommendations, the relevant question is: How are the

confirmations posted? Is the confirmation posted using confirmation

BAPIs? If so, it is recommended to decouple the goods movements

completely according to note 208477 and use the setting "later in the

background job". This is recommended in general for confirmations by

BAPI or PDC, because this will avoid conflicts between goods movements

posted in the update task and goods movements posted by CORUPROC. As

regularly scheduled job for program CORUPROC will then take care of the

BR

Caetano

[former_member219179]

Hello Caetano,

Yes you are right !!!

We observed this week beginning in our production environment lot of performance issues. We also suspect after your input may be due to that we could able to get this update terminations in our system.

Thanks for your precise info that is “this short dump does not cause any subsequent problems or inconsistencies” because the same I have observed no major issues occurred in Production environment due to this dump.

Regarding transaction OPKB this is the current setting / config keys maintained in my system,

Identificator for confirmation process – “1(Post goods movements)”

Maximum number of work processes that can be used – “2”

Logon/Server Group Name – “Blank”

Maximum portion size for parallel processes – “0”

Application of confirmation process – “1 (PM/PP/PP-PI/PS)”

Time of confirmation procedure – “2 (later in background job)”

Can you please look at above config setting and suggest me whether I have maintained parallel processors or not? If not please provide your comments to proceed further.

Awaiting for your response.

Cheers,

Kumar S

[Caetano]

Hello Kumar

This setting for OPKB is correct. The confirmation will create requests for the goods movements and they will actually be posted later, when you run program CORUPROC (or transaction CO1P). That should avoid the short dump.

Please note that the process control from OPKB must be refered on the customizing transaction OPK4N, for the order type, so that it is effective.

BR

Caetano

[former_member209265]

Hi Kumar,

Not faced the error practically. Just check whether it is a problem of multiple access of the same table. Might be AFFW is being accessed by multiple users at the same time.

Regards,

Krishnendu.

[former_member219179]

Hello Krishnendu,

Thanks for your response.

Could you please elaborate in detail what you are referring to problem of multiple access of the same table AFFW.

My understanding to your response is that multiple users are trying to post confirmation hence this update termination appears is it?

Because when i discussed with some of the users they say there was issue with packing of materials in WM.But i am confused how this could related to table AFFW.

Please respond to my query.

Cheers,

Kumar.S