Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

LUW logs in SM58 created even when the user is not active for days .

issabella_martin1995
Participant
0 Kudos

The issue has occurred in a C-Folder functionality , where we are getting more than 20,000 dumps a day from multiple user Ids. We have contacted the user to ask what actions are performed by them. None of them were using the system . Please find the ST22 dump details .

We are also having logs in SM58 . The status says "An exception has occurred "
when we tried to debug that log , the log vanishes from the queue . Is it a issue where the FM is over running by itself ??? What could be possible errors here? How can dumps and logs generate even when the user is not doing anything . Please note there is no background jobs here which can do so . Please help 😞

1 ACCEPTED SOLUTION

raymond_giuseppi
Active Contributor

As cleary stated in the dump, authorization failure triggered the error. When executing the FM yourself (debug mode) your user is authorized, so it will perform successfully.

NB: Did you already look for some background job that would periodically try to execute the tRFC in error? (Look for a program such as RSARFCEX)

4 REPLIES 4

raymond_giuseppi
Active Contributor

As cleary stated in the dump, authorization failure triggered the error. When executing the FM yourself (debug mode) your user is authorized, so it will perform successfully.

NB: Did you already look for some background job that would periodically try to execute the tRFC in error? (Look for a program such as RSARFCEX)

0 Kudos

Yes Raymond , we checked and found that the job is not causing nay error and this issue is coming from the last two days. We asked the user and he is saying that he hasn't even logged into the system then how come we have a dump with this ID . Like this many users are complaining .

There is an origin date (date of first FM execution, initial call of FM) in ARFCSSTATE table

But it's hidden in a technical field (ARFCRESERV, length 255) that you should map in a program (to an ARFCRESERV type structure) to get some human-readable data (subfields QDATE and QTIME)

NB: A background job calling report RSARFCEX won't dump or raise an error, as retry of FM call will be performed out of the job, else it would stop at first error...)

0 Kudos

I bow to your technical expertise. 🙂

Looking forward to your threads/replies/comments...religiously.

K.Kiran.