Managing Serviceguard Extension for SAP Version A.06.00 for Linux, December 2012

The debug mode allows package start up to the level of SAP specific steps. All instance startup
attempts will be skipped. Service monitors will be started, but they do not report failures as long
as the debug mode is turned on.
In this mode it is possible to attempt manual startups of the database and/or SAP software. All
rules of manual troubleshooting of SAP instances now apply. For example it is possible to access
the application work directories of the SAP instance to have a look at the trace files.
CAUTION: Make sure that all debug flag files become removed before a system is handed back
to production use.
NOTE: Using partial package startup can likewise be used as SAP startup troubleshooting method.
The debug behavior is different from package maintenance mode. In package maintenance mode,
the debug file does not disable package failover or allow partial startup of the package, but allows
a package in running state. Startup with debug mode starts all the SGeSAP service monitors, except
the monitored application software. The monitors suspend execution until the debug file is removed.
It is not required to halt the package before package operations can be tested. If a package halt
operation is prompted while the debug file exists, all SAP specific routines in the package shutdown
logic are executed. Clustered SAP software components that were absent during package startup
in debug mode, but manually started during subsequent debugging operations are stopped with
the standard package halt routines.
Make sure to remove the debug file at the end of the debugging operations. If the package still
runs, all monitors begins to work immediately and the package failover mechanism is restored.
SAP software changes
During installation of the SGeSAP Integration for SAP releases with kernel < 7.0, SAP profiles are
changed to contain only relocatable IP-addresses for the database as well as the Central Instance.
You can check these using transaction RZ10. In file DEFAULT.PFL these entries are altered:
SAPDBHOST = <relocatible_db_name>
rdisp/mshost = <relocatible_ci_name>
rdisp/vbname = <relocatible_ci_name>_<SID>_<INR>
rdisp/enqname = <relocatible_ci_name>_<SID>_<INR>
rdisp/btcname = <relocatible_ci_name>_<SID>_<INR>
rslg/collect_daemon/host = <relocatible_ci_name>
The additional profile parameters are SAPLOCALHOST and SAPLOCALHOSTFULL, that are included
as part of the Instance Profile of the Central Instance. Anywhere SAP uses the local hostname
internally, this name is replaced by the relocatable values <relocatable_ci_name> or
<relocatable_ci_name>.domain.organization of these parameters. Make sure that they
are always defined and set to the correct value. This is vital for the system to function correctly.
Relocatable IP addresses can be used consistently beginning with SAP kernel 6.40. Older releases
use local hostnames in profile names and startup script names. Renamed copies of the files or
symbolic links exist to overcome this issue.
The destination for print formatting, which is done by a Spool Work process, uses the Application
Server name. Use the relocatable name if you plan to use Spool Work processes with your Central
Instance. In these cases no changes need to be done in case of a failover—printing will work
persistently.
NOTE: Any print job in process at the time of the failure is canceled and required to be reissued
manually after the failover. To make a sprint spooler highly available in the Central Instance, set
the destination of the printer to <relocatible_ci_name>_<SID>_<nr> using the transaction
SPAD. Print all time critical documents via the high available spool server of the Central Instance.
26 SAP cluster administration