saptune 3.1.2 – Bugfixing and Note Updates

This month we released a maintenance update for saptune: 3.1.2
I was asked by to write s a short blog post about the changes. Here it is!

Reducing the lock scope

To avoid several saptune processes to run simultaneously and creating a mess, saptune always set a lock on start. Only one saptune command should run at the same time.
Back then, it was the easiest way to go. But like most times, going down the easiest road bites you later. 😉

With the recent Trento integration, it turned out that this approach does not work anymore.
A saptune command could fail, if it was called unfortunately at the same time when Trento collects the saptune status.

With 3.1.2 the lock only is set for commands that potentially change the system settings.
Nevertheless a set lock can cause Trento to report a wrong saptune status or causes saptune checks to fail. The following commands still set it:

• service start|stop|reload|enablestart|disabestop|apply|revert|takeover
• note|solution apply|customise|customize|create|edit|revert|delete|rename
• note revertall
• revert all
• solution change
• staging

Fixed log timestamps

We noticed a bug in the saptune logs, that incorrectly used the same timestamp for all log messages of the same saptune process. This has been fixed.

SAP Note Updates

We updated these SAP Note to the latest version:

• 1656250 to v63
• 1771258 to v8
• 2382421 to v45
• 3024346 to v10
• 2578899 to v47
• 1984787 to v42

Only 2578899 received a tuning change (kernel-default 5.14.21-150400.24.11.1 as minimum package version for 15 SP4 on ppc64le). For the others it was just a version number and release date update.

For these Notes we simply forgot to update the release information in an internally used comment string:

• 1410736
• 1805750
• 1868829
• 1980196
• 1557506
• 2205917
• 2161991
• 2534844
• 900929
• 941735

And for these we had to correct the date:

• 2684254
• 2993054

This was simply housekeeping and did not affect the tuning.