SAP Archives » Page 13 of 40 » Musings of an IT Implementor

SAP Applications – Daylight Saving to Standard Time

On the outset, this seems like something that should have been covered plenty of times before. However, you’d be surprised at the complexity of this simple operation.
We’re going to go through the options for how this can be achieved and show a scenario based on a company operating in the CET (Central European Time) timezone.
What’s the deal with the time changing?
I’m sure you will already know this, but just to recap for the sake of completeness:

In Europe (America is different) on the last Sunday of March, the northern hemisphere begins summer time. In our scenario, CET is swapped for CEST (Central European Summer Time).
CEST = CET + 1 hour.
In Europe (America is different) on the last Sunday of October, the process reverses. We swap CEST for CET. So we go back in time one whole hour.
On the last Sunday of October, at 02:59:59, the next second changes the time to become 02:00:00 again (it goes back one hour).
This is known as the double hour.
The period from 02:00:00 to 02:59:59 is known as the double hour period because those times are seen twice in the same day.
The double hour period causes some SAP applications problems because they are not able to adequately record the double hour period within their transactional processing capability. Simple example, a bank transaction record is recorded as happening at 2:15am, but which 2:15am during the double hour period?

So that’s the problem.
The common solution is stop the SAP system during the double hour period.
I’ve seen and heard of a raft of different requirements for solving this.
Some companies stop the system starting at 1:30am, some don’t stop it until 2:30am (the first 2:30am). Some stop the whole SAP landscape including the database and some stop just the SAP application layer.
What does SAP and the SAP notes say on this?
There are a few resources to help you decide what you need to do:

SAP Note 7417 “Conversion between standard time and daylight saving time”
SAP Note 102088 “Reducing downtime when chaning from summer to winter time”

Based on the notes, we can see there are 3 options available to us:

SAP downtime for just over 2 hours.
SAP extended time.
SAP minimal downtime for just over 1 hour.

Let’s highlight the options.

SAP downtime for just over 2 hours.
This is the standard approach and the approach recommended in the SAP notes, because it is the safest, catch-all approach.
You simply need to stop the SAP application layer before 02:00:00 and keep the system shutdown during the double hour period. Starting the SAP system back up again after 03:00:00.
During this approach, the databases can remain online, so why not do some DB maintenance…

SAP extended time.
In SAP Kernel 6.40 back in 2004 sometime, SAP introduced a new parameter and a capability within the Kernel which would automatically adjust the SAP system time, compared to normal clock time.

The new parameter is automatically activated (“ON”) by default.
On the day of the time change, at 02:00:00, the SAP Kernel starts to slow down the SAP system time, so that by 02:59:59 (clock time) the SAP system time is 30 mins slower (SAP time would be 02:30:00). Then after the clock time resets back 1 hour to 02:00:00, the SAP Kernel starts to slowly speed up the SAP system time again, so that at 03:00:00, both the clock time and the SAP system are synchronised again.
This method means that the SAP application never sees the double hour.

Sounds great. No need to stop the SAP system.
There are potential issues with ABAP code that compares the O/S time with the SAP system time (SY-UZEIT/SY-DATUM).

SAP note 7417 states that this “SAP extended time” option is only supported by SAP applications that are listed in the “referenced by” section of SAP note 7417.
There are no SAP applications listed in the “referenced by” section of SAP note 7417!!
There is SAP note 1454474 which specifically mentions issues with the double hour during a BW extract in an ECC system. In this note, the solution is to stop the SAP system. So it would appear that ECC is definately not capable of using this “SAP extended time” option.

SAP minimal downtime for just over 1 hour.
We talked about stopping the SAP system for just over 2 hours. This option is a modification on that option, but it needs some timezone alignment in the technology stack of the SAP system.
If your server timezone is CET, and the O/S locale timezone for your SAP application owner (e.g. <sid>adm) is also CET and your SAP system timezone is CET, then you are aligned.

If you have alignment of the timezone as mentioned above, then it means that all the technical layers will switch time at the same time.
This is difficult to explain, but imagine the O/S timezone was BST (British Summer Time) and the SAP system timezone was CEST, the CEST timezone is 1 hours ahead of BST. This means that first CEST would switch to CET then one hour later, BST switches to GMT (Greenwich mean time). The problem here is that without alignment, the SAP system would potentially have issues with ABAP code that compares the O/S time with the SAP system time (SY-UZEIT/SY-DATUM).

With alignment, you can potentially reduce the downtime to just over 1 hour because you know for certain that your SAP system experiences only 1 double hour period.

Before 02:00:00, you must disable the dynamic “SAP extended time” parameter “zdate/DSTswitch_contloctime”, so that the SAP system does not start to slow it’s system time.
Then you can stop the SAP application layer before 02:59:59 and start it up safely after 03:00:00 (a 1 hour downtime).
During this approach, the databases can remain online, so why not do some DB maintenance…

SUMMARY
For SAP Business Suite (and S/4), there are only really two options: ~ 2 hours of downtime or ~1 hours of downtime.
To use the 1 hour downtime option, there is a dependency on your timezone alignment of the technical layers.
To use the 2 hour downtime option, you must stop the SAP system before 02:00:00 or the SAP system will automatically have started to slow it’s system time which might cause you issues if you need to rely on timestamps outside the SAP system correlating with timestamps inside the SAP system.
For custom applications ontop of SAP Netweaver AS, if your ABAP code does not perform comparison of SY-UZEIT vs SY-DATUM, then you can probably use the “SAP extended time” option, but you should test it.

SAP Change Non-Dialog User to Dialog User Using Function Module

Scenario: The DDIC account is locked in a SAP system.
You don’t know the password to DDIC, and to get access as SAP* you would need to bounce the system, which is not acceptable during this period of business usage.
You’ve got the password to an existing account with profile SAP_ALL, but the account is a non-dialog user (system user or communication user).
You’ve got access to a development system where you can create SM59 RFC connections,
You would like to gain access to unlock and reset the DDIC account, without bouncing the system.

What we are doing in the below process, is changing the non-dialog user account, to become a dialog user account. We can then use the dialog account to logon to the SAP system and then unlock and reset the DDIC user account.

1, Log into the development SAP system as a user account that has SM59 access.
Create a new RFC connection to the destination SAP system (where DDIC is locked) set the authentication to use the non-dialog user account that has SAP_ALL.

2, In transaction SE37, from the menu select “Function Module -> Test -> Test Sequences“.

3, Set two function modules to execute, BAPI_USER_CHANGE followed by BAPI_TRANSACTION_COMMIT.

4, Execute function module BAPI_USER_CHANGE for the non-dialog user account, with “LOGONDATA” field “U” changed to value “A” (dialog user).
Set LOGONDATAX to “X”.
Set the destination to be the RFC destination you created.

5, Then execute function module BAPI_TRANSACTION_COMMIT.
Set the destination to be the RFC destination you created.

6, You can now log onto the target SAP system as the non-dialog user account (which is now a normal dialog user account).

7, You can now unlock the DDIC user and change the password.
Once completed, reset the non-dialog account back to be a non-dialog account.

As you can see, this is very easy to do.

To mitigate against this security threat:
– You should also look to prevent giving SAP_ALL to any SAP user accounts, even if they are non-dialog.
– Finally, you can also configure the RFC Access Control Lists (ACLs) to permit calls to specific function modules only.

SAP Secondary Oracle DB Connection–EasyConnect

When you run an SAP system on a non-Oracle database platform, you may sometimes need to connect to a secondary Oracle database (for example, in a SAP BW environment you could need a connection to multiple source database systems).

The process that is usually followed, is to create the TNSNAMES.ora in the appropriate location on *every* SAP application server of the SAP system. Then put the TNS service name and username/password into the DBCO transaction within SAP.

There are a couple of downsides to this approach:

1, You generally have to put the TNSNAMES.ora file in /sapmnt/<SID> as this is already shared across the SAP system’s application servers.

2, You have to keep the TNSNAMES.ora file updated. Any changes require a complete restart of the SAP system in order for the file to be re-read.

This is where the Easy Connect string can be used.
Instead of entering the TNS service name into the DBCO transaction, you simply enter all the service details, removing the need for the TNSNAMES.ora file.

An example of the Easy Connect string is:

“servervname.com:1521/tns-service-name”

We are supposing that:

– “tns-service-name” is the TNS service name for your target database (listened for on the target Oracle listener)
– Port 1521 (default port) is used by the listener.
– The server on which the listener is located is servername.com.

You must include the double quotes in the DBCO entry.

Based on the above entry, you can then dynamically change the value as and when needed.
No need for a restart of the SAP application server.

Reference: SAP note: 808505 – Secondary connections to Oracle database

Power Notes Searcher Updated to v2.0

I’ve finally managed to update the Power Notes Searcher to v2.0, which now supports the new SAP ONE support portal.
This is my free Google Chrome Extension to make life easier if you have to wade through a lot of SAP notes on a regular basis. This is my tried and trusted tool for 3 years now and it was time to provide an update.

Whilst the main features of Power Notes Searcher remain the same, a few notable features are:

– Highlighted note numbers can now be double clicked to open the note, even if it’s not an actual HTML link.
– Increased the history size to 150 notes.
– Smaller code base due to the use of the Google code compiler for JavaScript.
– Note content searches now highlight the note numbers without needing to initiate the search through the Power Notes Searcher popup.
– Collapsable settings area, simplifies the screen layout and increases viewing area for the history table.

I’ve also installed some basics into the code to provide for a future “tag” feature to allow notes to be tagged and organised in the history table.

What is: SAP AS Java Flight Recorder

In Solution Manager 7.1 “Managed System Configuration” step 7, you are requested to manually apply an instance profile parameter (jstartup/recorder) that configures the “Flight Recorder”:

The help for the item shows the following:

But the help doesn’t tell you what the Flight Recorder does and when you might use it.
So it was time to do a little research.

What does the flight recorder do?

Simply put, the flight recorder starts up only when a SAP Java server process (JVM) crashes (e.g. server0 crashes).
The flight recorder’s job is to gather up any available logs and traces and zip them up, before the system restarts the process.

Where are the dump zip files?

The zip files are stored by default in DIR_GLOBAL/dumps (e.g. /sapmnt/<SID>/global/dumps).
Typically the zip file is about 1-2MB in size and can contain around 1250 files.

What is included in a dump zip?

If you unzip a dump zip file, you will notice you get 3 different types of files extracted.
1– File system properties and config files, that were present on the file system at the time of the dump.
2– Database properties and config, that were stored in the database at the time of the dump.
3– Log files and traces, that were stored on the file system at the time of the dump.

Apart from looking in the DIR_GLOBAL/dumps area, trace or logs files, how can I see these dump zip files?

When you log into the System Info page of the Java server, you will see on the right hand side “Info for crashes of this node”:

https://<server>:5##00/monitoring/SystemInfo

How can we trigger a dump to see if this is all true?

Simple, we can just kill the server0 process like this:

DO NOT DO THIS IN PRODUCTION.

sidadm> ps -ef | grep server0

sidadm> kill 12345 <– This is the PID output from the previous command.

You will not really see the flight recorder process active, it’s very quick.
You will see the dump generated in the dumps folder.

Hopefully now, you can make use of the flight recorder.

“servervname.com:1521/tns-service-name”

sidadm> ps -ef | grep server0 sidadm> kill 12345 <– This is the PID output from the previous command.

sidadm> ps -ef | grep server0

sidadm> kill 12345 <– This is the PID output from the previous command.