Wednesday 22 March 2023

SAP Basis administration - ABAP Dump st22 "Dump ZDATE_LARGE_TIME_DIFF"

ABAP Dump st22  "Dump ZDATE_LARGE_TIME_DIFF"  


Purpose:

Large time difference between the Application server and the Database server.














Procedure:

The short dump ZDATE_LARGE_TIME_DIFF occurs when a time difference is found within a work process or when it happens between an Application server and a Database server. When this happens, the only way to resolve the issue is to restart the system.

Go through Notes: 102088, 697353 and 101726 which address the issue. Run RSDBTIME according to the note and check the result.

The explanation of this dump is described in note: 447839 - ZDATE_ILLEGAL_LOCTIME.


To solve the problems proceed as follows:


1: Setting the UTC timer" 

  a: Stop database and R/3

  b: Log on as Superuser (root).

  c: Set the General Mean Time (GMT) time zone (Greenwich time) for example in the C-shell with 'setenv TZ GMT'.

 d: Display the time with 'date'

The time displayed must match Greenwich time.

Greenwich time is 2 hours behind compared to Central European Summer Time and 1 hour compared to Central European Winter Time.


If this is not the case, you must correct the UTC timer with 'date'.

Caution: you must enter the correct Greenwich time here


The UTC timer is now correctly set.

2. Setting the time zone:


Log on as the user for which you want to make or check the time zone setting, for example ora<sid> or <sid>adm

Display the time with 'date'. The displayed time must match the local time, both in daylight saving time and standard time.

If this is not the case, you must set a correct time zone, for example with C-shell 'setenv TZ <zeitzone>'

In you have questions regarding the correct time zone, contact your operating system manufacturer.


Make sure that the correct time zone is set automatically in the login script of the user in question.

It is even better to configure the correct time zone as a default in the operating system. You then do not need to set a time zone in the login script.

Make sure that processes which are not started in the normal login (for example via 'rexec', 'cron') also have a correct time zone setting. With rexec, an R/3 instance is started if it is started from the CCMS system monitor (RZ03) or an R/3 start-up profile or a computer (instead of 'local').

The time zone is now set correctly for the databases and R/3 processes.


3. Check the settings to R/3:


Start the database (DB) and R/3

Start the R/3 report RSDBTIME, all times should now be displayed correctly.

If times are displayed incorrectly, check the time zone setting in the environment variable TZ of the DB shadow processes and the R/3 processes, for example with 'ps eww <prozessnumber' or a suitable monitor of the operating system. 'ps' shows the contents of environment variables, however only in the Berkeley(BSD) mode that does not exist on all UNIX derivatives. If you have questions contact your operating system manufacturer.


Thanks 

Rupesh Chavan