ABAP Keyword Documentation

SAP NetWeaver AS ABAP Release 731, Copyright 2015 SAP AG. All rights reserved.

Introductory Statements for Programs

REPORT
PROGRAM
FUNCTION-POOL
CLASS-POOL
INTERFACE-POOL
TYPE-POOL

Introductory Statements for Programs

The introductory statements for programs are:

REPORT

PROGRAM

FUNCTION-POOL

CLASS-POOL

INTERFACE-POOL

TYPE-POOL.

The introductory statement of each program depends on the program type specified in the program attributes.
All statements that follow the introductory statements in the source code or are included as include programs
are handled as a single unit by ABAP Compiler.
The first statement of every independent ABAP program must be an introductory statement, and each program
can only contain one of these statements. The only other statement allowed in the first position (alongside the
introductory statement) is the INCLUDE statement. In this case, an introductory statement for a program must
appear in the first position of the program after the include program has been resolved when the program is
generated.
Executable programs, module pools, function groups, class pools, interface pools, subroutine pools, and type
groups are standalone compilation units. Include programs, on the other hand, are are only used in the context
of of compilation units.
Type groups, also known as type pools, are standalone programs from a logical point of view. However, they do
not contain executable code but only type definitions and constant definitions. For this reason, type groups
have their own introductory program statement, the TYPE-POOL.

Note
It is not obligatory, from a syntax point of view, to assign introductory program statements to the program types
defined in the program attributes. However, you should always use the assignments listed in the following
sections. When a program is created, the suitable statement is automatically generated by ABAP Workbench
and should be changed only in the additions, when editing. In particular, the keywords FUNCTION-POOL,
CLASS-POOL, INTERFACE-POOL, and TYPE-POOL should be created solely by the respective tools of ABAP
Workbench and never be entered in the source text themselves, in order to avoid unexpected system behavior.

REPORT
Short Reference

Syntax
REPORT rep [list_options]
[MESSAGE-ID mid]
[DEFINING DATABASE ldb]
[REDUCED FUNCTIONALITY].

Extras:
1. ... MESSAGE-ID mid
2. ... REDUCED FUNCTIONALITY
Effect
The statement REPORT introduces an executable program. It must be the first statement of a standalone
program after the triggering of possible include programs. You must specify the name rep directly. You can use
the optional addition list_options to influence the basic list of the program. A message class can be
specified using MESSAGE-ID.
The addition DEFINING DATABASE is used to define a logical database, whereas REDUCED FUNCTIONALITY
shoudl only be used for PROGRAM.
Notes

In the above statement, you can replace the key word REPORT with the key word PROGRAM. In
executable programs, PROGRAM means the same as REPORT and can be used with the additions of
REPORT. As a rule, only initiate executable programs using REPORT.

Although you do not absolutely need to specify the name rep, you should always use the name of the
ABAP program from the Repository.

Addition 1
... MESSAGE-ID mid

Effect
This addition specifies a message class mid that, in the program, allows the use of shortforms of the statement
MESSAGE in which only the message type and message number are specified. The message class must be
specified directly and appear in the column ARBGB of the database table T100. The variations of statement
MESSAGE, in which the message class is specified, override the addition MESSAGE-ID.
Example
Default setting of the message class Z_MY_MESSAGES for the program Z_MY_REPORT.
REPORT z_my_report MESSAGE-ID z_my_messages.

Addition 2
... REDUCED FUNCTIONALITY
Effect
This addition is only intended for the PROGRAM statement in subroutine pools.

REPORT - list_options
Short Reference

Syntax
... [NO STANDARD PAGE HEADING]
[LINE-SIZE width]
[LINE-COUNT page_lines[(footer_lines)]] ... .

Extras:
1. ... NO STANDARD PAGE HEADING
2. ... LINE-SIZE width
3. ... LINE-COUNT page_lines[(footer_lines)]
Effect

These additions influence the basic list of the program.

Addition 1
... NO STANDARD PAGE HEADING
Effect
This addition suppresses the output of the standard page header (standard header and column headers) on
the basic list of the program and sets the system field sy-wtitl to the value "N". You can overwrite this
setting during list creation with the additions NO-TITLE|WITH-TITLE and NO-HEADING|WITH-HEADING to
the NEW-PAGE statement.

Addition 2
... LINE-SIZE width
Effect
This addition specifies the line width of the basic list and details list of the program to width characters, and
sets the system field sy-linsz to this value. The line width determines the number of characters in the line
buffer as well as the number of columns in the list displayed. The value width must be specified directly as a
positive number. The maximum line width is 1023.
When the LINE-SIZE is not specified, the line width of the basic list is set to a standard width based on the
window width of the current Dynpro, but is at least as wide as a standard size SAP window. For the standard
width, the contents of sy-linsz is 0. The LINE-SIZE overwrites the value of the like-named LINE-SIZE
addition to the statement SUBMIT and can be overwritten during list creation with the like-named LINE-SIZE
addition to the statement NEW-PAGE.
Note
The current maximum line width is stored in the constants SLIST_MAX_LINESIZE of the type group SLIST.
Also defined there is a type SLIST_MAX_LISTLINE of type c with length SLIST_MAX_LINESIZE.

Addition 3
... LINE-COUNT page_lines[(footer_lines)]
Effect
This addition specifies the page length for the basic list of the program to page_lines lines and fills the
system field sy-linct with this value. If LINE-COUNT is not specified and for page_lines less than 0 or
greater than 60000, the page length is set internally to 60000. This setting overwrites the value passed by the
(similarly named) addition LINE-SIZE of the statement SUBMIT and can be overwritten when the list is created
by the (similarly named) addition LINE-COUNT of the statement NEW-PAGE.
If you choose to specify a number for footer_lines, a corresponding number of lines are reserved for the
page footer, which can be described in the event block END-OF-PAGE.
page_lines and footer_lines must be specified directly as positive numbers, where no sign can be
specified for footer_lines.

Notes

For screen lists, you should use the standard value since, as a rule, page breaks defaulted through
LINE-COUNT are not adjusted to the window size.

You should also use the standard value for print lists, so that you can still select the page size on a
printer-specific basis. A print list should be created in such a way that it provides satisfactory results for
any page size.

Specifying a fixed line count is only useful for form-like lists with a fixed page layout. Here, however,
you should always check whether such forms can be created by other means, such as SAPScript
forms.

Example
The page length of the basic list is set to 65 lines, eight of which are reserved for the page footer. The line width
is 132 characters.
REPORT z_myreport LINE-COUNT 65(8) LINE-SIZE 132.

PROGRAM
Short Reference

Syntax
PROGRAM prog [list_options]
[MESSAGE-ID mid]
[REDUCED FUNCTIONALITY].

Addition:
... REDUCED FUNCTIONALITY
Effect
The statement PROGRAM initiates a module pool or a subroutine pool. It must be the first statement of a
standalone program after the triggering of possible include programs. You must specify the name prog directly.
The following applies for the additions:

In module pools, the additions list_options and MESSAGE-ID of the PROGRAM statement have the
same meaning as the additions of the same name in the statement REPORT. The REDUCED
FUNCTIONALITY addition has an effect only in subroutine pools, otherwise it is ignored.

In subroutine pools, the specification of MESSAGE-ID has the same meaning as with the statement
REPORT.. The possible additions list_options for the basic list are ignored, since subroutine pools
do not have a separate list buffer. Output statements in subroutine pools write to the current list of the
calling main program. The addition REDUCED FUNCTIONALITY only works in subroutine pools..

Notes

In the above statement, you can replace the key word PROGRAM with the key word REPORT. In module
pools or subroutine pools, REPORT has the same meaning as PROGRAM and can be used with its
additions. As a rule, you should initiate module pools and subroutine pools only by using PROGRAM.

Although you do not absolutely need to specify the name prog, you should always use the name of
the ABAP program from the repository.

The name of a module pool is not fixed, but should follow the naming conventions in ABAP
Workbench. These specify that the name of module pools should start with "SAPM".

Addition
... REDUCED FUNCTIONALITY
Effect
This addition only has an effect in programs of the type subroutine pool. In a subroutine pool initiated with the
addition REDUCED FUNCTIONALITY, not all components that are usually loaded with an ABAP program are
loaded. This leads to a reduction in the program load and to a lower memory in the roll area. This means that
the full ABAP language range is not available.

The embedded structure syst is not loaded. Instead of syst, the structure sy with the same meaning
can be used.

The embedded structure screen is not loaded. The statements LOOP AT SCREEN and MODIFY
SCREEN are then not possible.

Editing is not possible with the dynpros of the main program of the current program group .

No support is available for list printing. The corresponding additions of the statements NEW-PAGE and
SUBMIT cannot be changed.

If none of the missing functionality is required, you can use the REDUCED FUNCTIONALITY addition to avoid
the unnecessary resource consumption of subroutine pools.
Notes

The REDUCED FUNCTIONALITY addition also works in subroutine pools which were created with
GENERATE SUBROUTINE POOL.

The use of REDUCED FUNCTIONALITY is especially recommended for small subroutine pools which
only contain simple help procedures

The use of REDUCED FUNCTIONALITY in a subroutine pool leads to a warning from the syntax check,
pointing out that the entire ABAP range is not available. If functionality which is not present is used,
corresponding syntax errors occur.

FUNCTION-POOL
Short Reference

Syntax
FUNCTION-POOL fpool [list_options]
[MESSAGE-ID mid].
Effect
The FUNCTION-POOL statement introduces a function group. After the expansion of any existing include
programs, it must be the first statement of a standalone program. The additions of the FUNCTION-POOL
statement have the same meaning as the additions of the REPORT statement.
You use the Function Builder of the ABAP Workbench to maintain the function groups. The Workbench
automatically generates a framework program and the include programs listed below. The FUNCTION-POOL
statement is created in a top include.
The complete name of a framework program of a function group in the Repository consists of the prefix SAPL
and the name fpool of the FUNCTION-POOL statement.
A function group serves as a frame for function modules and is organized in include programs as follows.

One top include with the prefix "L" and the ending "TOP" in the declaration section of the function
group.

Optional include programs with the prefix "L" and the ending "D.." for the declaration of local classes
within the top include.

One include program with the prefix "L" and the ending "UXX" in the implementation section of the
function group. This include program includes include programs with the ending "U.." for implementing
each function module of the function group. This structure must not be changed.

Optional include programs with the prefix "L" and the ending "P.." for implementing the methods of
local classes in the implementation section of the function group.

Optional include programs with the prefix "L" and the ending "O.." for implementing PBO modules in
the implementation section of the function group.

Optional include programs with the prefix "L" and the ending "I.." for implementing PAI modules in the
implementation section of the function group.

Optional include programs with the prefix "L" and the ending "E.." for implementing event blocks in the
implementation section of the function group.

Optional include programs with the prefix "L" and the ending "F.." for implementing subroutines in the
implementation section of the function group.

The periods ".." represent a two-digit number. The functionality of the Function Builder is based on
adherence to this naming convention.

Example
Function group SAPLABAP_DOCU is structured from include programs.
*&---------------------------------------------------------------------*
*& Function Group SAPLABAP_DOCU
*&---------------------------------------------------------------------*
INCLUDE labap_docutop.

" Global Declarations

INCLUDE labap_docue00.

" Load of Program

INCLUDE labap_docuuxx.

" Function Modules

INCLUDE labap_docuo01.

" PBO Modules

INCLUDE labap_docui01.

" PAI Modules

INCLUDE labap_docue01.

" Handling of Runtime-Events</

INCLUDE
INCLUDE
INCLUDE
INCLUDE

" Class implementations

labap_docup01.
labap_docup02.
labap_docup03.
labap_docup04.

The function group includes the top include in the first place; it contains the FUNCTION-POOL statement and
other include programs for data and class declarations:
*&---------------------------------------------------------------------*
*& Include
LABAP_DOCUTOP
*&---------------------------------------------------------------------*
FUNCTION-POOL abap_docu.
INCLUDE labap_docud00.

" Global Data for Screens

INCLUDE labap_docud01.

" Classes for Docu Display

CLASS-POOL

Short Reference

Syntax
CLASS-POOL [MESSAGE-ID id].
Effect
The CLASS-POOL statement introduces a class pool. It must be the first statement of a standalone program,
after any include programs have been called. The MESSAGE-ID addition of the CLASS-POOL statement has
the same meaning as for the REPORT statement.
Class pools are edited in Class Builder in ABAP Workbench. A framework program for a global class, and
associated include programs, are generated automatically. The statement CLASS-POOL is created in the
framework program.
The full name of the framework program of a class pool in the repository starts with the name of the global
class, is padded with the character "=" up to and including position 30, and ends with "CP".
The names of the include programs of a class pool included by the framework program are constructed in
exactly the same way as the name of the class pool itself, however they have different endings. Unlike the case
with function groups, the actual structure of a class pool constructed from include programs is the internal
responsibility of ABAP Workbench and the ABAP runtime environment and is not displayed in Class Builder.
Note
The statements permitted in a class pool are listed under Statements in Class Pools and Interface Pools.
Example
The name of the framework program of the class pool of the global class CL_ABAP_BROWSER is
CL_ABAP_BROWSER===============CP.

INTERFACE-POOL
Short Reference

Syntax
INTERFACE-POOL.
Effect
The statement INTERFACE-POOL introduces an interface pool. It must be the first statement of an independent
program after resolving possible include programs.

Interface pools are edited only with the tool Class Builder in ABAP Workbench. A framework program for a
global interface including the statement INTERFACE-POOL is generated automatically.
The full name of the framework program of an interface pool in the repository starts with the name of the global
interface, is padded with the character "=" up to and including position 30, and ends with "IP".
The names of the include programs of an interface pool included by the framework program are constructed in
exactly the same way as the name of the interface pool itself, however they have different endings. Unlike the
case with function groups, the actual structure of an interface pool constructed from include programs is the
internal responsibility of ABAP Workbench and the ABAP runtime environment and is not displayed in Class
Builder.
Note
The statements permitted in an interface pool are listed under Statements in Class Pools and Interface Pools.
Example
The name of the framework program of the interface pool of the global interface
IF_DEMO_CR_CAR_RENTL_SERVICE is IF_DEMO_CR_CAR_RENTL_SERVICE==IP.

TYPE-POOL
Short Reference

Syntax
TYPE-POOL tpool.
Effect
The TYPE-POOL statement introduces a type group. It must be the first statement of a type group following the
triggering of any include programs. You can maintain type groups only in ABAP Dictionary in ABAP Workbench,
whereby an ABAP program is automatically generated including the TYPE-POOL statement. The actual name
of the program of a type group in the repository does not completely match the name of the type group and is
of internal relevance only.
Type groups can only contain the statements

INCLUDE,

INCLUDE TYPE|STRUCTURE,

TYPES,

CONSTANTS,

DEFINE, and END-OF-DEFINITION,

CLASS DEFINITION ... DEFERRED PUBLIC

and the declared data types, constants, and macros must be prefixed with the name tpool of the type group.
The elements declared in a type group can be addressed statically or dynamically by name in every ABAP
program in which the type group can be used. This is loaded when an element of a type group is first accessed.
Notes

Types in type groups are the predecessors for general type definitions in ABAP Dictionary.

Since you can also define data types and constants in the public visibility section of global classes,
type groups are obsolete and should no longer be created. Existing type groups can still be used.

To avoid conflicts in the type reference with the addition LIKE, you must ensure that constants in type
groups do not have the same name as existing flat structures or database tables in ABAP Dictionary.

The name of a type group may contain a maximum of five characters.

Previously, type groups had to be made known in ABAP programs using the TYPE-POOLS statement
before its elements could be accessed statically or dynamically. This restriction is now obsolete. The
TYPE-POOLS statement is no longer necessary.

Example
Type groups with the definition of a table type.
TYPE-POOL mytgr.
TYPES mytgr_spfli_tab TYPE HASHED TABLE
OF spfli
WITH UNIQUE KEY carrid connid.