Sharing INCLUDE variables
I have about 5 programs that share the same INCLUDE. All of these programs share the same several variables for processing defined in the INCLUDE. If the 5 programs were to run simultaneously, would there be any conflict on the variables in terms of overwiting values at some point in time of the 5 running programs?
Would it be wise to define the variables in each of its own program?
Thanks
No. This is the idea of Include.
Greetgreet is right. You should make a function module. What do you 5 programs do?
Robert
Guest,
Just to compare: imagine an office where several people are entering Sales Orders at the same time. They do not only use the same TOP-include, but also the same coding. Luckily they all run in local copies. The only 'problem' that can occur is that one user is locking a database record for another one user.
Usually a development class contains 1 include with data declarations. The same goes for Function groups.
So, no worries.
Robert: make a function module? I assume those 5 programs are performing different tasks (at least I hope so). If not, you have a point.
Since you asked, you would not believe what I have been through with these programs and the PEOPLE. Of course, these 5 programs have different logic and have different tasks. I was able to create one program that was a combination of these 5 programs. I created table locks for the 6 tables that were in use from this one program. I also prevented users from being able to execute the program in the background. The program is to extract data from SAP R3 to be loaded to BW. The purpose of using table locks on these tables was to prevent inadvertent execution of another same session of the same program that would create writing conflict to these tables. Moreover, it was to ensure that all the data from these tables to get loaded to BW because every time the programs get executed the tables get refreshed (I used the Native SQL TRUNCATE to wipe out the data from these tables).
The first problem was that the use of MESSAGE E type to check for the SY-BATCH status to prevent foreground execution was basically discouraged because it was said that the prevention wouldn't allow debugging on production if there was ever a problem. They have never seen any other companies who had done this with the program. A BW consultant was brought in to say that you never have to do this ever to any ABAP programs.
The second issue was the table locks. The issue was that the cancellation of this one program while it was running wouldn't allow automatic release of the locks. You would have to go into SM12 to delete the locks. SM50 is wide open for deletion of processes while SM12 is restricted. A BW consultant had called in and indicated that SAP automatically locks the custom tables and there was no need to explicitly do so.
The third issue was the program doesn't make good use of the internal tables and memory usage and the program was running in an infinite loop. The program was running fine until the balancing load logon issue was introduced and that we have 5 app servers. One server being the DB server and doesn't have enough memory. I was able to find a solution to submit the program in the background through SM36 to choose the app server other than the DB server, but people were complaining that they don't want to do that and why a program should not be able to run on any server including the DB server.
I was told to use the REFRESH statement to make good use of the memory. I was told use the COMMIT WORK statement. My understanding is that the COMMIT statement closes the LUW and will not roll back if you ever decide to cancel a running job, but the reasoning was to be able to delete a background job and rerun if possible. I would think that if this it were the case, you would need to delete unwanted records that were not rolled back.
The story goes. I thought it would make things easy and according to the suggestion which was to break the 5 tasks in that one program into 5 programs to make good use of memory, use REFRESH to also make good use of memory, take out the locks, take out the code to prevent execution the program in the foreground, no need to use MESSAGE class to check for the SY-SUBRC and display appropriate messages, no need for a background job log, and no totals for accounting the number of records extracted from SAP and loaded to BW. The thought was to ask for a BW consultant to find a function module to get the record count from SAP or BW to determine the record count extracted and loaded to BW. I don't think that is possible because these are custom programs that have custom logic to extract data with specific IF-ELSE and SELECT conditions to filter data. It is possible only if you write your own function module. To find a SAP standard FM to do that, you would need to write additional code to feed values to this FM.
This is my whine of the day.
If your 5 programs perform 5 different funcitons, then that's probably the best way to go. If you have repeated code, you CAN use an include. It's just not the best way. The best way is usually a function module. If you don't want to take the time to create a function module, you can say PERFORM xxx IN PROGRAM xxx. This will avoid repeating the code, but will give similar data declaration problems. You can also copy and paste code, which will obviously cause repeated code, but can be the least confusing as you have 1 self-contained program.
Once, COMMITTed data cannot be rolled back. Data can be rolled back prior to being committed with ROLLBACK WORK.
If you want to free internal table memory use FREE not REFRESH.
Good luck and be glad you have a job.
Robert Crouser
An INCLUDE copies code into your program prior to compilation, so if the variables are within the include, they are not being shared.
Robert
The first problem was that the use of MESSAGE E type to check for the SY-BATCH status to prevent foreground execution was basically discouraged because it was said that the prevention wouldn't allow debugging on production if there was ever a problem. They have never seen any other companies who had done this with the program. A BW consultant was brought in to say that you never have to do this ever to any ABAP programs.
I use a check for SY-BATCH and issue E type messages in reports all of the time. It does NOT preclude debugging (although doing that in Production is always a last resort), as with the correct security settings you can simply replace the variable value for SY-BATCH to 'X' to allow your program to proceed (not forgetting to switch it back after your check).
I think you're being led up a garden path by your client at the moment, from the sounds of things the programs being written at their site are a load of fetid dingos kidneys (to quote a famous English author)[/quote]
_________________
Kind Regards
Rosie Brent
Please remember to search the forum and check the FAQ before posting questions, thank you.
Tuly Idiot most of the time, part-time Guru
The first problem was that the use of MESSAGE E type to check for the SY-BATCH status to prevent foreground execution was basically discouraged because it was said that the prevention wouldn't allow debugging on production if there was ever a problem. They have never seen any other companies who had done this with the program. A BW consultant was brought in to say that you never have to do this ever to any ABAP programs.
I use a check for SY-BATCH and issue E type messages in reports all of the time. It does NOT preclude debugging (although doing that in Production is always a last resort), as with the correct security settings you can simply replace the variable value for SY-BATCH to 'X' to allow your program to proceed (not forgetting to switch it back after your check).
I think you're being led up a garden path by your client at the moment, from the sounds of things the programs being written at their site are a load of fetid dingos kidneys (to quote a famous English author)[/quote]
The 'E' message could be very irritating if the report has many parameters they will be lost.
What about de-activating the 'ONLI' function?
This is an example:
This is my whine of the day.
Lord help me!!! I pray to be surrounded by good people, so I wouln't become one of THEM.
By the way God, THEY keep insisting using REFRESH to make good use of memory. Have I become them by whining and backstabbing about little things?
How about this plan... you print out the keyword help for REFRESH, CLEAR and FREE and leave it lying around by the printer.
Then, later when someone mentions these piles of paper, say 'oh yeah, I was just doing some research', pretend to scan these, then look shocked and 'reveal' that FREE sorts out memory allocation and REFRESH just removes the body lines of table (still allocating 1 row's worth of memory).
In this way you prove your point, and can't be told you're talking donkey droppings
(BTW - can you tell I have worked with morons in the past?)
_________________
Kind Regards
Rosie Brent
Please remember to search the forum and check the FAQ before posting questions, thank you.
Tuly Idiot most of the time, part-time Guru
The saga continues...
After all the work had been done and moved to production as they had suggested. It now ended up still that one of the programs that requires intensive search through a table that contains more than 2 million records needs to be scheduled through SM36 to choose a specific App Server. It goes dead when it gets assigned by the balancing load logon to be executed from the DB server that doesn't have enough memory .
The Nerve even had the audacity to make me complete the documentation, while he is shitting at my desk, to add in instructions to schedule the program through SM36 to choose the App Server other than the DB server.
Stinking perverts. Don't come near me.