ABAP-Memory per User or static ABAP-class??

Hi there,
I want to save some information for each user in a transaction which uses SUBMIT-statements. So I want to store the information globally across reports and transactions (starting from my own single transaction).
So I can use the ABAP-Memory for storing this information. Is the information stored there seperated by user or is it possible that one user gehts the information of another user? When is ABAP-memory cleared? Is this done automaticly when my transaction flow is finished.
Alternatively I think I can use a global static ABAP-class with attributes to store the information. Is such a ABAP-class also user-dependent??
And when is this information cleared??
Can you give me some hints?
Thank you very much!
Kind regards
Jens

Hi,
Both ABAP and SAP memory are user specific. In your case if the issue would concern just one user you should go for SAP memory (when data should be exchanged between external sessions that is windows of SAP gui) or ABAP memory when data exchanged within one external session (between internal sessions - that is between programs run in one GUI session ).
If you want the data be stored globally for all the users, you have to either store them in some custom global table in DDIC (and later read from different user) or use [Shared objects|http://help.sap.com/saphelp_nw70/helpdata/EN/14/dafc3e9d3b6927e10000000a114084/frameset.htm] which is a special memory buffer in Application Server, where you can exchange data between user sessions.
Regards
Marcin

Similar Messages

Amount of Resources CPU and Memory per user

Hi,
We are looking to deploy a Line of Business Application via RemoteApp and a custom template. The application requires a significant amount of RAM and CPU, can someone tell me who much RAM and CPUs are allocated per session \ user? I would expect
that we would use the Standard tier if any difference to resources available.
Thanks
Giles

Hi James,
Currently there is no way to configure resources other than selecting either Basic or Standard. If you would like a lower per-VM user density (and thus higher resources for each user) what you can do is create more collections, and only assign
a small number of users to each.
For example, say you only wanted to have a maximum of 4 users on each VM, providing typically at least 1 vCPU per user. In this case you would create collections with the Basic plan, each linked
to the same template image, and only assign a maximum of 4 user accounts on the user access tab of each. Assuming each user uses 80+ hours a month, the total (before discounts) cost for each collection would be $228/month, making each user
cost about $57/month, slightly less than equivalent cost under Standard plan pricing if you factor in resources per user.
You probably already know this, but I will explain how scaling works normally for others that may read this. Azure RemoteApp will automatically create more VMs for each collection as needed to handle user load (Scale-Out) and shut down VMs when the
user load is reduced (Scale-In). The key thing that affects this scaling mechanism is the maximum concurrent users allowed on each VM, which for Standard is 10.
In your case you are asking if you can have more resources per user, hence my instructions above for creating multiple collections and limiting the number of assigned users to less than 10 each.
Depending on your unique needs it may make more sense to create a custom RDS deployment on Azure IaaS VMs. In this case you could control the size/type of VM used, user density, etc. Downside is you have to set up and manage more
RDS components than you do if you use Azure RemoteApp.
-TP

Is there any issue in using ABAP Memory ID to exchange between the programs

Hi All,
Do we expect any issues if we use ABAP Memory ID's to exchange the data between different programs?
I was told by my colleagues that, we can expect some unforeseen issues if we use ABAP Memory ID's. These issues could be because of refresh of Memory ID's in the Standard program.
Is that true? Need experts opinion on this question.
Thanks a lot in advance.
Regards,
RSS

I can think of such case only if you pick memory id of some standard name. Anyhow I can't imagine this happens w/o running any standard report on you machine from your custom report. ABAP memory is user dependant so you have your own roll area wherein all run programs can communicate. If you don't run any standard report by means of SUBMIT, you don't have to worry about this aspect either.
Futhermore if you run separate GUI session, or sinmply use /o in same session, you open new external session which gets its own new ABAP memory. So you don't affect your previous one at all.
If you want to be extremely careful, use memory id of some custom, original name i.e. I always use such naming convention NAME_OF_PROGRAM_XXXX where XXX denotes its usage i.e. XXX = 'EMPLOYEES'. If I also don't use SUBMIT I am 100% sure no other program touches/flushes this memory.
Don't believe your collegues and use ABAP memory whenever needed, but always consider context of program and where it lies in the memory. If they persist, please send them here to discuss this matter giving some good reason why they discourage you to do.
BTW: This could be an issue with SAP Memory, but with ABAP no chance.
Regards
Marcin

ABAP memory performance issue

Dear experts:
I got a problem with ABAP memory performance issue. I need to export an internal table to ABAP memory, and it's ID is sales order number. So, I will bulid too many ABAP memory in SAP...
Does it will couse performance issue or will it be lost?
tyrolu

Hi Tyrolu,
There are some settings in basis which decides size of your abap memory.
If you are consuming most of the abap memory by exporting heavy objects to abap memory then
you may face a problem as many standard sap program aslo uses abap memory and
if there is no free abap memory then they will start thowing short dumps like "Page allocation error"
or "Could not allocate shared memory" or something like that, I don't remember exact term now.
In some cases you won't have any problem if users are less, but as the no of concurrent users
running your program increased then every user who runs the program would consume abap memory
and if there is no free abap memory then this may again lead to above mentioned problem.
Also ensure FREE MEMORY ID is used which clears abap memory immediatly.
Other wise abap memory is cleared by the garbage collector on random basis and by that time
your memory remains consumed and not available for other programs to use
which may again lead to above mentioned problem.
Regards,
Vishal

How to use abap memory in global class

Hi experts,
I want to know how to use abap memory in global class. when i try write export and import statement its showing
error is export statement does not support in object oriented concept.
Thanks
Ramesh Manoharan

Hi Ramesh,
Export and import statements were not allowed to use in classes. Create a global variable in public section of that class of type of export parameter.Then pass value to the global variable of class by calling that class.
by
Prasad GVK.

Problem in ABAP memory

Hi Experts,
This is problem about ABAP memory.
I have two programs. Program-A & Program-B
Program-A sets value to variable and EXPORT command is used to set this variable in memory.
EXPORT variable TO DATABASE indx(st) ID 'KEYVALUE'.
Program-B gets variable using IMPORT command from memory.
IMPORT variable FROM DATABASE indx(st) ID 'KEYVALUE'.
User runs Program-A in SE38. Program-A calls Program-B using a button click event (SUBMIT).
The scenario is..
User1 executes the Program-A,
which set the variable = User1 in memory.
User2 executes the Program-A,
which set the variable = User2 in memory.
User2 clicks button to call Program-B,
which imports variable = User2 from memory.
User1 clicks button to call Program-B,
which imports variable = User2 from memory.
(But User1 expects the variable = User1).
So User1 gets wrong variable value set by another User.
How to handle this situation?. How to set memory variables user specific? I will appriciate all helpful answers.
Thanks in advance
Hari.

What you are using is global memory, if you don't want other sessions to see it, then you have to use a memeory id instead. This will work when submittin program b using the SUBMIT statement.
export variable to memory id 'ZRICHTEST'.
import variable from memory id 'ZRICHTEST'.
Or you can simply make your KEYVALUE unique by giving the USERID as part of it.
Regards,
Rich Heilman

Abap error when user fi asset using tcode KO88

hai gurus,
when the user fi_asset team want to use the transaction the system give and error.
For gurus information, we are facing the number ranges issue. when document type AA that using number ranges from 100006000 - 100006999 have been hit to maximum value in year 2007
so the at the time is we create a another number ranges in documnet type AA using number ranges form 8000000000 - 8999999999 that for year 2007 untill the future
but now when the user want to use this transaction the system have issue the problem.
when the user run the test run mode is no detect any problem but when user make actual run the system give abap error like this below.
ABAP runtime errors    MESSAGE_TYPE_X
       Occurred on     22.02.2008 at 09:58:49
>> Short dump has not been completely stored. It is too big.
The current application triggered a termination with a short dump.
What happened?
The current application program detected a situation which really
should not occur. Therefore, a termination with a short dump was
triggered on purpose by the key word MESSAGE (type X).
What can you do?
Note the actions and input that caused the error.
Inform your SAP system administrator.
You can print out this message by choosing "Print". Transaction ST22
allows you to display and manage termination messages, including keeping
them beyond their normal deletion date.
Error analysis
Short text of error message:
Document number 1000 100060000 2007 was already assigned
Long text of error message:
Diagnosis
Document number 100060000 in company code 1000 and fiscal year 2007
     has already been assigned.
System Response
Termination of processing.
Procedure
Check document number range 01 in company code 1000 and fiscal year
     2007 and correct the number range status if necessary.
Technical information about the message:
Message classe...... "F5 "
Number.............. 152
Variable 1.......... "1000 "
Variable 2.......... "100060000 "
Variable 3.......... "2007 "
Variable 4.......... "01 "

Hello,
If you are facing the error during KO88, there could be a problem with settlement document number range also.
During settlement, a settlement document is created and also related FI, CO, PA documments as applicable.
Please go to t code SNUM, check the number range for CO settlement object:CO_ABRECHN.
Let me know if it solves your problem.
Sourabh

Examples for SAP Memory and ABAP Memory

Hi all,
can u give me one example of sap memory and abap memory.
Ranjith

Hi,
SAP Memory
SAP memory is a memory area to which all main sessions within a SAPgui have access. You can use SAP memory either to pass data from one program to another within a session, or to pass data from one session to another. Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters). These parameters can be set either for a particular user or for a particular program at the time of logon using the SET PARAMETER statement. Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement. The most frequent use of SPA/GPA parameters is to fill input fields on screens .
example:
ABAP programs can access the parameters using the SET PARAMETER and GET PARAMETERstatements.
To fill one, use:
SET PARAMETER ID pid FIELD f
This statement saves the contents of field f under the ID pid in the SAP memory. The ID pid can be up to 20 characters long. If there was already a value stored under pid, this statement overwrites it. If you double-click pid in the ABAP Editor, parameters that do not exist can be created as a Repository object.
To read an SPA/GPA parameter, use:
GET PARAMETER ID pid FIELD f.
This statement places the value stored under the pid ID into the variable f. If the system does not find any value for pid in the SAP memory, sy-subrc is set to 4. Otherwise, it sets the value to 0.
ABAP Memory
ABAP memory is a memory area that all ABAP programs within the same internal session can access using the EXPORT and IMPORT statements. Data within this memory area remains throughout a sequence of program calls, with the exception of LEAVE TO TRANSACTION. To pass data to a program that you are calling, the data needs to be placed in ABAP memory before the call is made from the internal calling session using the EXPORT statement. The internal session of the called program then replaces that of the calling program. The program called can then read from the ABAP memory using the IMPORT statement. If control is then returned to the program that made the initial call, the same procedure operates in reverse.If a transaction is called using LEAVE TO TRANSACTION, the ABAP memory and the call stack are deleted. They cannot be used for data transfer.
Since objects belonging to ABAP objects can only be accessed within an internal session, it does not make sense and is therefore forbidden (from a syntax point of view) to pass a reference to an object to a calling program through the ABAP memory.
Example:
Export hello to memory id 'Hello_world'.
Import hello from memory id 'Hello_world'
Regards
Sudheer

How we can see the abap memory data

How we can see the abap-memory data
fine the code below
import lsind
         report_title
         table_name
         report_field
         change_display
         show_hide
         conversion_exits
         table_description
         form_program
         select_form
         update_form
         line_size
         line_count
         records[]
         fields[]
         header_fields[]
         select_fields[]
         xrep[]
         from memory id 'LZUT5U11'.
Regards
santhosh
mail-id : [email protected]

Dear Santosh,
ABAP MEMORY:
A logical memory model illustrates how the main memory is distributed from the view of executable programs. A distinction is made here between external sessions and internal sessions .
An external session is usually linked to an R/3 window. You can create an external session by choosing System/Create session, or by entering /o in the command field. An external session is broken down further into internal sessions. Program data is only visible within an internal session. Each external session can include up to 20 internal sessions (stacks).
Every program you start runs in an internal session.
All "squares" with rounded "corners" displayed in the status diagram represent a set of data objects in the main memory.
The data in the main memory is only visible to the program concerned.
CALL TRANSACTION and SUBMIT AND RETURN open a new internal session that forms a new program context. The internal sessions in an external session form a memory stack. The new session is added to the top of the stack.
When a program has finished running, the top internal session in the stack is removed, and the calling program resumes processing.
The same occurs when the system processes a LEAVE PROGRAM statement.
LEAVE TO TRANSACTION removes all internal sessions from the stack and opens a new one containing the program context of the calling program.
The ABAP memory is initialized after the program is called. In other words, you cannot transfer any data to a program called with LEAVE TO TRANSACTION via the ABAP memory.
SUBMIT replaces the internal session of the program performing the call with the internal session of the program that has been called. The new internal session contains the program context of the called program with which it is performed.
When a function module is called, the following steps are executed:
A check is made to establish whether your program has called a function module of the same function group previously.
If this is not the case, the system loads the associated function group to the internal session of the calling program as an additional program group. This initializes its global data.
If your program used a function module of the same function group before the current call, the function module that you have called up at present can access the global data of the function group. The function group is not reloaded.
Within the internal session, all of the function modules that you call from the same group access the global data of that group.
If, in a new internal session, you call a function module from the same function group as in internal session 1, a new set of global data is initialized for the second internal session. This means that the data accessed by function modules called in session 2 may be different from that accessed by the function modules in session 1.
You can call function modules asynchronously as well as synchronously. To do so, you must extend the function module call using the addition STARTING NEW TASK ''. Here, '' is a symbolic name in the calling program that identifies the external session, in which the called program is executed.
Function modules that you call using the addition STARTING NEW TASK '' are executed independently of the calling program. The calling program is not interrupted.
To make function modules available for local asynchronous calls, you must identify them as executable remotely (processing type: Remote-enabled module).
There are various ways of transferring data between programs that are running in different program contexts (internal sessions). You can use:
(1) The interface of the called program (standard selection screen, or interface of a
subroutine, function module, or dialog module)
(2) ABAP memory
(3) SAP memory
(4) Database tables
(5) Local files on your presentation server.
For further information about transferring data between an ABAP program and your presentation server, refer to the documentation for the function modules WS_UPLOAD and WS_DOWNLOAD.
Function modules have an interface, which you can use to pass data between the calling program and the function module itself (there is also a comparable mechanism for ABAP subroutines). If a function module supports RFC, certain restrictions apply to its interface.
If you are calling an ABAP program that has a standard selection screen, you can pass values to the input fields. There are two options here:
By using a variant of the standard selection screen in the program call
By passing actual values for the input fields in the program call
If you want to call a report program without displaying its selection screen (default setting), but still want to pass values to its input fields, there is a variety of techniques that you can use.
The WITH addition allows you to assign values to the parameters and select-options fields on the standard selection screen.
If the selection screen is to be displayed when the program is called, use the addition: VIA SELECTION-SCREEN.
Use the pattern button in the ABAP Editor to insert a program call via SUBMIT. The structure shows you the names of data objects that you can complete with the standard selection screen.
For further information on working with variants and further syntax variants for the WITH addition, see the key word documentation in the ABAP Editor for SUBMIT.
You can use SAP memory and ABAP memory to pass data between different programs.
The SAP memory is a user-specific memory area for storing field values. It is available in all of the open sessions in a user's terminal session, and is reset when the terminal session ends. You can use its contents as default values for screen fields. All external sessions can access SAP memory. This means that it is only of limited use for passing data between internal sessions.
The ABAP memory is also user-specific, and is local to each external session. You can use it to pass any ABAP variables (fields, structures, internal tables, complex objects) between the internal sessions of a single external session.
Each external session has its own ABAP memory. When you end an external session (/i in the command field), the corresponding ABAP memory is released automatically.
To copy a set of ABAP variables and their current values (data cluster) to the ABAP memory, use the EXPORT TO MEMORY ID statement. The (up to 32 characters) is used to identify the different data clusters.
If you repeat an EXPORT TO MEMORY ID statement to an existing data cluster, the new data overwrites the old.
To copy data from ABAP memory to the corresponding fields of an ABAP program, use the IMPORT FROM MEMORY ID statement.
The fields, structures, internal tables, and complex objects in a data cluster in ABAP memory must be declared identically in both the program from which you exported the data and the program into which you import it.
To release a data cluster, use the FREE MEMORY ID statement.
You can import just parts of a data cluster with IMPORT, since the objects are named in the cluster.
In the SAP memory, you can define memory areas (SET/GET parameters, or parameter IDs), which you can then address by a name of up to 20 characters.
You can fill these memory areas either using the contents of input/output fields on screens, or using the ABAP statement:
SET PARAMETER ID '' FIELD .
The memory area with the name now has the value .
You can use the contents of a memory area to display a default value in an input field on a screen.
You can also read the memory areas from the SAP memory using the ABAP statement GET PARAMETER ID FIELD . The field then contains the value from parameter .
The link between an input/output field and a memory area in SAP memory is inherited from the data element on which the field is based. You can enable the set parameter or get parameter attributes in the input/output field attributes.
Once you have set the Set parameter attribute for an input/output field, you can fill it with default values from SAP memory. This is particularly useful for transactions that you call from another program without displaying the initial screen. For this purpose, you must activate the Set parameter functionality for the input fields of the first screen of the transaction.
You can:
(1) Copy the data that is to be used for the first screen of the transaction to be called to the parameter ID in the SAP memory. To do so, use the statement SET PARAMETER immediately before calling the transaction.
(2) Start the transaction using CALL TRANSACTION or LEAVE TO
TRANSACTION . If you do not want to display the initial screen, use the AND
SKIP FIRST SCREEN addition.
(3) The system program that starts the transaction fills the input fields that do not already have default values and for which the Get parameter attribute has been set with values from SAP memory.
The Technical information for the input fields in the transaction you want to call contains the names of the parameter IDs that you need to use.
Parameter IDs should be entered in table TPARA. This happens automatically if you create them via the Object navigator.
Programs that you call using the statements SUBMIT , LEAVE TO TRANSACTION , SUBMIT AND RETURN, or CALL TRANSACTION run in their own SAP LUW, and update requests receive their own update key.
When you use SUBMIT and LEAVE TO TRANSACTION , the SAP LUW of the calling program ends. If no COMMIT WORK statement occurred before the program call, the update requests in the log table remain incomplete and cannot be processed. They can no longer be executed. The same applies to inline changes that you make using PERFORM … ON COMMIT.
Data that you have written to the database using inline changes is committed the next time a new screen is displayed.
If you use SUBMIT AND RETURN or CALL TRANSACTION to insert a program and then return to the calling program, the SAP LUW of the calling program is resumed when the called program ends. The LUW processing of calling and called programs is independent.
In other words, inline changes are committed the next time a new screen is displayed. Update requests and calls using PERFORM ... ON COMMIT require an independent COMMIT WORK statement in the SAP LUW in which they are running.
Function modules run in the same SAP LUW as the program that calls them.
If you call transactions with nested calls, each transaction needs its own COMMIT WORK, since each transaction maps its own SAP LUW.
The same applies to calling executable programs, which are called using SUBMIT AND RETURN.
The statement CALL TRANSACTION allows you to
Shorten the user dialog when calling using CALL TRANSACTION USING .
Determine the type of update (asynchronous, local, or synchronous) for the transaction called. For this purpose, use the addition CALL TRANSACTION USING UPDATE 'update_mode', where update_mode can have the values a (asynchronous), L (local), or S (synchronous).
Combining the two options enables you to call several transactions in sequence (logical chain), to reduce their screen sequence, and to postpone processing of the SAP LUW 2 until processing of the SAP LUW 1 has been completed.
When you call a function module asynchronously using the CALL FUNCTION STARTING NEW TASK ' ' statement, it runs in its own SAP LUW.
Programs that are executed with a SUBMIT AND RETURN or CALL
TRANSACTION statement starts their own LUW processing. You can use these to perform nested (complex) LUW processing.
You can use function modules as modularization units within an SAP LUW.
Function modules that are called asynchronously are suitable for programs that allow parallel processing of some of their components.
All techniques are suitable for including programs with purely display functions.
Note that a function module called with CALL FUNCTION STARTING NEW TASK is executed as a new logon. It, therefore, sees a separate SAP memory area. You can use the interface of the function module for data transfers.
Example: In your program, you want to call a display transaction that is displayed in a separate window (amodal). To do so, you encapsulate the transaction call in a function module, which you set as to Remote-enabled module. You use the function module interface to accept values that you write to the SAP memory. You then call up the transaction in the function module using CALL TRANSACTION AND SKIP FIRST SCREEN. You call the function module itself asynchronously.
Type ‘E' locks for nested program calls may be requested more than once from the same object. This behavior can be described as follows:
Lock entries from function modules called synchronously increment the cumulative counter, And are therefore successful.
Lock entries from programs called with CALL TRANSACTION or SUBMIT
AND
RETURN is refused. The object to be locked by the called program is displayed as already Locked by another user.
Programs that you call using SUBMIT or LEAVE TO TRANSACTION cannot come into conflict with lock entries from the calling program, since the old program ends when the call is made. When a program ends, the system deletes all of the lock entries that it had set.
Lock requests belonging to the same user from different R/3 windows or logons are treated as lock requests from other users.
Regards,
Rajesh.
Please reward points if found helpful.

Hi Friends ....Difference between SAP memory and ABAP memory

Hi Friends,
I faced a interview and they ask this question
What is the difference between SAP Memory and ABAP memory..

conti
SAP Memory
SAP memory is a memory area to which all main sessions within a SAPgui have access. You can use SAP memory either to pass data from one program to another within a session, or to pass data from one session to another. Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters). These parameters can be set either for a particular user or for a particular program using the SET PARAMETER statement.
Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement. The most frequent use of SPA/GPA parameters is to fill input fields on screens.
ABAP Memory
ABAP memory is a memory area that all ABAP programs within the same internal session can access using the EXPORT and IMPORT statements. Data within this area remains intact during a whole sequence of program calls. To pass data to a program which you are calling, the data needs to be placed in ABAP memory before the call is made. The internal session of the called program then replaces that of the calling program. The program called can then read from the ABAP memory. If control is then returned to the program which made the initial call, the same process operates in reverse.
A simple example of ABAP memory is using the EXPORT/IMPORT statements.
Here in this program, I get the data, export it to memory,
clear out the internal table in my progam, then reimport the data into it and write out the data.
You probably wounldn't do this in a normal program,
but this is how you can pass data from program a to program b when A Submits program B.
report zxy_0002 .
data: it001 type table of t001 with header line.
select * into table it001 from t001.
export it001 = it001 to memory id 'ZXY_TEST'.
clear it001. refresh it001.
import it001 = it001 from memory id 'ZXY_TEST'.
loop at it001.
write:/ it001-bukrs, it001-butxt.
endloop.
SAP Memory
SAP memory is a memory area to which all main sessions within a SAPgui have access.
You can use SAP memory either to pass data from one program to another within a session,
or to pass data from one session to another.
Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters).
These parameters can be set either for a particular user
or for a particular program using the SET PARAMETER statement.
Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement.
The most frequent use of SPA/GPA parameters is to fill input fields on screens
ABAP/4 Memory
ABAP memory is a memory area that all ABAP programs within the same internal session can access
using the EXPORT and IMPORT statements.
Data within this area remains intact during a whole sequence of program calls. To pass data
to a program which you are calling,
the data needs to be placed in ABAP memory before the call is made.
The internal session of the called program then replaces that of the calling program.
The program called can then read from the ABAP memory.
If control is then returned to the program which made the initial call, the same process operates in reverse.
SAP memory
The SAP memory, otherwise known as the global memory,
is available to a user during the entire duration of a terminal session.
Its contents are retained across transaction boundaries as well as external and internal sessions.
The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory.
ABAP/4 memory
The contents of the ABAP/4 memory are retained only during the lifetime of an external session
(see also Organization of Modularization Units).
You can retain or pass data across internal sessions.
The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory.
ABAP Memmory & SAP Memmory
http://www.sap-img.com/abap/difference-between-sap-and-abap-memory.htm
http://www.sap-img.com/abap/type-and-uses-of-lock-objects-in-sap.htm
Set
http://www.geocities.com/SiliconValley/Campus/6345/set_para.htm
GET
http://www.geocities.com/SiliconValley/Campus/6345/get_para.htm
EXPORT
http://www.geocities.com/SiliconValley/Campus/6345/export01.htm
Other Imp Help
http://www.geocities.com/SiliconValley/Campus/6345/abapindx.htm

Reading from ABAP memory, not available in call stack

Hi,
I need to read a table from ABAP memory. It is not available from the call stack, so I cant use the standard assign approach. The internal table is listed under System areas -> Area ITABS-HEADS with the name \FUNCTION-POOL=MLSP\DATA=IY_ESLL[]
Is it even possible to read this table? Seems as though I have to access function-pool MLSP to find it.
Regards,
Damian

Hi,
The main program of this function pool is SAPLMLSP. If you in any of theses includes can add a small form that returns the content of internal table ( IY_ESLL[] ) that should solve your problem.
In the program that need the data, write something like :
PERFORM Z_GET_MLSP_DATA(SAPLMLSP) using GT_ESLL.
This form can be created within any sub-include within the SAPLMLSP.
However, with a quick look at SAPLMLSP does not reveal any user modifiable includes, but I didn't check very carefully.
If you are on ECC 6.0, there are plenty of enhancement spots, which could be used for this purpose.

ABAP Memory.

Hi,
I have 2 ABAP program which was created in dialog screen not selection-scrren and list-processing. I using IMPORT & EXPORT with MEMORY ID 'mem_test' to pass value. I would like to know will there be any memory corruption and cause inconsistency when there is multi-concurrency of user using the ABAP program.
IF using IMPORT & EXPORT without Memory ID, will it cause any memory corruption and cause inconsistency when 2 person accessing the program at a time, or the memory will be smart enough to allocated another new memory space for the other user?
How do i avoid this? Is there any other better way like using submit? Please advise.
Regards,
Rayden

SUBMIT
Syntax
SUBMIT {rep|(name)} [selscreen_options]
                    [list_options]
                    [job_options]
                    [AND RETURN].
Addition:
... AND RETURN
Effect
The SUBMIT statement accesses an executable program rep. The executable program is executed as described under Calling Executable Reports.
The program name rep can either be specified directly or as the content of a character-like data object name. The data object name must contain the name of the program to be accessed in block capitals. If the program specified in name is not found, an irretrievable exception is generated.
The selscreen_options additions can be used to determine the selection screen for the program accessed and to supply it with values.
The list_options additions allow you to influence the output medium and the page size in the basic list for the program accessed.
You can schedule the program for background processing by specifying job_options.
SUBMIT - selscreen_options
Syntax
... [USING SELECTION-SCREEN dynnr]
    [VIA SELECTION-SCREEN]
    [selscreen_parameters] ... .
Extras:
1. ... USING SELECTION-SCREEN dynnr
2. ... VIA SELECTION-SCREEN
Effect
The addition USING SELECTION-SCREEN specifies the selection screen, VIA SELECTION-SCREEN specifies whether it is displayed. The additions selscreen_parameters provide values for the parameters, selection criteria, and the free selection of the called selection screen.
The values are transferred to the selection screen between the events INITIALIZATION and AT SELECTION-SCREEN OUTPUT The following hierarchy applies for transferring values:
First, the variant of the addition USING SELECTION-SET is transferred, which sets all parameters and selection criteria to the values of the variant. The values previously set in the called program are overwritten.
The values of the table of the addition WITH SELECTION-TABLE are then transferred. All parameters and selection criteria specified there are overwritten accordingly.
Finally, the values of the additions WITH sel value are transferred. All parameters and selection criteria are overwritten accordingly. If the addition WITH sel value is used more than once for the same parameter, this is overwritten with the last specified value. If the addition WITH sel value is used more than once for the same selection criterion, a selection table with the corresponding number of lines is transferred.
Providing values for free selections is independent of this hierarchy.
Notes
The options for parameter transfer enable a selection screen to be viewed as a parameter interface of an executable program. This applies particularly for background selection screen processing and for parameters and selection criteria that are defined without screen elements using the addition NO-DISPLAY
When transferring data, note that any adjustments made to the screen format, such as abbreviations or the execution of conversion routines, are not executed for fields for which there are no screen elements on the selection screen. This applies for all parameters and selection criteria defined with NO DISPLAY. It also applies for all lines of a selection table with the exception of the first line.
The additions selscreen_parameters only work the first time the called program is executed. If a selection screen is displayed in the called program, the runtime environment calls the program again after it is finished, thereby replacing the values specified in selscreen_parameters with the previous input values.
Addition 1
... USING SELECTION-SCREEN dynnr
Effect
This addition specifies which selection screen is called. dynnr is a data object that must contain the screen number of a selection screen defined in the called program when the SUBMIT statement is called.
If the addition USING SELECTION-SCREEN is omitted or the screen number 1000 is entered, the standard selection screen is called. If no standard selection screen is defined in the called program, no selection screen is called.
If a screen number that is not 1000 is entered in the addition USING SELECTION-SCREEN, the corresponding independent selection screen is called. If no selection screen with this screen number is defined in the called program, this leads to an untreatable exception.
Addition 2
... VIA SELECTION-SCREEN
Effect
If this addition is specified, the selection screen is displayed on the screen. Otherwise, background selection screen processing takes place. In background selection screen processing, the selection screen events are triggered without the selection screen being displayed.
SUBMIT - list_options
Syntax
... [LINE-SIZE width]
    [LINE-COUNT page_lines]
    { [EXPORTING LIST TO MEMORY]
    | [TO SAP-SPOOL spool_options] } ... .
Extras:
1. ... LINE-SIZE width
2. ... LINE-COUNT page_lines
3. ... EXPORTING LIST TO MEMORY
4. ... TO SAP-SPOOL spool_options
Effect:
These additions affect the basic list in the program accessed. While LINE-SIZE and LINE-COUNT influence the formatting, the other two additions determine the output type of the list.
EXPORTING LIST TO MEMORY saves the list to the ABAP Memory and TO SAP-SPOOL sends it as a print list to the SAP spool system. If you do not specify these additions, the basic list is displayed as a screen list.
Note:
The additions only take effect the first time the program accessed is executed. If a selection screen is displayed in the program accessed, the runtime environment accesses the program again after completion, without taking account of the list_options additions. This is particularly important to the addition TO SAP-SPOOL, because the basic list is displayed as a screen list and not as a print list when the program is accessed again. For this reason, it is advisable not to use the addition VIA SELECTION-SCREEN when using list_options.
Addition 1
... LINE-SIZE width
Addition 2
... LINE-COUNT page_lines
Effect
These additions define the line width and page length of the basic list. They have the same effect as the additions of the same name in the program initiating statement for the program accessed. If the program accessed has the same additions in the program initiating statement, these overwrite the values specified for SUBMIT.
Addition 3
... EXPORTING LIST TO MEMORY
Effect
This addition stores the basic list for the program accessed in the ABAP Memory. It can only be used together with the addition AND RETURN.
The list is stored in the ABAP Memory as an internal table of the row type ABAPLIST, ABAPLIST being a structured data type in the ABAP Dictionary.
The calling program can access the list stored once program access is completed, using function modules belonging to the function group SLST.
The function module LIST_FROM_MEMORY loads the list from the ABAP Memory to an internal table of the row type ABAPLIST.
The function module WRITE_LIST inserts the content of an internal table of the row type ABAPLIST in the current list.
The function module DISPLAY_LIST displays the content of an internal table of the row type ABAPLIST in a separate list screen.
Note
The addition can only work provided the function key Enter is not linked to a function code in the GUI status last defined for the program accessed.
Example
Once the program report has been accessed, the list stored there in the ABAP Memory is read by means of function modules and inserted in the current list.
DATA list_tab TYPE TABLE OF abaplist.
SUBMIT report EXPORTING LIST TO MEMORY
              AND RETURN.
CALL FUNCTION 'LIST_FROM_MEMORY'
TABLES
    listobject = list_tab
EXCEPTIONS
    not_found = 1
    OTHERS     = 2.
IF sy-subrc = 0.
CALL FUNCTION 'WRITE_LIST'
    TABLES
      listobject = list_tab.
ENDIF.
Addition 4
... TO SAP-SPOOL spool_options
Effect
This addition causes a new print list level to be opened in the internal session of the program called and assures that the first output statement for the basic list creates a new spool request. All list outputs of the program called are transferred as print lists, page by page, to the SAP spool system. Using the spool_options additions, the print parameters and archiving parameters of the spool request are specified.
Note
It is not possible to switch from the print list to a screen list in the program called. The statement NEW-PAGE PRINT OFF does not work on print list levels created using SUBMIT TO SAP-SPOOL.
Example
Accessing an executable program and creating a spool request.
DATA: print_parameters TYPE pri_params,
      archi_parameters TYPE arc_params,
      valid_flag(1) TYPE c.
CALL FUNCTION 'GET_PRINT_PARAMETERS'
EXPORTING
    archive_mode           = '3'
IMPORTING
    out_parameters         = print_parameters
    out_archive_parameters = archi_parameters
    valid                  = valid_flag
EXCEPTIONS
    invalid_print_params   = 2
    OTHERS                 = 4.
IF valid_flag = 'X' AND sy-subrc = 0.
SUBMIT submitable TO SAP-SPOOL
                    SPOOL PARAMETERS print_parameters
                    ARCHIVE PARAMETERS archi_parameters
                    WITHOUT SPOOL DYNPRO.
ENDIF.

ABAP Memory ID

Hi All,
Is the ABAP memory ID global?
for example, I have FUNC1, in FUNC1, I export value to memory ID 'ABC'. the value of 'ABC' is valide for all other function call?
The porblem I experinced is that the FUNC1 may called by many interface at the SAME time, and because the memory ID id "global", it may cause problem.
Thanks,

If you look at the documentation of the 'EXPORT' statement, you will see that data is stored in the ABAP memory not in SAP global memory. See below for an extract of the documentation.
Stores a data cluster in ABAP memory. The specified objects obj1 ... objn (fields, structures, complex structures, or tables) are stored as one cluster in ABAP memory.
If you call a transaction, an executable program, or a dialog module in call mode ( CALL TRANSACTION, SUBMIT, CALL DIALOG), the ABAP memory is retained, even over several call levels. The called transaction can import the data from ABAP memory using IMPORT ... FROM MEMORY. Each new EXPORT ... TO MEMORY overwrites the old data in ABAP memory. You cannot therefore append to data already in the ABAP memory.
When you leave the lowest level of the call chain, the ABAP memory is released.
SAP and ABAP/4 Memory
There is a difference between the cross-transaction SAP memory and the transaction-specific ABAP/4 memory.
SAP memory
The SAP memory, otherwise known as the global memory, is available to a user during the entire duration of a terminal session. Its contents are retained across transaction boundaries as well as external and internal sessions. The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory.
ABAP/4 memory
The contents of the ABAP/4 memory are retained only during the lifetime of an external session (see also Organization of Modularization Units). You can retain or pass data across internal sessions. The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory.
Please consult Data Area and Modularization Unit Organization documentation as well.
and Memory Structures of an ABAP Program
So, just based on this, your problem may not be related to the export statement or the import statement.
Are you making multiple function calls from the same program/transaction? In this case there is a chance of the memory getting overlaid. But if different people are using the transaction/program at the same time, but the function call is just once in the program/transaction, then you should not have this issue.
Srinivas

Shared memory used in Web Dynpro ABAP

Hi Gurus,
I am using shared memory objects in Web Dynpro ABAP. Everything was working fine until we went live to production. After some research I realized that users are not always able to reach data in shared memory because of different approach of web environment and classic GUI when using more servers. Solution would be to go to database instead of shared memory. However I am still interested if there might be some other way to solve it. Any ideas?

Marek Veverka wrote:
Hi Gurus,
>
> I am using shared memory objects in Web Dynpro ABAP. Everything was working fine until we went live to production. After some research I realized that users are not always able to reach data in shared memory because of different approach of web environment and classic GUI when using more servers. Solution would be to go to database instead of shared memory. However I am still interested if there might be some other way to solve it. Any ideas?
To my understanding writing to the database is the safe option. There are no other ways to solve your problem with Shared memory.

Hi All,Can any provide an example for SAP MEMORY AND ABAP memory

Hi All,
Can any provide me an example for SAP MEMORY AND ABAP memory.
thanks&regards.
Bharat.

HI Bharat
A simple example of ABAP memory is using the EXPORT/IMPORT statements.
Here in this program, I get the data, export it to memory,
clear out the internal table in my progam, then reimport the data into it and write out the data.
You probably wounldn't do this in a normal program,
but this is how you can pass data from program a to program b when A Submits program B.
report zxy_0002 .
data: it001 type table of t001 with header line.
select * into table it001 from t001.
export it001 = it001 to memory id 'ZXY_TEST'.
clear it001. refresh it001.
import it001 = it001 from memory id 'ZXY_TEST'.
loop at it001.
write:/ it001-bukrs, it001-butxt.
endloop.
SAP Memory
SAP memory is a memory area to which all main sessions within a SAPgui have access.
You can use SAP memory either to pass data from one program to another within a session,
or to pass data from one session to another.
Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters).
These parameters can be set either for a particular user
or for a particular program using the SET PARAMETER statement.
Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement.
The most frequent use of SPA/GPA parameters is to fill input fields on screens
ABAP/4 Memory
ABAP memory is a memory area that all ABAP programs within the same internal session can access
using the EXPORT and IMPORT statements.
Data within this area remains intact during a whole sequence of program calls. To pass data
to a program which you are calling,
the data needs to be placed in ABAP memory before the call is made.
The internal session of the called program then replaces that of the calling program.
The program called can then read from the ABAP memory.
If control is then returned to the program which made the initial call, the same process operates in reverse.
SAP memory
The SAP memory, otherwise known as the global memory,
is available to a user during the entire duration of a terminal session.
Its contents are retained across transaction boundaries as well as external and internal sessions.
The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory.
ABAP/4 memory
The contents of the ABAP/4 memory are retained only during the lifetime of an external session
(see also Organization of Modularization Units).
You can retain or pass data across internal sessions.
The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory.
ABAP Memmory & SAP Memmory
http://www.sap-img.com/abap/difference-between-sap-and-abap-memory.htm
http://www.sap-img.com/abap/type-and-uses-of-lock-objects-in-sap.htm
Set
http://www.geocities.com/SiliconValley/Campus/6345/set_para.htm
GET
http://www.geocities.com/SiliconValley/Campus/6345/get_para.htm
EXPORT
http://www.geocities.com/SiliconValley/Campus/6345/export01.htm
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3bc4358411d1829f0000e829fbfe/frameset.htm
Other Imp Help
http://www.geocities.com/SiliconValley/Campus/6345/abapindx.htm
Regards Rk

ABAP-Memory per User or static ABAP-class??

Similar Messages

Maybe you are looking for