Application Log and Unicode

It is possible to attach a context to a message or log header in the application log. This context consists of the name of a (flat) DDIC structure and its contents, which is held in a CHAR255 container.

The context is a DDIC structure with the name 'MY_STRUC', which contains the fields CARRID, CONNID and FLDATE:


l_s_msg TYPE bal_s_msg,

l_context TYPE MY_STRUC.

* fill message type, id and message variables


* define context information

l_context-carrid = 'ABC'.

l_context-connid = 15.

l_context-fldate = sy-datum.

l_s_msg-context-tabname = 'MY_STRUC'.

l_s_msg-context-value = l_context.

* add this message to log



i_s_msg = l_s_msg



The statement l_s_msg-context-value = l_context. causes problems in unicode systems if the DDIC structure contains fields that are non character-like (for example, the fields CONNID as INTEGER).

In principle, it could have been possible to completely convert this container mechanic for unicode conversion (for example, by introducing REF TO DATA as a reference to any context information). However, since most applications only operate with character-like contexts, a conversion of that kind was rejected. Instead, the following two options are available:

  1. Only use character-like fields in the DDIC structure. This procedure is recommended.

    This option can then be used, for example, if INTEGERs are used in the context. It is possible to convert relatively easily to NUMC. Coding can normally remain unchanged because moving an integer into an NUMC field automatically converts it.

    Furthermore, logs written in old releases can still be read. The old context data is automatically converted into the new structure when it is read.

  2. Work with ASSIGN .. CASTING.

If solution 1 cannot be applied and non character-like fields have to be used, you can proceed as follows:

The statement l_s_msg-context-value = l_context. can be replaced by:


<l_context> TYPE c.

ASSIGN l_context TO <l_context> CASTING.

l_s_msg-context-value = <l_context>.

Context data is still read/interpreted correctly in the application log.