Create Newlun 3par

Implementing High Availability for
SAP NetWeaver 7.1 Technology on

System z
Applies to:
SAP NetWeaver 7.1, IBM Tivoli System Automation for z/OS 3.2, IBM Tivoli System Automation for
Multiplatforms 3.1, System Automation „best practice policy‟ for SAP
For more information, visit the Landscape Design and Architecture homepage.
Summary
The IBM System Automation family of products delivers ‘best practice policies’ for SAP that implements a
high availability solution for SAP NetWeaver 7.0. This paper describes enhancements and adaptations to
these policies to cover SAP NetWeaver 7.1.
Authors: Harald Duvenbeck, Rainer Himmelsbach, Heike Schmidt, Volker Schölles

Company: IBM
Created on: 24 September 2009
Update: 18 January 2010
Document Version: Version 1.1, 18 January 2010
Author Bio
Harald Duvenbeck
Harald Duvenbeck is a software developer at IBM Deutschland Research & Development
GmbH, Boeblingen. He holds a master‟s degree in mathematics from the University of
Bonn, Germany, and has worked for IBM since 1990. In 1994 he joined the IBM/SAP
platform team that developed the SAP on System z solution. Since 2008 he has been
working in the IBM Team in the Boeblingen lab that focuses on High Availability for SAP on
IBM server platforms. He can be reached at duven@de.ibm.com .
Rainer Himmelsbach
Rainer Himmelsbach graduated with a degree in “IT & Electronics Engineering” in
Berlin in 1988. He started his career at Endress+Hausser as a software developer.
Rainer joined IBM in 1991 and worked as team lead of the CVT/SVT test team for
RMF, the MVS Resource Measurement Facility. In this role he worked closely together
with other IBM teams in Boeblingen, Poughkeepsie, Tucson and Endicott.
In 2007 he took the team lead position of the IBM COV-Team (Customer Oriented
Validation) for SAP on IBM System z. He is responsible for the certification of new z/OS and Linux for IBM
System z releases and for the validation of Business Continuity for SAP on IBM System z. He can be
reached at himmi@de.ibm.com .
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com
© 2010 SAP AG 1
Implementing High Availability for SAP NetWeaver 7.1 Technology on System z
Heike Schmidt
Heike Schmidt joined IBM in 1986, starting as an application programmer for IBM. Since
1998 she has been working as an SAP Basis Specialist with IBM, running functional
tests on IBM platforms and providing first level support for SAP Basis issues within IBM
(SAP Customer Competence Center). She has been involved in several SAP projects
and benchmarks for customers. Since 2007 she belongs to the IBM System z
Technology Center for SAP applications in the Boeblingen Lab and is focused on z/OS
and Linux on System z certification for SAP applications. She can be reached at
heike_schmidt@de.ibm.com .
Volker Schölles
Volker Schölles is a software developer at IBM Deutschland Research & Development
GmbH, Boeblingen. He holds an IT degree from the University of Kaiserslautern,
Germany, and has worked for IBM since 1985. In 1995 he joined the IBM/SAP platform
team which developed the SAP on System z solution. Since 2003 he has been
responsible for the High Availability solution for SAP on System z. In addition, he is
currently working on the extension of this solution to other IBM server platforms. He
can be reached at volker_schoelles@de.ibm.com .
© 2010 SAP AG 2
Table of Contents
Installing and Customizing SAP 7.1 for High Availability .................................................................................... 4
Software Prerequisites .................................................................................................................................... 4
IBM Tivoli System Automation for z/OS ....................................................................................................................... 4
IBM Tivoli System Automation for Multiplatforms ......................................................................................................... 4
Filesystem Setup on z/OS............................................................................................................................... 5
Considerations for the Planned or Unplanned Move of the NFS Server ...................................................................... 5
Define Own, Separate zFS filesystems for SCS and ASCS Instance Directories ........................................................ 5
Description of Test Environment ..................................................................................................................... 5
Configuration of the SAP File Systems ........................................................................................................... 7
SAP Central Services Installation on z/OS ..................................................................................................... 8
Installation of Central Services and its ERS with ZSCSinst tool................................................................................... 8
Installation of Central Services and its ERS with SAP installation tool ......................................................................... 9
Installation of a Primary and One or More Additional Application Server (AS) Instances ............................ 10
SAP Primary Application Server Instance .................................................................................................................. 11
SAP Dialog Instance .................................................................................................................................................. 12
SAP Post Installation Steps for HA ............................................................................................................... 12
Update DBSL ............................................................................................................................................................. 12
Multiple-Node Setup for a Highly Available SAP Application Server .......................................................................... 12
Adaptations in SAP Profiles ....................................................................................................................................... 12
Environment Adaptations for AIX and for Linux on System z ....................................................................... 13
Adaptations for AIX .................................................................................................................................................... 13
Adaptations for Linux on System z ............................................................................................................................. 14
Customizing Tivoli System Automation for z/OS .............................................................................................. 16
SAP JAVA Gateway ...................................................................................................................................... 16
SAP JAVA Enqueue Server .......................................................................................................................... 17
SAPOSCOL .................................................................................................................................................. 17
SAP WebDispatcher 7.1 ............................................................................................................................... 18
Installation .................................................................................................................................................................. 18
Running under Automation Control ............................................................................................................................ 21
OMPROUTE Relationship Changes ............................................................................................................. 22
NFSSERV Relationship Changes ................................................................................................................. 22
Filesystem Recommendation ........................................................................................................................ 22
Customizing Tivoli System Automation for Multiplatforms ............................................................................... 24
Related Content ................................................................................................................................................ 25
Copyright........................................................................................................................................................... 26
© 2010 SAP AG 3
Installing and Customizing SAP 7.1 for High Availability

This paper mainly concentrates on the differences between a SAP NetWeaver 7.0 and 7.1 configuration and
the effects that these have on the implementation of your high availability solution for SAP.
The general concepts of a highly available SAP NetWeaver 7.1 installation are the same as described for
SAP NetWeaver 7.0 in the “Business Continuity for SAP on IBM System z” in chapters 8 and 10.
The general procedure for adapting the IBM Tivoli System Automation „best practice policies’ for SAP to your
specific SAP system is described in chapters 11 and 12 of the book.
The following features of SAP NetWeaver 7.1 require changes in this procedure and they are described in
more detail in the chapters below:
1. In SAP NetWeaver 7.1 the SAP Enqueue Replication Servers (ERS) for ABAP and JAVA are
installed by the SAP installer as individual SAP instances including ERS instance profiles.
2. In SAP NetWeaver 7.1 there is only one single profile per instance that contains all the information
that was spread across 2 separate profiles - the instance profile and the instance start profile - in
previous SAP releases.
3. The JAVA Central Services are installed including a standalone SAP Gateway.
4. The default SAPOSCOL installation directories have changed.
5. If the home directory of the <sapsid>adm is -NOT-shared, we recommend that you install your SAP
application servers in your HA environment using virtual hostnames.
The high availability concepts and recommendations described in this paper have been implemented and
tested in our SAP NetWeaver 7.1 High Availability test environment.
Software Prerequisites
Before you start with your SAP NetWeaver 7.1 high availability installation you should ensure that you have
installed the following required software levels:
IBM Tivoli System Automation for z/OS

1. Install the relevant SA z/OS 3.2 service level listed in SAP Note 81737.
2. Install script sapctrl_em version 6 contained in SAP_v9.zip file into the home directory of the
<sapsid>adm user. This file can be downloaded from
http://www.ibm.com/servers/eserver/zseries/software/sap/downloads/
This zip file also contains an updated version of Chapter 11 of the book “Business Continuity for SAP
on IBM System z (SC33-8206-02”). Use the updated version.
IBM Tivoli System Automation for Multiplatforms

All SAP “best practice policy” scripts for SA MP 3.1 are contained in the file saphasalinux-
version6.0.tar. This tar file which is applicable for both for AIX and Linux can be downloaded from:
http://www.ibm.com/servers/eserver/zseries/software/sap/downloads/
As an alternative you can download and install the scripts from:
IBM Tivoli Open Process Automation Library (select „Tivoli System Automation‟ in the search
category ‟Tivoli products‟). For AIX see the install file under “System Automation for Multiplatform -
Automation Policies for AIX” for Linux see the .rpm file under “System Automation for Multiplatform -
Automation Policies for LINUX”
If you download the .tar file, untar the files into the /usr/sbin/rsct/sapolicies/sap directory.
© 2010 SAP AG 4
Filesystem Setup on z/OS
Considerations for the Planned or Unplanned Move of the NFS Server

For performance reasons we recommend that any movement of the NFS Server from one LPAR to another
should be accompanied by the movement of the filesystem ownership. Each file system that the NFS server
exports should be “owned“ by the LPAR on which the NFS server is running.
To accomplish this you configure a POSTSTART command for each file system in the SA z/OS policy for
NFS Server resource, as shown in the following example:
MVS SETOMVS FILESYS,FILESYSTEM='OMVS.ZFS.&SYSPLEX..SAPMNT',SYSNAME=&SYSNAME.

MVS SETOMVS FILESYS,FILESYSTEM='OMVS.ZFS.&SYSPLEX..TRANS',SYSNAME=&SYSNAME.
Define Own, Separate zFS filesystems for SCS and ASCS Instance Directories
In the case of a SAP double stack installation you must define System Automation resources for both the
JAVA central services (SCS) and the ABAP central services (ASCS) in your System Automation policy.
There is no technical reason why the SCS and the ASCS must run on the same z/OS LPAR. The SAP best
policy reflects this in the sense that there is no dependency between the resources of both central services
instances.
The enqueue server of each central services instance needs access to its instance directory which should –
for performance reasons – be owned by the LPAR on which the enqueue server is running (see: Filesystem
Recommendation).
If you define only one filesystem for both the SCS and the ASCS instance directories you might encounter a
situation where System Automation places the SCS and ASCS on different z/OS LPARs. Since only one
LPAR can have the ownership of the filesystem the other (A)SCS will encounter a performance penalty
especially during startup and shutdown, for example in a maintenance scenario with planned failover.
In order to avoid this penalty and potential restarts of application servers because of timeouts, we highly
recommend that you define separate filesystems for each SCS and ASCS instance directory. This allows for
movement of the filesystem ownership together with the (A)SCS that is using it, thus avoiding any
performance impact on one of the enqueue servers.
Description of Test Environment

The following section contains a description of the environment that was used to develop and test the
recommendations. The examples that you find in the following chapters contain the specific values from this
test environment. If you want to use any of the examples then make sure to replace them with the
parameters that are relevant for your SAP installation.
Our system configuration represents an implementation of the high availability aspects described in “SAP for
Banking on System z Reference Architecture”
The SAP database is installed on z/OS 1.10 with DB2 9 in data sharing mode with 3 data sharing members
distributed across 3 LPARs in the Parallel Sysplex with two physical machines.
The Central Services for ABAP and JAVA and their corresponding Enqueue Replication Servers are installed
on z/OS Unix System Services.
- The ABAP central service instance and its corresponding enqueue replication server are installed
using a virtual hostname (=z/OS dynamic VIPA) of ha2ascsv.
- The JAVA central service instance and its corresponding enqueue replication server are installed
with a virtual hostname (=z/OS dynamic VIPA) of ha2scsv.
The SAP NetWeaver Process Integration 7.1 double stack installation was performed with a SAP System
name (SAPSID) of HA2.
© 2010 SAP AG 5
The three SAP application servers – one primary and two additional application servers - were installed on
IBM System p LPARs running AIX 6.1, also distributed on two physical machines.
SAP supports the application server installation with virtual hostnames. We used p570coh1v, p570coh2v,
p570coh3v for the three AIX application servers. This was possible, because on each machine the home
directory of the ha2adm is local.
System Setup - SAP System HA2
IBM System p IBM System p
LPAR 1 - AIX LPAR 2 - AIX LPAR 3 - AIX

VIPA p570coh1v VIPA p570coh2v VIPA p570coh3v
Primary AS Instance Additional AS Instance Additional AS Instance

HA2_DVEBMGS24_p570coh1v HA2_D25_p570coh2v HA2_D26_p570coh3v
IBM System z IBM System z

LPAR 1 LPAR 2 LPAR 3
Movable Services in Movable Services in Movable Services in

Unix System Services Unix System Services Unix System Services
ABAP SCS dynamic VIPA ha2ascsv ABAP SCS dynamic VIPA ha2ascsv ABAP SCS dynamic VIPA ha2ascsv
Java SCS dynamic VIPA ha2scsv Java SCS dynamic VIPA ha2scsv Java SCS dynamic VIPA ha2scsv
NFS dynamic VIPA sapnfsv NFS dynamic VIPA sapnfsv NFS dynamic VIPA sapnfsv
ABAP SCS Instance HA2_ASCS20_ha2ascsv ABAP SCS Instance HA2_ASCS20_ha2ascsv ABAP SCS Instance HA2_ASCS20_ha2ascsv
Java SCS instance HA2_SCS21_ha2scsv Java SCS instance HA2_SCS21_ha2scsv Java SCS instance HA2_SCS21_ha2scsv
ERS for ASCS HA2_ERS22_ha2ascsv ERS for ASCS HA2_ERS22_ha2ascsv ERS for ASCS HA2_ERS22_ha2ascsv
ERS for SCS HA2_ERS23_ha2scsv ERS for SCS HA2_ERS23_ha2scsv ERS for SCS HA2_ERS23_ha2scsv
z/OS z/OS z/OS
static VIPA coh1vipa static VIPA coh2vipa static VIPA coh3vipa

DB2 member SNH1 DB2 member SNH2 DB2 member SNH3
= physical machine boundary
According to the instructions in the SAP NetWeaver 7.1 installation guide, the SAP instances for a high
availability system should be installed in the following sequence:
1. SAP Central Service instances (ASCS and/or SCS)
2. Enqueue Replication Server instances for ABAP and/or JAVA (ERS)
3. Database instance
4. Primary Application Server instance (PAS)
5. Additional Application Server instance (AAS)
The installation procedure in SAP 7.0 did not install the Enqueue Replication Server (ERS) as a separate
instance. This has changed with SAP 7.1.
The Installation guide “SAP NetWeaver 7.1 PI ABAP and Java on AIX: IBM DB2 for z/OS” recommends the
installation of a separate ERS instance on each eligible application server. In a High Availability setup under
USS with a shared filesystem this is not appropriate. It is required that you install only one ERS instance for
ABAP and one for ERS instance for JAVA under USS.
The SAP NetWeaver 7.1 installation will automatically add a JAVA Gateway when installing the JAVA SCS.
A change in the System Automation policy (see SAP JAVA Gateway) is required to make this component
highly available as well.
© 2010 SAP AG 6
Configuration of the SAP File Systems

The following figure shows which zFS filesystems must be defined to run ASCS/SCS under USS and to
automate them by SA z/OS. It also depicts what directories are exported by the NFS server to the
Application servers on AIX or Linux machines.
= zFS file system

/usr
/sapmnt
= NFS exported directory
sap = softlinked directories

HA2
trans HA2
exe global profile

ERS23 SCS21* ASCS20* ERS22
SYS
data data data data

exe global profile
exe exe exe exe
log log log log
work sec sec work
profile work work profile run dbg
HA2 SAP system ID

SCS21 Java SCS instance
ERS23 Java ERS instance
SAP directory structure and file systems ASCS20 ABAP SCS instance
ERS22 ABAP ERS instance
* the Central Services instance directories are configured as zFS filesystems, see: Define Own, Separate
zFS filesystems for SCS and ASCS Instance Directories
The SAP global directories which are exported by the NFS server on z/OS are mounted on AIX in our
environment. We highly recommend using the automounter. See the following sample automounter
definitions:
p570coh1:/etc # cat auto_master
/sapmnt/HA2 auto.ha2.sapmnt
p570coh1:/etc # cat auto.ha2.sapmnt
global -rw,hard,intr,sec=sys sapnfsv:/HFS/sapmnt/HA2/global,text,cln_ccsid(819),srv_ccsid(1047)
profile -rw,hard,intr,sec=sys sapnfsv:/HFS/sapmnt/HA2/profile,text,cln_ccsid(819),srv_ccsid(1047)
trans -rw,hard,intr,sec=sys sapnfsv:/HFS/usr/sap/trans,text,cln_ccsid(819),srv_ccsid(1047)
exe -rw,hard,intr,sec=sys sapnfsv:/HFS/sapmnt/HA2/AIX/exe
© 2010 SAP AG 7
SAP Central Services Installation on z/OS

There are two alternative ways for installing the SAP Central Services on Unix System Services:
 ZSCSinst for SAP Central Services on z/OS
 SAP installation tool
The ZSCSinst tool has been released to simplify the installation of SAP Central Services (ASCS, SCS, ERS)
and utilities under z/OS Unix System Services. The ZSCSinst tool is implemented as a REXX script, which
is called from the z/OS Unix System Services command line. The installation of the SAP Central Services
can be done either interactively or using a response file that contains the installation parameters.
For SAP NetWeaver Kernel 7.10, 7.11, 7.20 and SAP NetWeaver Composition Environment 7.11 the
ZSCSinst tool is attached to SAP Note 1322991. Follow the instructions in this note to extract the ZSCSinst
tool. Then begin ZSCSinst installation as described in the unpacked guide “ZSCSinst_Instguide.doc”.
Make sure you use ZSCSinst version 710.5 or later. The version is displayed when running the command
without parameters from the z/OS Unix System Services shell:
./zscsinst
zscsinst version 710.5
In our environment the SAP Central Services have been installed with the ZSCSinst tool. We recommend
using ZSCSinst, because it is easier to handle and the installation is much faster.
Installation of Central Services and its ERS with ZSCSinst tool

The ZSCSinst tool installs the SAP Central Services instances and the Enqueue Replication Server
instances in the same way as the SAPinst tool.
With the ZSCSinst tool you can install the Central Services on Unix System Services either through an
interactive command-line dialog or using predefined parameter files. The ZSCSinst tool provides sample
parameter files for an ASCS, SCS and ERS installation, which you have to adapt to your system definitions.
The virtual hostnames have to be entered as the value of the parameter VIRTUALHOST within those files.
In the examples for our sample SAPSID HA2 we use the following dynamic VIPA names as VIRTUALHOST:
ha2ascsv VIPA for the ABAP Central Services (ASCS) and its ERS
ha2scsv VIPA for the JAVA Central Services (SCS) and its ERS
Please note, that those dynamic VIPAs must be activated manually on the LPAR on which you plan to do the
installation, for example by using the moddvipa USS command as described in the “Business Continuity for
SAP on IBM System z” .
Example invocation of ZSCSinst for ABAP Central Services Installation (ASCS) using a parameter file:
./zscsinst ASCS /u/admin/REXX/ASCS.HA2
Example parameters file ASCS.HA2 for ABAP Central Services
SYSTYPE=ASCS
VIRTUALHOST=ha2ascsv
SAPSID=HA2
MOUNTDIR=/sapmnt
KERNELCD=/common/sapdvds/SAP_Netweaver_PI_710/sapcd1/DATA_UNITS/K_710_UI_OS390_64
INSTANCENUMBER=20
MSPORT=3620
IMSPORT=3920
© 2010 SAP AG 8
Example invocation of ZSCSinst for Enqueue Replication Server for ABAP (ERS)
./zscsinst ERS /u/admin/REXX/ERSA.HA2
Example parameters file ERSA.HA2 of ERS for ABAP

SYSTYPE=ERS
VIRTUALHOST=ha2ascsv
PROFDIR=/sapmnt/HA2/profile
INSTANCENUMBER=22
INSTFILE=HA2_ASCS20_ha2ascsv
Example invocation of ZSCSinst for Java Central Services Installation (SCS)
./zscsinst SCS /u/admin/REXX/SCS.HA2
Example parameters file SCS.HA2 for ABAP Central Services
SYSTYPE=SCS
VIRTUALHOST=ha2scsv
SAPSID=HA2
MOUNTDIR=/sapmnt
INSTANCENUMBER=21
IMSPORT=3921
Example invocation of ZSCSinst for Enqueue Replication Server for Java (ERS)
./zscsinst ERS /u/admin/REXX/ERSJ.HA2
Example parameters file ERSJ.HA2 of ERS installation for Java:

SYSTYPE=ERS
VIRTUALHOST=ha2scsv
PROFDIR=/sapmnt/HA2/profile
INSTANCENUMBER=23
INSTFILE=HA2_SCS21_ha2scsv
The INSTFILE parameter contains the filename of the ASCS – or SCS instance profile for which the ERS
must be installed.
Note: To ensure proper functionality of SAP utilities like ensmon or enqt in a double-stack installation (ABAP and Java
stack) check the Java SCS profile. It must contain the parameter „enque/serverhost‟ set to the Java virtual
hostname. If the parameter is missing in the SCS Profile and you are using these utilities, they will fail because
they will use enque/serverhost from the default parameter file that is set to ABAP virtual hostname.
Installation of Central Services and its ERS with SAP installation tool
Parallel to using the ZSCSinst tool there is still the option of installing the high availability components on
z/OS Unix System Services using the SAPinst installation tool.
When calling SAPinst from the Unix System Services command line you need to specify the virtual hostname
using the option SAPINST_USE_HOSTNAME.
© 2010 SAP AG 9
Example for ABAP Central Services installation:

./sapinst SAPINST_USE_HOSTNAME=ha2ascsv -nogui
Example for JAVA Central Services installation:

./sapinst SAPINST_USE_HOSTNAME=ha2scsv -nogui
In the SAPinst GUI select the menu item “High-Availability System” and choose the ABAP (ASCS) or JAVA
Central Service (SCS) of your choice.
The same command lines should be used for installing the corresponding enqueue replication server
instances.
Caution: When you use SAPinst to install the ERS it will install both ERS instances (for ABAP and JAVA) in one step. In
our case this would have the negative side-effect, that both ERS instances (for JAVA and ABAP SCS) would be
installed with the same virtual hostname – namely the virtual hostname which was specified in the SAPinst
command line. This would prevent the two ERS instances from running independently of each other. Therefore
you need to call SAPinst twice, to install each ERS Instance with its own virtual hostname.
In order to prevent SAPinst from installing the two ERS instances at once, you need to explicitly prevent the
installation of the „wrong‟ ERS as depicted in the following example screenshot.
In this example we want to install the ERS for the ABAP SCS using the SAPinst command line:
./sapinst SAPINST_USE_HOSTNAME=ha2ascsv –nogui
and therefore uncheck the checkbox in front of the Java SCS (SCS21):
If you install the ERS with SAPinst, you must follow the instruction of SAP Note 1045531, to make the ERS
instances startable:
https://service.sap.com/sap/support/notes/1045531
Installation of a Primary and One or More Additional Application Server (AS) Instances
Redundancy for SAP application servers is usually achieved by installing more than one application server
instance which is supported by the NetWeaver architecture. If a specific application server is not available, a
SAP user can connect to another one that is still active. Therefore, the „best practice policy‟ for SAP of
System Automation for Multiplatforms (SA MP) defines SAP application server resources as fixed resources
that are not moved to another node. From a high availability point of view, installing an application server
using the physical hostname is sufficient.
© 2010 SAP AG 10
On the other hand, the SAP installer supports installation of an application server instance with its own virtual
hostname. Exploiting this feature makes it easier to move an instance from one physical machine to another
in case this should be necessary, for example when moving to a newer and faster hardware.
In order to exploit the SA MP „best practice policy‟ for SAP and to get the flexibility provided by SAP‟s
virtualization option, we recommend installing every application server with its own virtual hostname,
provided the home directory of the <sapsid>adm is local on each machine. SA MP will define and manage
the application server as a fixed resource regardless of its hostname being a virtual or a physical one. The
rare case of moving such an AS from one physical host to a different one is NOT done using SA MP. It is
done as a manual task outside of automation after the cluster has been changed to include the new host.
SAP Primary Application Server Instance

Please note, that the VIPA must be active before the installation. We defined a vi0 interface with the
corresponding IP. Also, on our AIX machines the home directory of the <sapsid>adm is local on each
machine.
To install the Primary Application Server with a virtual hostname, call the sapinst command with virtual
hostname parameter:
./sapinst SAPINST_USE_HOSTNAME=p570coh1v
Note: Make sure that System Automation under z/OS is not controlling the Java SCS during the Primary Application
Server installation because SAPinst will try to start and stop the Java SCS during the installation procedure. This
will create a conflict if the JAVA SCS is already managed – and kept highly available - by System Automation at
that time and will cause the Primary Application Server installation to fail.
© 2010 SAP AG 11
SAP Dialog Instance

Analogous to the installation of the Primary Application Server, the Additional Application Servers on AIX
should be installed with virtual hostnames using a sapinst command line similar to this one:
./sapinst SAPINST_USE_HOSTNAME=p570coh2v
SAP Post Installation Steps for HA

Additionally to the post-installations steps outlined in the SAP Installation Guide, using a virtual hostname
requires platform specific manual steps to ensure proper DB2 Connection failover for ABAP work processes
to a standby DB2 data sharing member.
Update DBSL
When you run your SAP application servers with virtual hostnames, you need a minimum DBSL level as
documented in SAP Note 1339004, “DB2-z/OS: Support of Logical Hostname in connect.ini”. Download the
required DBSL patch from SAP Services Marketplace and install it in your application servers.
The current DBSL level of your SAP kernel is reported when you run the following command as
<sapsid>adm:
disp+work –v
After you have installed the DBSL, follow the instructions in SAP Note 1339004 describing the modification in
the connection profile „connect.ini‟. The profile can be modified directly using an editor or through the SAP
transaction DBACOCKPIT from SAPGUI. Check the SAP note for the Support Package that needs to be
installed.
Note: It is essential that you have added the SAPLOCALHOST variable to the environment of your <sapsid>adm and
that its value is the name of the virtual/logical hostname. System Automation for Multiplatforms depends on it when
it runs the R3trans utility to test the application server connectivity to the z/OS database.
Multiple-Node Setup for a Highly Available SAP Application Server

For SAP NetWeaver 7.1 the same high availability rules are valid as in previous versions. This means that
you should have at least two application server instances installed:
1. Primary Application Server (PAS)
2. Additional Application Server (AAS) on another node
The profile parameters of the Additional Application Server instances must be configured manually so that all
SAP ABAP services that run on the PAS installation are also on it. These are:
 Batch service
 Update/Update 2 service
 Spool service
Through this setup all non-unique SAP services are running on each of the application servers and therefore
no longer constitute single points of failure (SPOF).
To ensure redundancy from the SAP user perspective you should configure the SAP logon groups.
Adaptations in SAP Profiles

With SAP 7.1 it is no longer necessary to explicitly set the profile parameter for the enqueue replication port:
enque/encni/repl_port
© 2010 SAP AG 12
Use this parameter only if the replication port of the enqueue server cannot be set to the default port 5XX16
(where XX is the instance number).
a) Put
enque/con_retries = 120
enque/deque_wait_answer = TRUE
into DEFAULT.PFL (or into each AS instance profile, if you think this is more appropriate)
b) In the instance profiles for the Enqueue Replication Servers <SAPSID>_ERSxx_<virtual hostname>
comment out the line:
Autostart = 1
c) In each ASCS/SCS/ERS profile change every occurrence of

Restart_Program_<xx>
to
Start_Program_<xx>
Adaptations b) and c) make sure that SAP (via hostctrl or startsapsrv) is NOT trying to restart instances. We
want System Automation to control this (and having 2 'automation managers' controlling the same resources
will cause problems).
Environment Adaptations for AIX and for Linux on System z

We recommend running the highly available NFS server on z/OS, using OSPF as a dynamic routing protocol
for network high availability (network between Application Server and Database Server) and running
automounter to mount the NFS filesystems. In order that all of these work together smoothly at AIX/Linux
boot or shutdown time, we recommend making the following changes in your environment.
Since the processes implementing the OSPF protocol (ospfd/zebra/quagga) under Linux and gated under
AIX) need some time to create a routing table after they are started and the normal boot sequence does not
allow „waiting‟ for successful routing table updates, we needed to adapt some of the services called during
boot/shutdown.
Caution: If you change any script that is delivered with the OS (like /etc/rc.nfs) or System Automation (like sapctrl_em),
the changes may and most likely will be over-written during a service update. So it is highly recommended that you
check the adapted scripts after such activities.
Adaptations for AIX

We had to perform the following adaptations in our AIX 6.1 systems. In /etc/rc.nfs we removed the call to
start the automounter as we want to run our own automounter start script, which waits up to one minute until
gated has added a route to the to NFS Server. Otherwise the automount was automatically aborted and
never recovered.
1. Comment out the start of automount in /etc/rc.nfs, as in this example:
## if [ -s /etc/auto_master ]; then
## /usr/sbin/automount
## fi
© 2010 SAP AG 13
2. Add a new rc.local script in the /etc directory. Adapt the virtual NFS server hostname to your
environment (our virt. NFS server hostname is sapnfsv):
$ cat rc.local
#!/bin/ksh
# this is to start autofs group after gated had time to consolidate it's routing table
VirtNFSHOST="sapnfsv"
TIMEVAR=0
MAXRETRY=20 # this lets this script try for 20 minutes
RETRY=0
SLEEPSEC=5 # this lets this script sleep for 5 seconds
RC=1
while [[ $RC -eq 1 && $RETRY -lt $MAXRETRY ]];do

while [[ $RC -eq 1 && $TIMEVAR -lt 60 ]];do
eval "/usr/bin/netstat -r | /usr/bin/grep \"$VirtNFSHOST\" > /dev/null"
RC=$?
TIMEVAR=$((${TIMEVAR}+${SLEEPSEC}))
sleep ${SLEEPSEC}
done
if [[ $RC -eq 0 ]];then
/usr/sbin/automount
/usr/bin/logger -p user.debug -i "rc.local: Found (virt.) NFS server $VirtNFSHOST in
routing table; automount daemon started."
else
if [[ $RETRY -eq $((${MAXRETRY}-1)) ]];then
/usr/bin/logger -p user.debug -i "rc.local: Could not find (virt.) NFS server $VirtNFSHOST
in routing table; automount daemon not started."
else
/usr/bin/logger -p user.debug -i "rc.local: Could not find (virt.) NFS server $VirtNFSHOST
in routing table; Retrying ..."
fi
TIMEVAR=0
RETRY=$((${RETRY}+1))
fi
done
exit 0
3. Add starting of rc.local to /etc/inittab. Insert the rc.local call before the rc_2 call and the following
rc_x:
automd:2:wait:/etc/rc.local >/dev/console 2>&1

l2:2:wait:/etc/rc.d/rc 2
…
Note: Starting the sapstartsrv processes in /usr/sap/sapservices will produce some NFS mount failure messages in the
/tmp/syslog.out file at system start. This is normal since, even if the z/OS NFS server host is listed in the routing
table, it may not be able to reply directly because the z/OS routing daemon also needs to update its routing table
after the AIX (gated) has started.
Adaptations for Linux on System z
The init scripts for sapinit and autofs need to have dependencies set, so that they are started and stopped in
the correct order.
sapinit needs a start dependency to autofs and autofs needs a start dependency to ospfd/zebra. Therefore,
in the sapinit script under /etc/init.d at the end of the “# Required-Start” line, add the autofs:
ihlscoh1:/etc/init.d # head -n 20 sapinit
#!/bin/sh
# Copyright (c) 1995-2005 SAP AG Walldorf, Germany.
#
# /etc/init.d/sapinit
#
# chkconfig: 345 90 10
# description: Start sapstartsrv
#
© 2010 SAP AG 14
### BEGIN INIT INFO

# Provides: sapinit
# Required-Start: $network $syslog $remote_fs $time autofs
Also add in the autofs script under /etc/init.d at the end of the “# Required-Start” line the ospfd and zebra
processes:
ihlscoh1:/etc/init.d # head -n 20 autofs
#!/bin/bash
#
# rc file for automount using a Sun-style "master map".
# We first look for a local /etc/auto.master, then a YP
# map with that name
#
### BEGIN INIT INFO

# Provides: autofs
# Required-Start: $network $syslog $remote_fs ospfd zebra
© 2010 SAP AG 15
Customizing Tivoli System Automation for z/OS

IBM Tivoli System Automation for z/OS delivers a ”best practice policy” for SAP that contains the necessary
definitions for automation and for ensuring your SAP Components on z/OS are rendered highly available.
The modifications that are needed to adapt this policy to your specific SAP System ID (SAPSID) are
described in detail in chapter 11 of “Business Continuity for SAP on IBM System z”.
Note that chapter 11 of the referenced book Business Continuity for SAP on IBM System z (SC33-8206-02)
does not fully describe all the necessary actions to adapting the „best practice policy‟ for SAP to a newly
installed SAP system. An updated version ('chapter11_new.pdf' ) of that chapter is contained in the
SAP_v9.zip file. Use the updated version.
Before you activate your System Automation policy you should ensure that you can start and stop all SAP
components manually on all systems on which the components are intended to run. Verify that the SAP
components operate correctly. Depending on your system setup, adaptations in local files like e.g.
/etc/services or /etc/hosts might be required to enable startup of SAP components on all LPARs.
The following paragraphs focus on the changes that were introduced in the SAP configuration from SAP
NetWeaver 7.0 to 7.1 that require an adaptation of the System Automation policy for SAP:
- SAP JAVA gateway
- saposcol configuration
Further changes apply to SAP NetWeaver 7.1 but may also be used for 7.0:
- additional relationship from OMPROUTE to TCPIP
- additional NFSSERV relationships
- enhancements for the JAVA enqueue server
- movement of file system ownership with the ENQ server
- definition of separate filesystems for ABAP and JAVA SCS
Note: All automation names and sample command lines that are mentioned below contain the sample SAPSID HA1 that
is used in the “best practice policy” for SAP delivered with System Automation. You need to replace references to
this sample SAPSID with your specific SAPSID for which you are creating the System Automation policy.
SAP JAVA Gateway

In SAP 7.1 the SAP JAVA SCS has its own standalone gateway process that starts independently of an
optional ABAP gateway. In order to automate the operation of this gateway and make it part of the System
Automation JAVA SCS resources you need to:
- define an additional System Automation APL SAPHA1JGW and add it as an additional member to
System Automation APG SAPHA1JSCS
There is no need to create SAPHA1GW from scratch, instead you can use the SAPHA1GW resource which is an
optional part of the ABAP central services in the “best practice policy” for SAP and copy its content into
SAPHA1JGW.
In case of a JAVA-only or an ABAP+JAVA double-stack installation we recommend that you define and use
SAPHA1JGW in your policy. There is no need for a second highly available gateway resource (SAPHA1GW) in
your policy.
In the case of an ABAP-only installation, you may still want to include SAPHA1GW in your policy.
© 2010 SAP AG 16
SAP JAVA Enqueue Server

The current resource definition for the SAP JAVA enqueue server SAPHA1JEN contains the following
(standard) first pass for shutdown processing in all phases, which is inherited from the C_SAP_USS class:
1 INGUSS /bin/kill &SUBSPID
This means that in all shutdown phases the first pass will cause the JAVA enqueue server to stop normally.
All SAP JAVA application servers notice the stop. As a consequence, all JAVA application servers will
restart. As stopping and restarting of a JAVA application server can take quite some time, SAP JAVA
applications are not accessible to the SAP user during that time.
If the shutdown of the JAVA ES was intended to move the ES to another system (for example for planned
maintenance of the LPAR where it currently runs), that move is not transparent to the application server. To
actively trigger a failover of the JAVA enqueue server to another LPAR –AND-- to avoid the restart of Java
application servers, that means to make the failover seamless and transparent for the SAP users, you must
simulate an „unplanned‟ outage of the JAVA enqueue server. That can be easily done by killing the Java
enqueue server process with „kill -9‟.
Therefore we recommend changing the first pass of the STOP IMMED and STOP FORCE phases for the
SAPHA1JEN resource to:
1 INGUSS /bin/kill -9 &SUBSPID
rd nd
and to delete the second pass and rename the 3 to the 2 :
2 MVS C &SUBSUSSJOB,A=&SUBSASID
A STOP IMMED/ STOP FORCE will then initiate the following sequence:
- „kill -9‟ will stop the JAVA enqueue server immediately without the JAVA application servers being
notified.
- System Automation restarts the JAVA enqueue server on another LPAR
- the enqueue table is rebuilt from the information that the Enqueue Replication Server provides
- the JAVA application servers (re)connect to the enqueue server without restart
- SAP users can continue to work with the SAP JAVA applications and might only encounter a slight
delay during the rebuilt of the enqueue table
We highly recommend initiating such a failover by using STOP IMMEDiate or STOP FORCE.
SAPOSCOL
With the standard SAP 7.1 installation the SAP operating system collector saposcol is installed into the SAP
system independent path /usr/sap/hostctrl/exe.
If you intend to use the 7.1 SAPOSCOL you need to update the STARTUP entry in the “best practice policy”
for SAP of the System Automation APL SAPSYSOS as follows:
Replace the STARTUP command:
INGUSS JOBNAME=&SUBSJOB,/bin/tcsh -c '/usr/sap/HA1/SYS/exe/run/saposcol -l >&
/u/ha1adm/saposcol.&SYSNAME..log'
with:
INGUSS JOBNAME=&SUBSJOB,/bin/tcsh -c '/usr/sap/hostctrl/exe/saposcol -l >& /u/h
a1adm/saposcol.&SYSNAME..log'
© 2010 SAP AG 17
SAP WebDispatcher 7.1
Installation
General Information
The SAP Web Dispatcher connects the Internet and the SAP System. The Web Dispatcher receives
requests from the internet (http/https) and forwards the request to an ABAP- or Java-Server. The incoming
requests are distributed among the application servers regarding their capacity weighting (the amount of
dialog-work-processes for AS ABAP and the amount of server processes for AS Java).
The Web Dispatcher has to be installed with its own SAP System Identifier (SID). This because it is planed
that up from SAP Netweaver 7.20 one SAP Web Dispatcher can handle several SAP Systems, SAP
Systems with different kernel versions.
There are two ways to install the SAP Web Dispatcher in z/OS Unix System Services (USS):
1. with SAP installation tool – you have to run it as a remote installation, because the GUI of sapinst
can not be started in USS.
2. with ZSCSinst for SAP Central Services on z/OS – a REXX script which is called from z/OS USS
command line. It simplifies the installation of SAP Central Services and of SAP Web Dispatcher.
The installation with ZSCSinst tool is similar to the installation of the SAP Central Services. As described in
chapter “SAP Central Services Installation on z/OS” the ZSCSinst tool can be downloaded from SAP Note
1322991 and follow the instructions from the SAP note and the the unpacked ZSCSInst_Instguide.doc
Make sure you use ZSCSinst version 710.7 or later. The version is displayed when running the command
without parameters from the z/OS Unix System Services shell:
./zscsinst
zscsinst version 710.7
Note: We recommend using ZSCSinst , because it is easier to handle and the installation is much faster.
In our environment the SAP Web Dispatcher has been installed with the ZSCSinst tool.
Installation with ZSCSinst tool on z/OS

With the ZSCSinst tool you can install the SAP Web Dispatcher on Unix System Services either through an
interactive command-line dialog or using predefined parameter files. The ZSCSinst tool provides a sample
parameter file for the SAP Web Dispatcher installation, which you have to adapt to your system definitions.
The virtual hostname has to be entered as the value of the parameter VIRTUALHOST within this file.
Here an example of the parameter file for ZSCSinst:

SYSTYPE=WD
VIRTUALHOST=sapwebdv
SAPSID=wd2
MOUNTDIR=/sapmnt
INSTANCENUMBER=88
WMSHOST=ha2ascsv
WMSPORT=8120
WDHTTP=58800
© 2010 SAP AG 18
Example invocation of ZSCSinst for SAP Web Dispatcher:

./zscsinst WD /u/admin/REXX/WEBDIS.WD2
After succesfull installation it is mandatory to follow the post installation steps like described in the ZSCSinst
Installation Guide.
With SAP NetWeaver Kernel 7.20 there is the possibility to manage with one SAP Web Dispatcher several
SAP Systems. This can be archieved by modifying the SAP Web Dispatcher instance profile. For each
wdisp_system enter the corresponding icm/server_port<x>, for example:
wdisp/system_0 = SID=BCO, MSHOST=bcomain, MSPORT=8127, SRCSRV=*:53548
wdisp/system_1 = SID=BIN, MSHOST=binmain, MSPORT=8082, SRCSRV=*:53547
icm/server_port_0 = PROT=HTTP,PORT=53548,
icm/server_port_1 = PROT=HTTP,PORT=53547,
For detailed information about SAP Web Dispatcher and its availablity please see the SAP Web Dispatcher
documentation in the SAP Library http://help.sap.com/ → SAP NetWeaver. Select the SAP NetWeaver
release and search for „SAP Web Dispatcher‟.
Installation with SAP installation tool

When calling SAPinst from the Unix System Services command line you need to specify the virtual hostname
using the option SAPINST_USE_HOSTNAME.
Example for ABAP Central Services installation:
./sapinst SAPINST_USE_HOSTNAME=sapwebdv -nogui
From sapinst main menu select the Standalone Engine –> Web Dispatcher
© 2010 SAP AG 19
During the sapinst dialog you will be ask for the SAP System Identifier and the parameters to connect to the
message server.
The parameters for the connection to the target SAP System are message server host and message server
HTTP port:
Entered the instance number for Web Dispatcher and the HTTP port number.
The HTTP port number is used for the logon via web-browser:
© 2010 SAP AG 20
Running under Automation Control

In order to automate the SAP WebDispatcher 7.1 utility under z/OS Unix System Services you have to create
two SA z/OS Applications:
 SAPWD2WD, a USS Application for the WebDispatcher itself, which has „Monitor Interval‟ of 1
minute (the minimum value of SA z/OS for USS Applications) and
 SAPWD2WV, which is a transient job to activate the VIPA belonging to the SAP WebDispatcher.
Both applications are in the Basic Group SAPWD2WDP of each system which are again contained in a
Syplex Move Group SAPWD2WDP_X. Under SA z/OS 3.2 we recommend that you create the Web
Dispatcher resources from a copy of the SAPRouter resources of the SAP „add-on‟ policy. Then change the
move mode of SAPWD2WDP_X to SERIAL.
STARTUP:
INGUSS JOBNAME=&SUBSJOB,/bin/tcsh -c 'startsap all W88 sapwebdv >&
/u/wd2adm/start_sapwebdisp.&SYSNAME..log'
SHUTNORM:
INGUSS JOBNAME=&SUBSJOB,/bin/tcsh -c 'stopsap all W88 sapwebdv >&
/u/wd2adm/stop_sapwebdisp.&SYSNAME..log'
USS Control specifications:
User ID WD2ADM
Process Command/Path wd.sapWD2_W88
© 2010 SAP AG 21
OMPROUTE Relationship Changes

In order to initiate a failover of the SAP Central Services and NFS server in the case of an outage of TCPIP,
you must add/change an existing ForceDown relationship between System Automation APL OMPROUTE
and TCPIP as follows:
Relationship Type FORCEDOWN
Supporting Resource TCPIP/APL/=
Condition WhenObservedAssumedDownOrStopping
This conditions results in a force down (hard down) of OMPRoute as soon as System Automation detects a
problem with TCPIP. A hard down OMPRoute in turn forces the SAP Central Services group(s) into a hard
down state and then SA moves them to another system. The groups are SAPHA1ASCS and/or
SAPHA1JSCS in our HA1 environment.
NFSSERV Relationship Changes
Note: you must remove OMPROUTE and PORTMAP from the AUTOLOG statement in the TCPIP profile, if both services
are managed as SA z/OS resources. Otherwise SA automation and TCPIP based restart can conflict.
The NFS server needs the PORTMAP and OMPROUTE resources to be available for proper operation so
you should introduce an additional HASPARENT relationship between System Automation APL NFSSERV
and PORTMAP and another HASPARENT between NFSSERV and OMPROUTE.
In order to trigger a failover of the NFS server in the case of an outage of PORTMAP or OMPROUTE, you
should add the following relationships System Automation APL NFSSERV on the one hand and PORTMAP
and OMPROUTE on the other hand as follows:
Supporting Resource PORTMAP/APL/=
and
Supporting Resource OMPROUTE/APL/=
These conditions results in a force down (hard down) of NFSSERV as soon as System Automation detects a
problem with either PORTMAP or OMPROUTE. It will cause the NFSSERV to move to another system.
Filesystem Recommendation
As already stated above, we recommend defining separate zFS filesystems for SCS and ASCS instance
directories in case of an ABAP and JAVA double stack installation. With a double stack installation there is
no technical reason why the SCS and the ASCS resources must run on the same z/OS LPAR. The SAP best
policy reflects this in the sense that there is no dependency between the resources.
© 2010 SAP AG 22
Also the enqueue server of each central services instance needs access to its own instance directory which
should – for performance reasons – be owned by the LPAR on which the enqueue server is running.
Having separate filesystems for the ASCS and SCS instance directories allows System Automation
independent placement of JAVA central services (SCS) from ABAP central services (ASCS) in your Sysplex.
If you define only one filesystem for both the SCS and the ASCS instance, you might encounter a situation
where System Automation places the SCS on a different z/OS LPAR than the ASCS. Since only one LPAR
can have the ownership of the filesystem the other (A)SCS will encounter a performance penalty.
To actually move filesystem ownership for example for /usr/sap/<SAPSID>/ASCS<xx> to which the ABAP ENQ
server need access, you must adapt the Prestart automation policy item accordingly. For an ASCS00 directory and
the associated Enqueue Server resource SAPHA2AEN change the prestart automation item as in the following
example:
PRESTART
MVS SETOMVS FILESYS,FILESYSTEM='OMVS.ZFS.&SYSPLEX..USRSAP.HA2.ASCS00',SYSNAME=&SYSNAME.
© 2010 SAP AG 23
Customizing Tivoli System Automation for Multiplatforms

Download and use the SA MP „best practice policy‟ for SAP as described in Software Prerequisites . Use
version saphasalinux-version6.0.tar or later.
The 6.0 version is an update of the previous 5.3 version. It:
- Supports SAP NetWeaver 7.1 technology
- Introduces a new naming of (A)SCS resources and groups that corresponds to SAP's naming
conventions. This is only of interest, if you plan to implement „Option 1B: Automation
using SA for z/OS, SA for MP, and SA AM‟ as described in
“Business Continuity for SAP on IBM System z (SC33-8206-02)”.
- Increases the MonitorCommandTimeout from 10 to 30 seconds to avoid Unknown status caused by
high system load.
- Supports the new MonitorUserName attribute to run Monitor Commands from root user which has
no dependency on NFS.
© 2010 SAP AG 24
Related Content
SAP Note 81737 ”DB2-z/OS: APAR List”
SAP Note 1326921 ”Updates are lost when restarting the ASCS instance”
SAP Note 1322991 ”ZSCSinst Installation tool for SAP Central services on z/OS”
SAP Note 1339004 “DB2-z/OS: Support of Logical Hostname in connect.ini”
SAP Note 1085521 “DB2-z/OS: Seamless JDBC Database Failover for SAP Java stack”
IBM documentation “Business Continuity for SAP on IBM System z (SC33-8206-02)” available from: IBM for
SAP High Availability Documentation
IBM product documentation: IBM Tivoli System Automation for z/OS
IBM product documentation: IBM Tivoli System Automation for Multiplatforms
SAP SDN: SAP for Banking on System z Reference Architecture
SAP SDN: SAP for Insurance on IBM System z Reference Architecture
© 2010 SAP AG 25
Copyright
© Copyright 2010 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9,
iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server,
PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,
BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,
Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of
Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by
Netscape.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned
herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered
trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document
serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP
Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
© 2010 SAP AG 26

Create Newlun 3par

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Create Newlun 3par

Hochgeladen von

Copyright:

Verfügbare Formate

Implementing High Availability for

SAP NetWeaver 7.1 Technology on

Authors: Harald Duvenbeck, Rainer Himmelsbach, Heike Schmidt, Volker Schölles

Installing and Customizing SAP 7.1 for High Availability

IBM Tivoli System Automation for z/OS

IBM Tivoli System Automation for Multiplatforms

Filesystem Setup on z/OS

Considerations for the Planned or Unplanned Move of the NFS Server

MVS SETOMVS FILESYS,FILESYSTEM='OMVS.ZFS.&SYSPLEX..SAPMNT',SYSNAME=&SYSNAME.

Description of Test Environment

System Setup - SAP System HA2

IBM System p IBM System p

LPAR 1 - AIX LPAR 2 - AIX LPAR 3 - AIX

Primary AS Instance Additional AS Instance Additional AS Instance

IBM System z IBM System z

Movable Services in Movable Services in Movable Services in

z/OS z/OS z/OS

static VIPA coh1vipa static VIPA coh2vipa static VIPA coh3vipa

= physical machine boundary

Configuration of the SAP File Systems

= zFS file system

sap = softlinked directories

exe global profile

data data data data

HA2 SAP system ID

SAP Central Services Installation on z/OS

Installation of Central Services and its ERS with ZSCSinst tool

Example parameters file ASCS.HA2 for ABAP Central Services

Example parameters file ERSA.HA2 of ERS for ABAP

Example invocation of ZSCSinst for Java Central Services Installation (SCS)

./zscsinst SCS /u/admin/REXX/SCS.HA2

Example parameters file SCS.HA2 for ABAP Central Services

Example parameters file ERSJ.HA2 of ERS installation for Java:

Example for ABAP Central Services installation:

Example for JAVA Central Services installation:

./sapinst SAPINST_USE_HOSTNAME=ha2ascsv –nogui

SAP Primary Application Server Instance

SAP Dialog Instance

SAP Post Installation Steps for HA

Multiple-Node Setup for a Highly Available SAP Application Server

Adaptations in SAP Profiles

c) In each ASCS/SCS/ERS profile change every occurrence of

Environment Adaptations for AIX and for Linux on System z

Adaptations for AIX

1. Comment out the start of automount in /etc/rc.nfs, as in this example:

while [[ $RC -eq 1 && $RETRY -lt $MAXRETRY ]];do

automd:2:wait:/etc/rc.local >/dev/console 2>&1

Adaptations for Linux on System z

### BEGIN INIT INFO

### BEGIN INIT INFO

Customizing Tivoli System Automation for z/OS

SAP JAVA Gateway

SAP JAVA Enqueue Server

SAP WebDispatcher 7.1

Installation with ZSCSinst tool on z/OS

Here an example of the parameter file for ZSCSinst:

Example invocation of ZSCSinst for SAP Web Dispatcher:

Installation with SAP installation tool

Running under Automation Control

Process Command/Path wd.sapWD2_W88

OMPROUTE Relationship Changes

Relationship Type FORCEDOWN

Supporting Resource TCPIP/APL/=

NFSSERV Relationship Changes