Managing Serviceguard Extension for SAP Version B.05.10, December 2012

SGeSAP specific check routines which are not related with SAP requirements towards local operating
environment configurations are not deactivated and are executed as part of both
cmcheckconf(1m) and cmapplyconf(1m) commands.
Upgrading SAP Software
Upgrading the version of the clustered SAP application does not necessarily require changes to
SGeSAP. Usually SGeSAP detects the release of the application that is packaged automatically
and treats it as appropriate. Make sure that you have a valid SGeSAP version in place by issuing
the following command.
On HP-UX 11i v2 or higher type:
swlist -l bundle T2357BA T2803BA
Review the release notes of the SGeSAP version that gets reported and make sure that the target
SAP application release is supported with the SGeSAP version that is already installed. If this is
not the case, you should first get an update for the HP Serviceguard Extension for SAP installed
and activated before continuing.
For a safe upgrade of SAP with modular-style packages, put all impacted SGeSAP packages in
package maintenance mode and perform a partial package start before the first SGeSAP specific
module becomes executed. Now, you can manually handle the SAP startup or shutdown operations,
the upgrade happens without interference from the cluster software. SGeSAP can be switched off.
See the section below.
Perform failover tests for all potential failure scenarios before putting the system in production.
If the setup has a mixed cluster of PA-RISC and IPF nodes, then there will be two sets of SAP central
executables. In this case, make sure that after a successful upgrade on one platform, the second
kernel directory gets upgraded manually. Both kernel directories need to have the same kernel
revision and patch level.
Sometimes, upgrades come with additional configuration options. ASCS and Replicated Enqueue
is possible beginning with ABAP kernel 4.6. SCS instances are introduced with J2EE engine 6.40.
Refer to chapter 3 on how to configure packages for the additional components.
Package Conversion
The conversion of SGeSAP legacy configurations to SGeSAP module configurations requires manual
steps. Preparatory effort lies in the range of 1 hour per package.
The cmmigratepkg command can be applied to SGeSAP legacy packages. The output file will
lack SAP-specific package configurations of /etc/cmcluster/<SID>/sap*.config, but the
file can be used to simplify the creation of a modular SGeSAP package: cmmakepkg –i
<cmmigratepkg_output_file> -m sgesap/all >modular_sap_pkg.config.
Then, the configuration of the SGeSAP specific parameters to modular_sap_pkg.config can be
done manually according to the “Modular Package Configuration“ section of chapter 3.
Caution needs to be taken in clusters that alter any unofficial SGeSAP parameter that is not described
in the official product documentation and in clusters that use customized code as part of the SGeSAP
customer.functions hooks. In these cases, an individual analysis of the required steps is needed.
Any SAP procmap configuration of the WLM SAP toolkit must be removed before the conversion
and can be recreated afterwards.
Mixed Clusters
Platform changes from HP 9000 hardware to Integrity systems are complex and require a significant
investment. Changing the hardware for a multi-node cluster at once is an expensive undertaking.
It is possible to perform this change step by step, replacing only one server at once with SGeSAP.
During this transition phase, the cluster will technically have a mixed layout. However, from SAPs
perspective it's still a homogeneous HP-UX system.
Upgrading SAP Software 27