A question about installation sequence

[Former Member]

When I install IDES6 on Windows platform using "IBM DB2 for LUW" --> "Central System" --> "Central System Installation", the System Number in MMC after installation are:

1. Central Instance: Number 00

2. Central Service Instance: Number 01

When I install IDES6 using "IBM DB2 for LUW" --> "Distributed System" --> " Based on AS ABAP and AS Java", I noticed that the installation sequence is "Central Service Instance(SCS)" --> "Database Instance" --> "Central Instance", that is, System Number in MMC after installation are:

1. Central Service Instance: Number 00

2. Central Instance: Number 01

Here are my two questions:

1. Do I always need set Central instance number to be 00? Why set Central Service Instance number to be 00 in the secondary way.

2. What's the Central Service Instance here? In above two installation way, both of them are ABAP and Java double stacks installation. So, there are two concepts: ABAP Central Service Instance and Java Central Service Instance. How to distinguish these two concepts, and what's the right installation sequence, and start up sequence? Please advise.

I am a beginner of BASIS. Thanks so much.

James

[Former Member · Accepted solution]

1. Do I always need set Central instance number to be 00? 
Why set Central Service Instance number to be 00 in the secondary way.

No, you do not need to set Central instance number 00.

The Central Service Instance contains the

Java Message Server and Enqueue Server (locking mechanism).

I does not matter what number it uses, sapinst simply pick the first free number, starting from 00.

SAP just having an old history of using 00 as default for the Central Instance, but this has changed since Java always using two instances.

In Clustered installation the ABAP-stack is also installed as two instances.

2. What's the Central Service Instance here?

As said above:

Central Service Instance contains the Java Message Server and Enqueue Server.

The Central Instance (yes, the similar naming confuses a lot)

contains ABAP Central instance (including Enqueue and Message Server)

plus Java Central Instance together.

Sometimes it's hard to explaiin in an easy way...

[Former Member · Accepted solution]

Thanks so much for your explanation. Here is another thing confused me. The ASCS instance (ABAP Central Services) contains the standalone enqueue server and the message server. How to distinguish ASCS and Java Central Service Instance in a system landscape? It seems both of them have message server and enqueue server.

Thanks.

James

[Former Member · Accepted solution]

The SCS and ASCS are simply two different instances.

One to handle the abap-part and one to handle the java-part.

There's really nothing more to it.

So in an Cluster you have a lot of services, but only a few of them moves when a node failes. This architecture has been created to minimize the single-point-of-failure.

It makes more sense in an Cluster environment to explain how it works:

A cluster consists of two nodes A and B and some services are local and some of them are Clustered (can move between the nodes)

As Cluster services you have:

ASCS and SCS.

They can move from one node to another (between Node A and B).

On Node A you have Local installation of:

Central ABAP instance with Java Add-in.

ABAP Enqueue Replicator (Automatic replicate locks from ASCS Enqueue)

Java Enqueue Replicator (Automatic replicate locks from SCS Enqueue).

On Node B you have Local installation of:

Dialog ABAP instance with Java Add-in.

ABAP Enqueue Replicator (Automatic replicate locks from ASCS Enqueue)

Java Enqueue Replicator (Automatic replicate locks from SCS Enqueue).

Both nodes have ABAP and Java installed and it does not matter if Node A

goes down, all Cluster services are rolled over to Node B.

Since Node B already had the Dialog Instance running, the users can logon again.

Also, on Node B the Enqueue replicators are running, so they are sync'ed

with the "just arrived" Enqueue Service of the ASCS/SCS and then goes into

standby (not needed when the "real" enqueue service is running on the Node).

So part of this technique is used, even if the installation is not in a Cluster.