Skip to Content

ABAP Geek 6 – Jam(med) Sessions

ABAP memory organization part2. Internal session internals.

This Blog continues ABAP Geek 5 –  In Memory of …. It digs deeper into ABAP’s memory by explaining how an internal session is organized. Maybe one or the other might gain deeper insight from that.

Internal Session

From last ABAP Geek 5 –  In Memory of … you know, that each program call (SUBMIT, CALL TRANSACTION, LEAVE TO TRANSACTION) opens an Internal Session in a Main Session. It depends from the program call, if a preceding Internal Session is deleted or stacked to become part of a call sequence. The ABAP Memory is used to pass data between programs of a call sequence.

Main Program Group

Every time an Internal Session is created, its Main Program Group is created. What is a Program Group? A Program Group is an organizational unit of programs in the internal session. There is always a main program group and it is possible to have several additional program groups. Each program group has a main program and can have additional programs. The runtime of the main program in the main program group determines the lifespan of the entire internal mode.

Additional Program Group

This is created when a function group or a class pool is loaded into the internal session. A function group is loaded by means of an external procedure call. A class pool is loaded by usage of its global class (execution of the static constructor). The function group or class pool is the main program of the additional program group. An additional program group, its programs and data are retained for the entire duration of the internal session.

Main Program of a Program Group

The first program of a program group. The first program  that is loaded by a program call (SUBMIT, CALL TRANSACTION, LEAVE TO TRANSACTION) into an internal mode is the main program of the main program group. The program (function group or class pool) – for which an additional program group is created when it is loaded – is the main program of the additional program group.

Additional Programs of a Program Group

All programs, that are loaded via an external subroutine call (PERFORM) become additional programs of the caller’s program group. Exceptions of that rule are function groups. Loading a function group always creates a new program group.

Named Data Objects

All global data objects of all programs in an Internal Session are part of the Internal Session. The named data objects of a specific program (declared by DATA etc.) are created, when the program is loaded and are statically visible for their program only. Exceptions are the so called interface work areas (see below). The global data objects of a program live as long as the Internal Session. When you call procedures of a program several times, they always work with the same global data.

Objects

Objects (instances of classes) are part of the Internal Session. They are visible to and can be used by all programs and objects of the same internal session. You do so, by passing references between programs and objects. An object lives as long as there are references to the object.

Anonymous Data Objects

Anonymous data objects are created by a CREATE DATA statement and can be addressed using reference variables. They are handled like objects. The only difference is, that objects are instances of object types (classes) and anonymous data objects are instances of data types.

Interface Work Areas

Interface work areas are a dangerous and tricky thing. They are declared with the (partly obsolete) statements TABLES, NODES and the (obsolete) addition COMMON PART of the DATA statement. Interface work areas are created only once per program group and are equally accessed from all programs in a program group.

Important Note: The assignment of a program to a program group depends on the call sequence. Therefore, it depends from user interaction and so on, which interface work areas a program might work with.

Dynpros, Lists, and GUI Status

With CALL SCREEN, you always call the Dynpros of the main program of the current program group. Directly after creating an Internal Session, you call the Dynpros of the main program of the main program group. In additional program groups, only function groups can call their own Dynpros. As a rule, a GUI Status set with SET PF-STATUS is also taken from the program group’s main program. Last but not least, ABAP Lists are always linked to the current Dynpro sequence and therefore also belong to the main program of a program group. As a result, when you work with screens in externally called subroutine, you normally never work with the Dynpros and GUI Status in the subroutines own program, but you execute the dialog modules and list event blocks of the program group’s main program.

Bottom line

Everything that is complex and ambiguous in this blog comes from external subroutine calls.

Without external subroutine calls we would not need the term program group at all!

Don’t use them …

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Scott Barden
    In my opinion, a welcome change for ABAP was when it was no longer necessary to declare tables being accessed in the TABLES declaration section.  Much better for controlling the scope of variables and isolation of logic.  However I find it odd that one still needs to use the TABLES declaration when defining select-options variables.

    For example, often I’ll want to code something like below, but it requires me to add table T001 with the TABLES statement.

    SELECT-OPTIONS:
      s_bukrs        FOR t001-bukrs.

    Now I know that I could use a variable like GV_BUKRS instead, but the point remains that I have to declare an unwanted variable or table work area.

    I am aware of the historical reason for this coupling of a select-options variable to another variable (ie. for the CHECK SELECT-OPTIONS statement), but in my experience this is very rarely used and I’m sure it could be worked around.  For example, perhaps the variable coupling requirement could be dropped for select-options defined using:

    SELECT-OPTIONS:
      s_bukrs TYPE RANGE OF t001-bukrs.

    And while I’m on the topic, why are we stuck with select-option and parameter variable names being a maximum of 8 characters when other things like program name lengths have been increased?  Makes for less-readable code.

    Gripe over (I really do like the language 🙂

    Regards,
    Scott

    (0) 
  2. Scott Barden
    In my opinion, a welcome change for ABAP was when it was no longer necessary to declare tables being accessed in the TABLES declaration section.  Much better for controlling the scope of variables and isolation of logic.  However I find it odd that one still needs to use the TABLES declaration when defining select-options variables.

    For example, often I’ll want to code something like below, but it requires me to add table T001 with the TABLES statement.

    SELECT-OPTIONS:
      s_bukrs        FOR t001-bukrs.

    Now I know that I could use a variable like GV_BUKRS instead, but the point remains that I have to declare an unwanted variable or table work area.

    I am aware of the historical reason for this coupling of a select-options variable to another variable (ie. for the CHECK SELECT-OPTIONS statement), but in my experience this is very rarely used and I’m sure it could be worked around.  For example, perhaps the variable coupling requirement could be dropped for select-options defined using:

    SELECT-OPTIONS:
      s_bukrs TYPE RANGE OF t001-bukrs.

    And while I’m on the topic, why are we stuck with select-option and parameter variable names being a maximum of 8 characters when other things like program name lengths have been increased?  Makes for less-readable code.

    Gripe over (I really do like the language 🙂

    Regards,
    Scott

    (0) 
  3. Scott Barden
    In my opinion, a welcome change for ABAP was when it was no longer necessary to declare tables being accessed in the TABLES declaration section.  Much better for controlling the scope of variables and isolation of logic.  However I find it odd that one still needs to use the TABLES declaration when defining select-options variables.

    For example, often I’ll want to code something like below, but it requires me to add table T001 with the TABLES statement.

    SELECT-OPTIONS:
      s_bukrs        FOR t001-bukrs.

    Now I know that I could use a variable like GV_BUKRS instead, but the point remains that I have to declare an unwanted variable or table work area.

    I am aware of the historical reason for this coupling of a select-options variable to another variable (ie. for the CHECK SELECT-OPTIONS statement), but in my experience this is very rarely used and I’m sure it could be worked around.  For example, perhaps the variable coupling requirement could be dropped for select-options defined using:

    SELECT-OPTIONS:
      s_bukrs TYPE RANGE OF t001-bukrs.

    And while I’m on the topic, why are we stuck with select-option and parameter variable names being a maximum of 8 characters when other things like program name lengths have been increased?  Makes for less-readable code.

    Gripe over (I really do like the language 🙂

    Regards,
    Scott

    (0) 
  4. Christian Finkbeiner
    Am I wrong or does the way of memory allocation depend on the type of WP (Batch or Dialog)?

    And if so – it seems to have no impact on how the memory is organized considering the different programs otherwise you would have mentioned it, right?
    Christian

    (0) 
    1. Horst Keller Post author
      Hi,

      the principles of memory organization as explained in the blog are the same for all types of programs and all types of programm execution.

      In detail there are in fact some differences between Batch and Dialog processing, which do not alter the big picture.

      Horst

      (0) 
  5. Christian Finkbeiner
    Am I wrong or does the way of memory allocation depend on the type of WP (Batch or Dialog)?

    And if so – it seems to have no impact on how the memory is organized considering the different programs otherwise you would have mentioned it, right?
    Christian

    (0) 
    1. Horst Keller Post author
      Hi,

      the principles of memory organization as explained in the blog are the same for all types of programs and all types of programm execution.

      In detail there are in fact some differences between Batch and Dialog processing, which do not alter the big picture.

      Horst

      (0) 
  6. Christian Finkbeiner
    Am I wrong or does the way of memory allocation depend on the type of WP (Batch or Dialog)?

    And if so – it seems to have no impact on how the memory is organized considering the different programs otherwise you would have mentioned it, right?
    Christian

    (0) 
    1. Horst Keller Post author
      Hi,

      the principles of memory organization as explained in the blog are the same for all types of programs and all types of programm execution.

      In detail there are in fact some differences between Batch and Dialog processing, which do not alter the big picture.

      Horst

      (0) 

Leave a Reply