SAW for JAS Servers - SysErrs

Hi,

I found those errors as below in JAS log are related to the SysErrs, anyone know why those errors happened or any suggestion on this?

Any help would be greatly appreciated.

Thanks and Regards.

----
Problem executing function [F4116FSClearWorkfile] lib [COPBASE] TM_TRAN_CANCELLED was received from CallObject user:alex Env:JPD811
-----
Problem executing function [F4116FSEndDoc] lib [COPBASE] TM_TRAN_CANCELLED was received from CallObject user:alex Env:JPD811
----
Problem executing function [F0911FSEndDoc] lib [CFIN] TM_TRAN_CANCELLED was received from CallObject userenny Env:JPD811
-------
Problem executing function [F0411FSEndDoc] lib [CFIN] TM_TRAN_CANCELLED was received from CallObject userenny Env:JPD811
-----

We recently experienced the same error...upon troubleshooting, this is what I found the cause to be (in our particular setup).

The P4210 and a number of other programs were written to be a 'heads down' program. It was written with the idea that the users are entering data quickly, and then going onto the next entry. In order to facilitate this, certain business functions were written to be asynchronus - IE, the function is set off to complete in the background, while the user continues their data entry.

The problem that we experienced is that we get very few orders through hand-entry, most of it comes through automated processes. What was happening was that a user would enter one order, and then immediately hit the X-close/cancel button on the program once they entered their order. Since the business function is written to be asynch. the users is unaware that the order is still being processed in the background. When the user hits the 'X/Cancel' button, the system actually cancelled the transaction.

There are two possible fixes - you can ask a user to wait a period of time after they do their last order (or entry) before hitting the cancel/close button. The only problem with this is that you don't know how long to tell them to wait, as the amount of time for the entry to commit and come back is dependant upon the load of the system.

The fix that we used was that we flipped the business function(s) to be synchronus. What this did was make the user wait for the function to complete and come back before they could either enter another order or close the program. This was a perfect fix for us - but obviously would not be acceptable for businesses where they are entering lots of orders, for they would have to enter, wait...wait...then enter.

All of that said, can't say that you are having the same issue - but for giggles watch the users enter the data and see if they are cancelling out of the program fairly quickly after trying to commit the previous transaction..

John

John,

Was this happening on your web clients?