Related to previous post..

Question

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.

Answer 1

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...