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

touch /etc/cmcluster/ <SID>/debug — debug mode for the SGeSAP legacy SGeSAP
packages of SAP system<SID>.
The SGeSAP node will now be in debug mode. If the file is created in the package directory
/etc/cmcluster/<SID>, it will only turn on the debug mode for packages in that directory.
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 don't 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 apply now. It is possible to access the application
work directories to have a look at the trace files.
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 pause 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 will begin 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 this using transaction RZ10. In the 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>
There are also two additional profile parameters SAPLOCALHOST and SAPLOCALHOSTFULL
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: A print job in process at the time of the failure will be canceled and needs to be reissued
manually after the failover. To make a spooler highly available on 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.
Print requests to other spool servers stay in the system after failure until the host is available again
and the spool server has been restarted. These requests can be moved manually to other spool
servers if the failed server is unavailable for a longer period of time.
Change Management 25