Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

Package Directory Content for the One-Package Model
NOTE: In this document, references to ${SGCONF} can be replaced by the definition of the variable that
is found in this file /etc/cmcluster.config. The default values are:
• SGCONF=/opt/cmcluster/conf - for SUSE Linux
• SGCONF=/usr/local/cmcluster/conf - for Redhat Linux
In the one package model, the SAP functionality-database and central instance along with the highly available
NFS server have all been placed in one Serviceguard package. The following convention was used for the
postfix name:
• .config for the Serviceguard / SGeSAP/LX package configuration file
• .control.script for the Serviceguard / SGeSAP/LX package control script
The Serviceguard Extension for SAP on Linux scripts of the one package concept (dbci<SID>) one
additional SAP dialog instance (d<INSTNR><SID>) are organized as follows:
NOTE: All the following files reside in ${SGCONF}/<SID>/ except for ${SGCONF}/sap.functions
• ${SGCONF}/<SID>/dbci<SID>.config - Serviceguard generic package configuration file as
created with cmmakepkg -p. It needs to be customized.
• ${SGCONF}/<SID>/dbci<SID>.control.script - Serviceguard package control file as created
with cmmakepkg -s. It needs to be customized.
• ${SGCONF}/<SID>/d<INSTNR><SID>.config - Serviceguard generic package configuration file
as created with cmmakepkg -p. This file configures an optional application server package. It needs
to be customized. This file is optional.
• ${SGCONF}/<SID>/d<INSTNR><SID>.control.script Serviceguard SAP application server
package control file as created with cmmakepkg -s. It needs to be customized. This file is optional.
• ${SGCONF}/<SID>/sap.config - SAP specific package configuration file. It needs to be customized.
• ${SGCONF}/<SID>/customer.functions - contains all functions which can be modified for special
setups. This file may also contain your own additional functions. If there is a need to hotfix functions in
${SGCONF}/sap.functions, copy them over to ${SGCONF}/<SID>/customer.functions
and modify them there. Never modify ${SGCONF}/sap.functions itself. Any function provided in
customer.functions overrides its equivalent in sap.functions
• ${SGCONF}/<SID>/sapms.mon - SAP message service monitoring functions. This file is optional.
• ${SGCONF}/sap.functions - contains all standard runtime logic used by one package and two
package configurations. Do not modify this file.
• ${SGCONF}/<SID>/sapwas.sh provides the basic control flow for starting or stopping a SAP instance
through a set of function calls. These function calls themselves are defined in file
${SGCONF}/sap.functions. ${SGCONF}/sap.functions - contains all standard runtime logic
used by one package and two package configurations. Do not modify this file.
Use the one package concept for all configurations where you can put the database and central instance
on one node and have an equally sized node as a backup. During normal operation, backup nodes can
be used as an idle standby, application server host, or test system. If you are planning to distribute the
database and central instance on two nodes in the near future apply the two package concept.
26 Understanding Serviceguard Extension for SAP on Linux