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: 

Two program in same LUW

Former Member
0 Kudos
1,035

Hi Experts,

I have a questions..Can we have a 2 programs saving the same LUW for processing??

Is there any method to force two programs into a single LUW??

Thanks,

Chirantan

1 ACCEPTED SOLUTION

Former Member
0 Kudos
338

If you are asking whether it is possible to SUBMIT two program calls within same LUW, then the answer is NO, as every SUBMIT statement executes the called program in a LUW of its own that is separate from the LUW of calling program.

The same happens when you start a transaction using CALL TRANSACTION - the statement opens a new LUW for the called transaction separate from the calling program.

One way to execute another transaction within same LUW as that of calling program is to create a dialog module with the same main program and initial screen in SE35 and call it using CALL DIALOG. But calling an entirely different program within same LUW is not desirable, as any statements that trigger an explicit commit in the called program can close the LUW of the calling program. That is one of the reason why CALL DIALOG statement has been obsoleted by SAP.

Another way to execute a transaction screen sequence within same LUW is to encapsulate the screen sequence as part of a function module and using CALL FUNCTION statement which executes in the same LUW as calling program.

If you would want to execute two different programs in the same LUW, you would not code them as separate programs in the first place and would rather combine them in a single program or bundle the database updates in function modules that are called using IN UPDATE TASK or use PERFORM.. ON COMMIT.

Best regards,

Vishnu Tallapragada

3 REPLIES 3

Former Member
0 Kudos
339

If you are asking whether it is possible to SUBMIT two program calls within same LUW, then the answer is NO, as every SUBMIT statement executes the called program in a LUW of its own that is separate from the LUW of calling program.

The same happens when you start a transaction using CALL TRANSACTION - the statement opens a new LUW for the called transaction separate from the calling program.

One way to execute another transaction within same LUW as that of calling program is to create a dialog module with the same main program and initial screen in SE35 and call it using CALL DIALOG. But calling an entirely different program within same LUW is not desirable, as any statements that trigger an explicit commit in the called program can close the LUW of the calling program. That is one of the reason why CALL DIALOG statement has been obsoleted by SAP.

Another way to execute a transaction screen sequence within same LUW is to encapsulate the screen sequence as part of a function module and using CALL FUNCTION statement which executes in the same LUW as calling program.

If you would want to execute two different programs in the same LUW, you would not code them as separate programs in the first place and would rather combine them in a single program or bundle the database updates in function modules that are called using IN UPDATE TASK or use PERFORM.. ON COMMIT.

Best regards,

Vishnu Tallapragada

Former Member
0 Kudos
338

if you are asking in terms of accessing same context then yes you can. change your program to function modules (of same group preferably ).

and call function modules with the addition starting new task and using RECEIVE RESULTS FROM FUNCTION is the return subroutine... with KEEPING TASK.

in this case, the context of FM is retained .

and you are expecting those two FM to be executing parallel, then no need to use the addition KEEPING TASK. if the task id is the same then they will access the same global variables on the function group.

0 Kudos
338

> if you are asking in terms of accessing same context then yes you can. change your program to function modules

> and call function modules with the addition starting new task and using RECEIVE RESULTS FROM FUNCTION is the return subroutine... with KEEPING TASK.

You don't need to create aRFCs for FMs to access the same context, any general FM would do!

When an FM is called, the global data of the corres. function group (FuGr) is loaded into the internal session of the calling program. So any FM of the same FuGr called in the same internal session subsequently can access the global data.

Of course, if the OP wants to run the procedure asynchronously then he can go for aRFCs.

BR,

Suhas