You have SAP Kernel Release 7.00, patch level 36 or higher.
To install the (A)SCS instance (standalone enqueue server and message server), use SAPinst. For more information see the SAP Service Marketplace in the installation guide:
http://service.sap.com/instguides . Here you choose your operating system, your database, and the installation option (ABAP only, ABAP+Java, Java only).
ABAP only: If you choose the HA installation, SAPinst installs an ASCS instance (ABAP Central Services) that contains the standalone enqueue server and the message server.
Note
Normally, a classical central instance with the enqueue work process is installed (no standalone enqueue server).
ABAP+Java: With AS Java an SCS instance is installed by default (SAP Central Services). With AS ABAP, the same applies as with ABAP only.
Java only: With AS Java an SCS instance is installed by default.
You can later change the configuration of a classical ABAP central system into a system with an SCS instance. 821904 describes how to split a classical ABAP central instance (with an enqueue work process) into a dialog instance and into an ASCS instance with a standalone enqueue server and message server and. You can then make this a high availability system.
If you want your system to be a high availability solution, you also have to install and configure the replication server. This is not (yet) possible with SAPinst; you have to carry out the installation manually.
The procedure for UNIX platforms is described in the section, Setting Up the Replication Server.
You can find information about installing the replication server under Windows in section High Availability with Microsoft Cluster Service.
After you have installed the replication server, you should carry out some tests to ensure that it is running correctly.
The procedure for UNIX platforms is described in the section, Replication Server: Check Installation.
You can find information about installing the replication server under Windows in the installation guide.
Caution
If the enqueue server and the replication server are running on the same host, a problem may arise if they are shut down normally and restarted.
The shutdown and restart must occur in the correct order.
Stop the enqueue server
Stop the replication server
This ensures that the enqueue server does not receive any more requests if the replication server is no longer running, and therefore no requests can get lost.
Start replication server
Start enqueue server
This ensures that the replication server deletes its old replica first (that is, it cleans up its shared memory), and therefore unwanted replications are avoided.
Note
The problem only occurs on Unix/Linux, since here the shared memory still exists after the processes belonging to it have finished.