cancel
Showing results for 
Search instead for 
Did you mean: 

Related to previous post..

Former Member
0 Kudos
669

Hi realted to my previous question, I was looking at standard ABAP SAPCript driver program PSFCOBJL.

I see something like follwoing inside include LCODRINC:-

Import .....

FROM MEMORY ID 'PPT'.

......

......

IMPORT ITAB

ITAB_TDR FROM MEMORY ID 'PPI'.

IMPORT PRLST_TMP FROM MEMORY ID 'PPS'.

What does memory ID' PPT', 'PPI' and 'PPS' signify.

Is this the place from where we can ftech the initail data field(Explained in my previous post)

Tushar.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Memory ID is a concept similar to pointers in C, you can define any name to a memory place and then you can place any value over there and call it according to your program's requirement. This memory space may not always have the same value as it changes according to the flow of the program. So saying that a particular memory id will always store the same value is difficult. To call a value you must first export the value to that id with "Export" and then call at the required place with "Import".

Hope it helps,

Cheers,

Barjinder Singh

Former Member
0 Kudos

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

IMPORT - Reading Data

Variants:

1. IMPORT obj1 ... objn FROM MEMORY.

2. IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.

3. IMPORT obj1 ... objn FROM LOGFILE ID key.

4. IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.

5. IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.

6. IMPORT obj1 ... objn FROM SHARED BUFFER dbtab(ar) ID key.

7. IMPORT (itab) FROM ... .

Variant 1

IMPORT obj1 ... objn FROM MEMORY.

Additions:

1. ... = f (for each object to be imported)

2. ... TO f (for each object to be imported)

3. ... ID key

In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See ID must be specified and Implicit Field Names not Allowed inClusters

Effect

Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from a data cluster in ABAP memory . All data exported to ABAP memory using EXPORT... TO MEMORY without ID is read. Unlike the IMPORT FROM DATABASE variant, the sytsem does not check whether the structures used in EXPORT and IMPORT correspond.

The return code is set as follows:

SY-SUBRC = 0:

Data objects imported.

SY-SUBRC = 4:

Unable to import data objects.

The ABAP memory was probably empty.

The contents of all listed objects remain unchanged.

Notes

You should always use addition 3 /... ID key) with this statement. Variants that do not use this addition have unpredictable effects ( EXPORT statements in different parts of programs can overwrite each other's data in ABAP memory. These variants only exist for the sake of compatibility with R/2.

Please consult Data Area and Modularization Unit Organization documentation as well.

Addition 1

... = f (for each object you want to import)

Addition 2

... TO f (for each object you want to import)

Effect

Places the object in the field f.

Addition 3

... ID key

Effect

Only the data stored in ABAP memory under the key key is imported.

The return code is set as follows:

SY-SUBRC = 0:

Data objects imported.

SY-SUBRC = 4:

Data objects could not be imported.

You may have used an incorrect ID.

The contents of all listed objects remain unchanged.

Related

EXPORT TO MEMORY, FREE MEMORY

Variant 2

IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.

Additions:

1. ... = f (for each object you want to import)

2. ... TO f (for each object you want to import)

3. ... CLIENT g (before ID key )

4. ... USING form

5. ... TO wa (as last addition or after dbtab(ar))

6. ... MAJOR-ID id1 (instead of ID key)

7. ... MINOR-ID id2 (together with MAJOR-ID id1)

In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Implicit field names not allowed in clusters and Table work areas not allowed.

Effect

Imports data objects obj1 ... objn (fields, structures, complex structures, or tables) from the data cluster with the ID key in area ar of the database table dbtab (compare EXPORT TO DATABASE).

The return code is set as follows:

SY-SUBRC = 0:

Data objects imported.

SY-SUBRC = 4:

Data objects could not be imported.

You may have used an incorrect ID.

The contents of all listed objects remain unchanged.

Example

Importing two fields and an internal table:

TYPES: BEGIN OF TAB3_TYPE,

CONT(4),

END OF TAB3_TYPE.

DATA: INDXKEY LIKE INDX-SRTFD,

F1(4), F2 TYPE P,

TAB3 TYPE STANDARD TABLE OF TAB3_TYPE WITH

NON-UNIQUE DEFAULT KEY,

WA_INDX TYPE INDX.

INDXKEY = 'INDXKEY'.

IMPORT F1 = F1

F2 = F2

TAB3 = TAB3 FROM DATABASE INDX(ST) ID INDXKEY

TO WA_INDX.

Notes

You must have named the table dbtab listed in DATABASE in a TABLES statement (except in addition 7).

The structure of the fields, structures, and internal tables that you want to import must correspond to the objects exported to the dataset. Furthermore, the objects must be imported with the same names with which they were exported. If you do not do this, the import will fail, and a runtime error may occur.

Exception: The last field may be longer or shorter, as long as it has type CHAR. Likewise, you can add or remove CHAR fields at the end of the structure.

Addition 1

... = f (for each object you want to import)

Addition 2

... TO f (for each object you want to import)

Effect

Places the object in the field f.

Addition 3

... CLIENT g (before ID key)

Effect

The data is taken from client g (only for client-specific import/export databases).

Example

DATA: F1,

WA_INDX TYPE INDX.

IMPORT F1 = F1 FROM DATABASE INDX(AR) CLIENT '002' ID 'TEST'

TO WA_INDX.

Addition 4

... USING form

Note

This statement is for internal use only.

Incompatible changes or further developments may occur at any time without warning or notice.

Effect

The data is not read from the database. Instead, the subroutine form is called for each data record that would have been read from the database. This routine can use the key fields of the records that would have been read from the work area of the database table and write the procured data into the work area. The routine has the name <database table name>_<subroutine name>. It has one parameter that describes the operation mode (READ, UPDATE, or INSERT). The routine must set SY-SUBRC to indicate whether the function has been executed successfully.

Note

Runtime errors: Various runtime errors can occur, depending on the operands you use to import data:

Addition 5

... TO wa (last addition or after dbtab(ar))

Effect

Use this addition when you want to read user data fields that have been strored in the database. Instead of the table work area, the statement uses the specified work area wa. The target area must have the structure of the corresponding table dbtab.

Example

DATA WA LIKE INDX.

DATA F1.

IMPORT F1 = F1 FROM DATABASE INDX(AR)

CLIENT '002' ID 'TEST'

TO WA.

WRITE: / 'AEDAT:', WA-AEDAT,

/ 'USERA:', WA-USERA,

/ 'PGMID:', WA-PGMID.

Addition 6

... MAJOR-ID id1 (instead of ID key)

Addition 7

... MINOR-ID id2 (together with MAJOR-ID id1)

This addition is not allowed in an ABAP Objects context. See Generic ID not allowed.

Effect

Searches for a record with an ID whose first part corresponds to id1 and (if you also specify MINOR-ID id2) whose second part is greater than or equal to id2.

Variant 3

IMPORT obj1 ...objn FROM LOGFILE ID key.

Note

This statement is for internal use only.

Incompatible changes or further developments may occur at any time without warning or notice.

Additions:

1. ... = f (for each field f you want to import)

2. ... TO f (for each field f you want to import)

In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Implicit field names not allowed in clusters

Effect

Imports data objects (fields, structures, or internal tables) from the update data. You must specify the update key assigned by the system (with the serial request number).

The return code is set as follows:

SY-SUBRC = 0:

Data objects imported.

SY-SUBRC = 4:

Data objects could not be imported.

You may have used an incorrect ID.

The contents of all objects listed in the statement remain unchanged.

Addition 1

... = f (for each object you want to import)

Addition 2

... TO f (for each object you want to import)

Effect

Places the object in the field f.

Variant 4

IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.

Additions:

1. ... CLIENT g (before ID key)

2. ... TO wa (last addition or after dbtab(ar))

In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Table work areas not allowed.

Effect

Places a directory of the objects stored under the specified ID using EXPORT TO DATABASE in the internal table itab. itab may not have the type HASHED TABLE or ANY TABLE.

The return code is set as follows:

SY-SUBRC = 0:

Directory imported.

SY-SUBRC = 4:

Unable to import directory.

You may have used an incorrect ID.

The internal table itabmust have the same structure as the ABAP Dictionary structure CDIR (INCLUDE STRUCTURE).

Addition 1

... CLIENT g (before ID key)

Effect

Takes the data from client g (only if the import/export database is client-specific).

Addition 2

... TO wa (last addition, or after dbtab(ar))

Effect

Uses the specified work area wa instead of the table work area. The table dbtab specified after DATABASE does not, in this case, have to be declared in a TABLES statement. The specified target area must have the same structure as dbtab.

Example

Directory of a cluster consisting of two fields and an internal table.

TYPES: BEGIN OF TAB3_LINE,

CONT(4),

END OF TAB3_LINE,

BEGIN OF DIRTAB_LINE.

INCLUDE STRUCTURE CDIR.

TYPES END OF DIRTAB_LINE.

DATA: INDXKEY LIKE INDX-SRTFD,

F1(4),

F2(8) TYPE P decimals 0,

TAB3 TYPE STANDARD TABLE OF TAB3_LINE,

DIRTAB TYPE STANDARD TABLE OF DIRTAB_LINE,

INDX_WA TYPE INDX.

INDXKEY = 'INDXKEY'.

EXPORT F1 = F1

F2 = F2

TAB3 = TAB3

TO DATABASE INDX(ST) ID INDXKEY " TAB3 has 17 entries

FROM INDX_WA.

...

IMPORT DIRECTORY INTO DIRTAB FROM DATABASE INDX(ST) ID INDXKEY

TO INDX_WA.

DIRTAB subsequently has the following contents:

NAME OTYPE FTYPE TFILL FLENG

-


F1 F C 0 4

F2 F P 0 8

TAB3 T C 17 4

Meanings of the individual fields:

NAME:

Name of the object

OTYPE:

Object type (F: field, R: structure / ABAP Dictionary structure, T: internal table)

FTYPE:

Field type (C: character, P: packed, ...)

Structures and internal tables have type C.

TFILL:

Number of filled lines in an internal table

FLENG:

Length of the field in bytes

For internal tables: Length of the header line.

Variant 5

IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.

This variant is not allowed in an ABAP Objects context. See Clusters not allowed in files

Note

Do not use this variant.

Note

Catchable runtime errors

The following catchable runtime errors can occur with this variant:

EXPORT_DATASET_CANNOT_OPEN: The EXPORT/IMPORT statement could not open the file.

OPEN_DATASET_NO_AUTHORITY: No authorization to access a file.

Variant 6

IMPORT obj1 ... objn FROM SHARED BUFFER dbtab(ar) ID key.

Additions:

1. ... = f (for each object you want to import)

2. ... TO f (for each object you want to import)

3. ... CLIENT g (before ID key)

4. ... TO wa (last addition or after dbtab(ar))

In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See No implicit field names allowed in clusters and Table work areas not allowed.

Effect

Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from the cross-transaction application buffer. The data objects are read from table dbtab using the ID key from area ar (see EXPORT TO SHARED BUFFER).

The return code is set as follows:

SY-SUBRC = 0:

Data objects imported.

SY-SUBRC = 4:

Unable to import data objects.

You may have used an incorrect ID.

The contents of all data objects listed in the statement remain unchanged.

Example

Importing two fields and an internal table from the application buffer with the structure indx:

TYPES: BEGIN OF ITAB3_LINE,

CONT(4),

END OF ITAB3_LINE.

DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',

F1(4),

F2(8) TYPE P DECIMALS 0,

ITAB3 TYPE STANDARD TABLE OF ITAB3_LINE,

INDX_WA TYPE INDX.

  • Import data

IMPORT F1 = F1 F2 = F2 ITAB3 = ITAB3

FROM SHARED BUFFER INDX(ST) ID INDXKEY TO INDX_WA.

  • After the import, the fields before CLUSTR

  • (INDX-AEDAT and INDX-USERA) are filled with the

  • values they had before the corresponding EXPORT

  • statement.

Notes

The table dbtab specified after DATABASE must be declared under TABLES (except in addition 2).

The structures of the fields, structures, and internal tables you want to import must be the same as those fo the objects you exported. The EXPORT and IMPORT statements (unlike IMPORT FROM DATABASE statement) does not check that they are the same. If the structures are not the same, a runtime error may occur if invalid assignments are attempted during the operation. The objects must also be imported using the same name as that with which they were exported. Otherwise, nothing is imported.

Please consult Data Area and Modularization Unit Organization documentation as well.

Addition 1

... = f (for each field you want to import)

Addition 2

... TO f (for each field you want to import)

Effect

Places the object in field f.

Addition 3

... CLIENT g (before ID key)

Effect

Takes the data from client g (if the import/(export table dbtab is client-specific).

Addition 4

... TO wa (as last addition or after dbtab(ar))

Effect

Use this addition if the application buffer contains user data fields that you want to read. Instead of the table work area, the system uses the specified work area wa. The target area you specify must have the same structure as dbtab.

Example

DATA: INDX_WA TYPE INDX,

F1.

IMPORT F1 = F1 FROM SHARED BUFFER INDX(AR)

CLIENT '001' ID 'TEST'

TO INDX_WA.

WRITE: / 'AEDAT:', INDX_WA-AEDAT,

/ 'USERA:', INDX_WA-USERA,

/ 'PGMID:', INDX_WA-PGMID.

Variant 7

IMPORT (itab) FROM ... .

Effect

Specifies the objects you want to import in the internal table itab. You can use this variant instead of the static object list in the following variants: " ... FROM MEMORY", "... FROM DATABASE ", " ... FROM DATASET" und "... FROM SHARED BUFFER". Any additions that are valid in the static cases can also be used here. The table itab may not have the type HASHED TABLE or ANY TABLE.

Note

Structure of the internal table itab:

The first column of the table contains the object name in the data cluster (corresponds to obj1 ... objn from the static case. The second column contains the different name in the program (if necessary), and corresponds to f in the FROM f addition. If the table has only one column, or the second column contains only blanks, the statemeht is the equivalent of a static IMPORT with no TO addition. Both the first and the second columns should have the type character.

Example

TYPES: BEGIN OF OBJ_LINE,

CLUSTERNAME(30),

PROGRAMNAME(10),

END OF OBJ_LINE,

BEGIN OF B_LINE,

FIELD_1 TYPE I,

FIELD_2(1) TYPE N,

END OF B_LINE.

DATA: OBJ_TAB TYPE STANDARD TABLE OF OBJ_LINE,

OBJ_WA TYPE OBJ_LINE,

B_PROG TYPE STANDARD TABLE OF B_LINE,

B_WA TYPE B_LINE,

A(10),

C_PROG LIKE SYST.

MOVE: 'A' TO OBJ_WA-CLUSTERNAME.

APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.

MOVE: 'B' TO OBJ_WA-CLUSTERNAME,

'B_PROG' TO OBJ_WA-PROGRAMNAME.

APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.

MOVE: 'C' TO OBJ_WA-CLUSTERNAME,

'C_PROG' TO OBJ_WA-PROGRAMNAME.

APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.

IMPORT (OBJ_TAB) FROM MEMORY ID 'ABCD'.

The dynamic EXPORT statement corresponds to the static IMPORT statement.

IMPORT A = A B = B_PROG C = C_PROG FROM MEMORY ID 'ABCD'.

Places the single field A in field A, the internal table B in the internal table B_PROG, and the structure C in the structure C_PROG.

Note

Runtime errors:

DYN_IMEX_OBJ_NAME_EMPTY: The object name in the cluster (that is, the contents of the first column of obj_tab) is empty.

DYN_IMEX_OBJ_NAME_TWICE: An object name (in the cluster) occurs twice in the first column of the internal table.

DYN_IMEX_OBJ_NOT_FOUND: The data object in the program (the object whose name appears in column 2, if this is not empty, otherwise in column 1) does not exist.

The return code is set as follows:

SY-SUBRC is set in the same way as for the static IMPORT.

Note

General notes about catchable runtime errors

The variants

IMPORT obj1 ... objn FROM MEMORY,

IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key,

IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key,

IMPORT obj1 ... objn FROM SHARED BUFFER dbtab(ar) ID key,

IMPORT (itab) FROM ... ,

can cause the following catchable runtime errors:

CONNE_IMPORT_WRONG_COMP_LENG: A component in the dataset has an incorrect length

CONNE_IMPORT_WRONG_COMP_TYPE: A component in the dataset has an incorrect type

CONNE_IMPORT_WRONG_FIELD_LENG: A field in the dataset has the wrong length

CONNE_IMPORT_WRONG_FIELD_TYPE: A field in the dataset has the wrong type

CONNE_IMPORT_OBJECT_TYPE: Type conflict between a simple and a structured data type

CONNE_IMPORT_WRONG_STRUCTURE: Type conflict between structured objects

IMPORT_ALIGNMENT_MISMATCH: Same sequence of components in different structures

IMPORT_TYPE_MISMATCH: Only with IMPORT...FROM MEMORY | FROM SHARED BUFFER...

athavanraja
Active Contributor
0 Kudos

<i><b>What does memory ID' PPT', 'PPI' and 'PPS' signify.</b></i>

these are pointer to the memory address where those variables values are stored.

<i><b>how and from where this get stored?</b></i>

this would have got exported from another program or within the same program but within the same SESSION.

EXPORT XXXX to meory id <memory ID> .

Regards

Raja