Skip to content

ABAP Keyword Documentation →  ABAP Programming Guidelines →  ABAP-Specific Rules →  Programm Type and Program Properties 

Program Attributes

Other versions: 7.31 | 7.40 | 7.54

Background

In addition to various, less important properties, each ABAP program has a set of program attributes that control specific aspects of the program behavior and syntax check severity:

  • Unicode checks active
    For creating a Unicode program.
  • Fixed point arithmetic
    For taking the decimal separator into account for operations with packed numbers.
  • Logical database
    For connecting an executable program with a logical database.

You define the program attributes when you create a program, by using the relevant tool (Class Builder, Function Builder, ABAP Editor). You can also change them later.

Rule

Use the default settings for program attributes

Set the program attributes for new programs as follows:

  • Unicode Checks Active activated
  • Fixed Point Arithmetic activated
  • No assignment to a logical database

These settings are the same as the default values when you create a new program. This means you can apply them without making any changes. Once the program attributes are set, you should not change them later on.

Details

Different behaviors or check severities are only provided for compatibility reasons, to ensure that existing programs can still be compiled and executed. New programs should definitely not use obsolete settings.

  • When you create a new program, the Unicode Checks Active attribute is already set by default. This attribute must never be reset. Activating the Unicode checks is the only way to ensure that the program can be executed in Unicode systems and in non-Unicode systems, and that the same results are returned in both cases. A program with activated Unicode checks is referred to as a Unicode program. A Unicode system represents an SAP system, where characters are displayed in Unicode format (ISO/IEC 10646). Currently: UTF-16 with platform-dependent byte order. On a Unicode system, you can only execute Unicode programs. However, Unicode programs can also be executed on non-Unicode systems. The programs provided by SAP are usually Unicode programs. When you prepare a non-Unicode system for the changeover to Unicode, you must implement all existing non-Unicode programs as Unicode programs. Activating the Unicode checks is only beneficial for the developer (for example, a more stringent static type check and a stricter separation of byte and character string processing).
  • When you create a new program, the Fixed Point Arithmetic attribute is already set by default. This attribute must never be reset. If fixed point arithmetic is deactivated, the position of the decimal separator of packed numbers (type p) is only taken into account for the display in a classical dynpro or for formatting with WRITE TO. The position is not taken into account for calculations. Today, this behavior only rarely meets the developer#s expectations. If the calculation is to be carried out with packed numbers without any decimal places, this must be specified using the DECIMALS 0 addition for the declaration.
  • When you create a new executable program, the Logical Database attribute is empty. This attribute assigns executable programs to a logical database. This allows you to combine the program selection screen and the program flow with the selection screen and flow of the logical database. A logical database is a special development object that is edited in Logical Database Builder and which provides other ABAP programs with data from the nodes of a hierarchical tree structure. A logical database has a hierarchical structure, an ABAP database program and a separate standard selection screen. Logical databases should no longer be used. This is because they are based on cross-program usage of global data, implicit subprogram calls and reporting event control, and therefore do not comply with modern concepts. The function module LDB_PROCESS can be used to access existing logical databases. This function module can be called from a method. You should not create new logical databases. Instead a relevant service should be made available using a global class.

Because a subsequent change to the program attributes potentially involves changeover effort, you should set the correct attributes right from the start and not change them later on. It is particularly important for attributes that influence the syntax check (currently the Unicode check) that you always choose the highest possible check severity. This ensures you are well prepared for any subsequent changeovers that may occur.

The following sections assume that you only work with the Unicode check and fixed point arithmetic set to activated and without the logical databases. These guidelines no longer contain a special rule for obsolete or problematic language constructs, which are only available if the Unicode checks are switched off. These constructs are only mentioned briefly in regard to the list of obsolete language elements.


Example

In the following source code, a write access to a subfield across two numeric components of a structure is executed.

METHOD ...
  DATA:
    BEGIN OF struct,
      comp1 TYPE i,
      comp2 TYPE i,
    END OF struct.
  struct+2(4) = 'XXXX'.
ENDMETHOD.

This is only possible in non-Unicode programs. Here an implicit casting of the subarea is performed for type c. The result in the components depends on the alignment gaps, the internal presentation of numeric values (byte order), and the code page used. Therefore, the result is extremely platform-dependent. A live program must never contain this type of code. This type of code often results in incorrect data or runtime errors that are difficult to trace.

The above code results in a syntax error, when used in an ABAP program where the Unicode Checks Active attribute is selected in the program properties (in accordance with the above rule). Unwanted subfield accesses are prohibited, just like any other unwanted accesses to structures or other parts of the working memory. If these accesses cannot be identified by the syntax check, a runtime error occurs with a descriptive short dump while the program is running.