Managing Serviceguard Extension for SAP Version B.05.10, September 2010

servers running on different nodes, any failure of the update server leads to subsequent outages
at these nodes. Configure the update server on a clustered instance. Using local update servers
should only be considered, if performance issues require it.
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 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, SGeSAP can be switched off like is described in 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 he will have two sets of SAP
central executables. In this case it is required to make sure that after 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.
The configuration of the SGeSAP specific parameters to modular_sap_pkg.config can then be
done manually according to the “Modular Package Configuration“ section of chapter 3.
Caution needs to be taken in clusters that alter any inofficial 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.
Most of SAPs business transactions are still written in ABAP, SAPs own programming language.
All programs are stored as source code in the database and translated at the first time of execution
180 SGeSAP Cluster Administration