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

This can lead to unsafe shutdowns and Instance crash.
To be safe, specify one of the following:
WAIT_OWN_AS=1
The shutdown of all application servers takes place in parallel, but the scripts do not continue
before all of these shutdown processes have come to an end.
WAIT_OWN_AS=2
If the package should also wait for all application servers to come up successfully. You have to
use this value if you want to prevent the integration from temporarily opening a new process
group for each application server during startup.
WAIT_OWN_AS=0
Can significantly speed up the package start and stop, especially if Windows NT application
servers are used. Use this value only if you have carefully tested and verified that timing issues
will not occur.
Optional Step: OS710
Specify SAPOSCOL_STOP=1 if saposcol should be stopped together with each instance that is
stopped.
The collector will only be stopped if there is no instance of an SAP system running on the host.
Specify SAPOSCOL_START=1 to start the saposcol even with packages that don't use the
implicit startup mechanism that comes with SAP instance startup, e.g. database-only packages
or packages that only have a SCS, ASCS, or ERS instance.
Optional Step: OS720
If several packages start on a single node after a failover, it is likely that some packages start
up faster than others on which they might depend.
To allow synchronization in this case, there is a loop implemented that polls the missing resources
regularly.
After the first poll, the script will wait 5 seconds before initiating the next polling attempt. The
polling interval is doubled after each attempt with an upper limit of 30 seconds. Polling continues
until the resource becomes available or up to a maximum of DELAY_INTERVALS polling
attempts.
Optional Step OS730
If several packages start on a single node after a failover, it is likely that some packages start
up faster than others on which they might depend.
To allow synchronization in this case, there is a loop implemented that polls the missing resources
regularly.
Control the handling of resources.
Prior to any instance startup, the SGeSAP tries to free up unused or unimportant resources to
make the startup more likely to succeed. A database package only frees up database related
resources, a Central Instance package only removes IPCs belonging to SAP administrators.
The following list summarizes how the behavior of SGeSAP is affected by changing the
CLEANUP_POLICY parameter:
• Lazy—no action, no cleanup of resources
• Normal—removes unused resources belonging to the own system
• Strict—uses HP-UX commands to free up all semaphores and shared memory segments
that belong to any SAP Instance of any SAP system on the host if the Instance is to be started
soon. It uses HP-UX to free up all semaphores and shared memory segments that belong to
any database if the SAP database is to be started soon.
Legacy Package Configuration 89