Find original calling program or transaction...

[Former Member]

Hello,

I want to keep a User-exit from running when it is ran from LT23, but I want it to work from LT11. The problem is when the function to confirm the TO is executed in LT23, it does a call transaction to LT11.

So, in the user-exit SY-TCODE has LT11 in it.

I have tried using SYSTEM_CALLSTACK and the first program in there is the initiating program for LT11, SAPML03T.

So, does anyone know a way to be able to find that either LT23 or the program RLLT2300, was the calling program for the CALL Transaction to LT11?

Any help would be greatly appreciated.

Thanks,

Rocky

[RichHeilman]

Interesting. The only way that I can think of off the top of my head is to have a "Z" version of LT23 and hence a "Z" version of the program behind it. Just before calling the transaction LT11, set some flag in a memeory id using the EXPORT statement. Then in the user exit, IMPORT that flag, if the value is set, then exit out of the user exit.

In the "Z" version of LT23.

data: flag(1) type c.
flag = 'X'.
EXPORT flag to MEMORY ID 'WHATEVER'.

In the user exit function module.

IMPORT flag FROM MEMORY ID 'WHATEVER'.
if flag = 'X'.
exit.
endif.

Probably not the best way, but can't think of anything else right now.

Welcome to SDN. Please remember to award points for any helpful answers that you might receive. Thanks.

Regards,

Rich Heilman

[Former Member]

Yeah, I had thought of that too. I was hoping to be able to find some trick that I didn't know about to be able to do this. But thanks.

Rocky

[RichHeilman]

I guess, another alternative, would be to write a wrapper program for LT23. This way you won't have to alter the standard sap program.

report Zwrapper_lt23.

data: flag(1) type c.

start-of-selection.


flag = 'X'.
EXPORT flag to MEMORY ID 'WHATEVER'.

submit RLLT2300 via selection-screen and return.

Again, do the IMPORT in your user exit function module.

Regards,

Rich Heilman

[Former Member]

Thanks again, definitely another good suggestion. I'm guessing there isn't going to be anyway of getting it from the system.

I will have to propose one of these options to my functional people, and see what they think.

Thanks,

Rocky

[guillaume-hrc]

Did you try to use the SY-CPROG ?

I don't know if you are familiar with it, but it contains the name of the main program. I may be relevant in your case.

Hope it helps!

Cheers,

Guillaume

[RichHeilman]

The only other thing would be to try to access a global field of the RLLT2300 program in your function module. You know that you can do this via field-symbols.

In your user exit....

CONSTANTS: c_program_variable (30) TYPE C VALUE ‘(RLLT2300)some_global_variable’.

field-symbols: <fs1>.

ASSIGN ( c_program_variable ) to <fs1>. 

If sy-subrc  = 0.
* You have gained access to this field
* and hence you need to exit the user exit
EXIT.
ENDIF.

I have done something like this before, but not to this extent.

I was going to suggest checking SY-CPROG, but I was thinking that it would have the name of the LT11 program.

It's worth a try!!!

Regards,

Rich Heilman

Message was edited by: Rich Heilman

[Former Member]

I tried this, but unfortunately after the call transaction sy-cprog had the main program for LT11 in it. Thanks though.

[Former Member]

Rich,

I think I will try that. Thank you so much for your help. Actually I did not know about that technique, so I will try it in the morning.

Thanks you so much,

Rocky

[Former Member]

Looks like LT23 is a ALV list and LT11 is called on one of several user commands possible there in this list. Have you checked the content of the SY-UCOMM? Looks like when the user command in the ALV is 'QUIH', it is calling LT11. See if the UCOMM is still available to you as it is and is different from that you would have gotten if you executed LT11 directly.

Srinivas

[Former Member]

Rich,

Ended up the assign failed even when I would run it from LT23. It doesn't see any of the variable defined in LT23. I tested to make sure I was doing it correctly by taking a varible from the main program of LT11, and that worked with the assign. So, I think I am just going to have to do the wrapper program. Thank you so much for your help though.

Rocky

[RichHeilman]

That's a shame that the "field symbol" thing didn't work. I was really hoping that it would. Anyway, glad to help out.

Regards,

Rich Heilman

[Former Member]

Well, I have found a new wrinkle in the problem.

The function that the user-exit is being called from is IN UPDATE TASK. So, when I debug, and change the variable that decides to call the function in update task, so that it runs in the foreground, it can get the value of the variable in the import x from memory id y. But, it seems when it is in an update task, that memory must be gone, because it is executing the code that I don't want it to.

Any help with this?

If I had a function where I exported the value IN UPDATE TASK, would this help? Do the functions set to run IN UPDATE TASK share the same memory?

Thanks,

Rocky

[RichHeilman]

Oh ok, lets pass the flag off to a global memeory id. Use this syntax. This should work..

  data: key(60) type c.

  concatenate sy-uname sy-datum 'LT23' into key.

  export flag to shared buffer indx(st)id key.

Then in the user exit.

  data: key(60) type c.

  concatenate sy-uname sy-datum 'LT23' into key.

  import flag from shared buffer indx(st)id key.

* Clear out the shared buffer
  delete from
   shared buffer indx(st) id l_key.

if flag = 'X'.
exit.
Endif.

Regards,

Rich Heilman

[Former Member]

When something is called in UPDATE TASK its in a seperate memory space to the calling program.

Export to DATABASE rather than memory will persist in the UPDATE TASK however, and should solve your problem.

Just export using the key of the document, so you don't get problems with concurrent processes reading the wrong record. Its probably best to delete the DATABASE entry once you have accessed it in the userexit also.

Cheers,

Brad

[Former Member]

Agree that Rich's suggestion would work also. Just read the help on shared memory, in which version was that released?

Cheers,

Brad

[Former Member]

Best still to clean up the export once its been used, however.

Cheers,

Brad

[Former Member]

And did you just add the delete in?

What about some team spirit!

Anyway, have a good weekend everyone.

Cheers,

Brad