Dependencies between the ABAP enqueue server and the enqueue replication server

Edit online
The SAP enqueue replication mechanism imposes certain restrictions on the location where the components run. This topic describes these dependencies and shows how to implement them. The following considerations only apply to the case where traditional TCP/IP based replication is being used. When using EnqCF replication (see Enqueue replication into a IBM Z coupling facility), there is no replication server.
  • During normal operations, the enqueue server and the enqueue replication server (with its associated ERS VIPA) must not run on the same LPAR.
  • Let us take an example where the enqueue server runs on LPAR A and the enqueue replication server runs on LPAR B. If the enqueue server fails, it must not be restarted on LPAR A:
    • Instead, the enqueue server must be restarted on LPAR B where the enqueue replication server is running.
    • Only in this case, the enqueue server can rebuild its enqueue table from the replicated copy of the enqueue table that was maintained by the enqueue replication server.
    • The enqueue replication server should now stop on LPAR B.
    • In order to re-establish high availability, the enqueue replication server should then be restarted on a different LPAR.

These mentioned restrictions are implemented in the SAP policy definition. Using the definitions within this policy, establish the following three dependencies between the enqueue server and the enqueue replication server:

  • Dependency 1: The enqueue replication server is always started on a different LPAR from the one on which the enqueue server is running .
  • Dependency 2: If the enqueue server fails, it will be attracted by the enqueue replication server and will restart on the LPAR where the enqueue replication server is running .
  • Dependency 3: Do not start the enqueue replication server on an LPAR where the enqueue server failed previously.

Implementation of Dependency 1

The INGGROUP commands in the Messages and User Data and Startup section of the policy definition for the SAP<SID>ACV resource ensure that the enqueue replication server is not started where the enqueue server (actually the related VIPA) is currently running. This is accomplished by setting the PREFerence value to 1 for the enqueue replication server group (SAP<SID>AERS) and the LPAR where the VIPA for the enqueue server (SAP<SID>ACV) is running.

Table 1. Messages and User Data section from the SAPSIDACV policy definition
Message ID Command Text
RUNNING
INGGROUP SAP<SID>AER_X/APG,ACTION=RESET
INGGROUP SAP<SID>AER_X/APG,ACTION=ADJUST,MEMBERS=(SAP<SID>AERS/APG/
&SYSNAME.),PREF=(1)
Table 2. Startup section from the SAPSIDACV policy definition
Phase Command Text
REFRESHSTART INGGROUP SAP<SID>AER_X/APG,ACTION=ADJUST,MEMBERS=(SAP<SID>AERS/APG/&SYSNAME.),PREF=(1)

Implementation of Dependency 2

The INGGROUP commands in the Startup section of the policy definition for the POSTSTART and ANYSTART phases of the SAP<SID>AER resource ensure that the enqueue replication server attracts the enqueue server if this enqueue server fails. This is accomplished by setting the PREFerence value to 700 for SAP<SID>ASCS and the LPAR where the enqueue replication server (SAP<SID>AER) is running. This requires, that the default PREFerence value of each SAP<SID>ASCS group is set to 601 in the SAP<SID>ASCSX SYSPLEX MOVE group.

Table 3. Startup section from the SAPSIDAER policy definition
Phase Command Text
POSTSTART INGGROUP SAP<SID>ASCSX/APG,ACTION=RESET
ANYSTART INGGROUP SAPSIDASCSX/APG,ACTION=ADJUST,MEMBERS=(SAP<SID>ASCS/APG/&SYSNAME.),PREF=(700)

Implementation of Dependency 3

The MakeAvailable/WhenObservedSoftDown relationship against SAP<SID>ASCS/APG/= prevents the start of the enqueue replication server (SAP<SID>AER) whenever the ABAP central services group SAP<SID>ASCS on the same system is in HARDDOWN status.
Table 4. Relationships section from the SAPSIDAER policy definition
Relationship Supporting Resource Automation Chaining Condition
MakeAvailable SAP<SID>ASCS/APG/= PASSIVE WEAK WhenObservedSoftDown

Consequences of this implementation: A System Automation operator must manually change the status of the failed resource(s) in the group to AUTODOWN (after he has investigated or resolved the root cause of the resource failure) in order to allow the enqueue replication server to start on that LPAR.

Alternative to this implementation: In a two-LPAR environment, the described mechanism prevents the enqueue replication server from being restarted by SA z/OS® after a failure of the enqueue server. If you want to enable SA z/OS to do this restart you need to set a BROKEN enqueue server to AUTODOWN as soon as it is restarted on the other system. This can be done by the following policy change to the SAP<SID>AER definition:

  1. Remove the MakeAvailable/WhenObservedSoftDown relationship to SAP<SID>ASCS/APG/=.
  2. Add to the list of POSTSTART commands: SETSTATE SAP<SID>AEN,AUTODOWN.

One possible consequence of using System Automation to automatically reset the enqueue server (SAP<SID>AEN) status instead of letting an System Automation operator do it manually is that the enqueue server might start to move back and forth if the it fails over and over again with the same error:

  1. Enqueue server fails on LPAR1.
  2. SA z/OS moves it to LPAR2. There the enqueue server fails again.
  3. SA z/OS then moves the enqueue server back to LPAR1, and so on.

You need to decide which is the best behavior for your installation and define the SAP<SID>AER resource accordingly.

Note: This outlined alternative solution to this implementation is not included in the Best Practice Policy.