Fix typos simplemount sle16

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-administration.adoc

@@ -93,7 +93,7 @@ Stop the Linux cluster on all nodes:
 # crm cluster stop --all
 ----
 
-You can now perform maintenance on the Linux cluster or system. Before performinc maintenance, 
+You can now perform maintenance on the Linux cluster or system. Before performing maintenance,
 stop any SAP instances as necessary. If you stopped the SAP instances, start them before
 activating the cluster.
 
@@ -233,7 +233,7 @@ go into production with your cluster.
 
 ==== Checking product names with HAGetFailoverConfig
 
-Verify that the name of the SUSE cluster solution is shown in the output of
+Verify that the name of the {SUSE} cluster solution is shown in the output of
 `sapcontrol` or the {sap} management console. This test checks the status of the
 {sapS4} cluster integration.
 
@@ -295,7 +295,7 @@ As user _root_, type the following command:
 
 ==== Restarting ASCS in-place using `Stop` and `Start`
 
-Verify that the in-place restart of the {sap} resources succeeded. 
+Verify that the in-place restart of the {sap} resources succeeded.
 The {sap} instance should not failover to another node. It starts on the same node where it stopped.
 
 ////

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-cluster.adoc

@@ -26,7 +26,7 @@ is reserved for SBD usage.
 
 === Preparing the operating system and installing the cluster software
 
-- Set up and enable `chrony` with `yast2`.
+- Set up and enable `chrony`.
 
 // TODO PRIO3: pattern sap-nw?
 // - Install the RPM pattern *ha_sles* and package `sapstartsrv-resource-agents` on both cluster nodes.

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-multinode.adoc

@@ -5,7 +5,7 @@
 Depending on the starting point, you can or extend a two-node cluster setup
 or directly start with more than two nodes for an ASCS / ERS high availability setup.
 The following examples show how to set up a multi-node cluster and how to extend
-an existing two-node cluster. They outline major configuration changes and the basic 
+an existing two-node cluster. They outline major configuration changes and the basic
 preparation of a new member node.
 The task list for setting up a three-node cluster is similar to the task list for a
 two-node cluster. However, some details differ to allow for a diskless
@@ -47,7 +47,7 @@ SBD in diskless mode cannot handle split brain scenarios for two-node clusters.
 ==== Preparing the operating system and installing the cluster software
 
 In general the OS preparation is similar to the procedure described for the two node cluster.
-This includes the setup of NTP as well as installing the software pattern `ha_sles` using `yast2` or `zypper`.
+This includes the setup of NTP as well as installing the software pattern `ha_sles` using `zypper`.
 
 ==== Preparing watchdog and SBD parameters for diskless SBD
 
@@ -193,7 +193,7 @@ Adapt the cluster *fencing-watchdog-timeout* for diskless SBD:
 For diskless SBD, this parameter must not equal zero. It defines after how long
 it is assumed that the fencing target has already self-fenced. Therefore, its
 value needs to be >= 2 times value of SBD_WATCHDOG_TIMEOUT in _/etc/sysconfig/sbd_ .
-See maunal page crm(8) for detals on calculating timeout. 
+See maunal page crm(8) for detals on calculating timeout.
 
 ==========
 
@@ -225,15 +225,15 @@ for the two node cluster.
 
 ==== Backing up the current cluster
 
-To *back up the current cluster*, perform a 
+To *back up the current cluster*, perform a
 ==========
 
 * Backup of your system including
 ** cluster configuration
 ** corosync.conf
 ** all data and configuration which are important and customized and not default
 
-The system is configured as described in the SUSE Best Practices document
+The system is configured as described in the {SUSE} Best Practices document
 __SAP S/4 HANA - Enqueue Replication 2 High Availability Cluster With Simple Mount - Setup Guide__.
 
 To *back up the cluster configuration*, go to one of the cluster nodes and save
@@ -246,7 +246,7 @@ the cluster configuration with the _crm_ and _crm report_ commands:
 ----
 
 Back up the existing _/etc/corosync/corosync.conf_ and all other files required to restore the system.
-The following example is one method for creating a backup. 
+The following example is one method for creating a backup.
 The important step is storing the backup on an external destination.
 
 [subs="specialchars,attributes,quotes"]
@@ -302,7 +302,7 @@ There are multiple ways to do so:
 # ping <hostname>
 ----
 
-- Set up `chrony` (this is best done with `yast2`) and enable it:
+- Set up `chrony` and enable it:
 +
 [subs="specialchars,attributes,quotes"]
 ----
@@ -403,7 +403,7 @@ configurations as the two existing nodes
 
 With SWPM 2.0 (SP4 or later), which is part of the SL Toolset, SAP provides a new
 option which can perform all necessary steps to prepare a fresh install server to
-be able to fit into an existing SAP system. This new option helps  to prepare
+be able to fit into an existing SAP system. This new option helps to prepare
 a new host which can later run either ASCS or ERS in the cluster environment.
 
 Create the directory structure that should run the SAP resource.
@@ -463,7 +463,7 @@ The next step requires the following information:
 # /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/<SID>/SYS/profile/<SID>_ASCS<instanceNumberAscs>_<virtHostNameAscs> -reg
 ----
 +
-NOTE: This must be done for each instance. 
+NOTE: This must be done for each instance.
 Call `sapstartsrv` with parameters *pf=*<profile-of-the-sap-instance> and *-reg*.
 +
 

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-overview.adoc

@@ -46,7 +46,7 @@ The number of nodes within one cluster should be either two or an odd number.
 ////
 TODO PRIO2: check text content
 ////
-// TODO PRIO1: 
+// TODO PRIO1:
 // NOTE: Because the setup at hand focuses on the {sapCert} certification, the cluster described
 // in this guide only manages the {sap} instances ASCS and ERS.
 NOTE: The cluster described in this guide manages only the {sap} central services
@@ -56,10 +56,10 @@ For the {sapHana} database, we recommend setting up the performance-optimized
 // TODO PRIO1: make {sapHanaSR} work
 system replication scenario with {sapHanaSR}. The
 {sapHanaSR} solution should be set up in a separate two-node cluster. The setup is
-described in a separate best practices document available from the SUSE Best
+described in a separate best practices document available from the {SUSE} Best
 Practices on documentation portal at https://documentation.suse.com/sbp/sap-16/.
 
-.Typical systems 
+.Typical systems
 // TODO PRIO1: for the certification setup
 image::sles4sap_s4hana_simple_fs02.svg[SVG]
 
@@ -80,7 +80,7 @@ image::sles4sap_s4hana_simple_fs02.svg[SVG]
 
 === Implementing high avaiability for the {SapHana} databse - optional
 
-We recommend implementing {saphana} system replication (SR) automation to enhance the scenario described 
+We recommend implementing {saphana} system replication (SR) automation to enhance the scenario described
 in this document.
 
 .One cluster for central services, one for {saphana} SR
@@ -108,10 +108,10 @@ The integration of the HA cluster through the SAP control framework using the
 instances starting with {sap} Kernel versions 6.40. One of the classic problems running
 {sap} instances in a highly available environment is the following: If an {sap}
 administrator changes the status (start/stop) of an {sap} instance without using
-the cluster software interfaces, the cluster framework detects that as an error status. 
-The framework then restores the {sap} instance to its previous status by either starting 
-or stopping it. This can result in very dangerous situations, if the cluster changes the 
-status of an {sap} instance during some {sap} maintenance tasks. 
+the cluster software interfaces, the cluster framework detects that as an error status.
+The framework then restores the {sap} instance to its previous status by either starting
+or stopping it. This can result in very dangerous situations, if the cluster changes the
+status of an {sap} instance during some {sap} maintenance tasks.
 The new updated solution enables the central
 component `{SAPSTARTSRV}` to report status changes to the cluster software. This
 avoids dangerous situations as previously described.

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-sap.adoc

@@ -156,7 +156,7 @@ ASCS needs to be registered.
 # /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/<SID>/SYS/profile/<SID>_ASCS<instanceNumberAscs>_<virtHostNameAscs> -reg
 ----
 
-After registration, the list of systemd services must be the same and should like:
+After registration, the list of systemd services must be the same and should look like:
 
 [subs="specialchars,attributes"]
 ----
@@ -244,8 +244,9 @@ See also manual pages sap_suse_cluster_connector(8), usermod(8) and groupmod(8).
 // TODO PRIO1: to match the {sapCert} certification
 
 For the ASCS instance, change the start command from _Restart_Program_xx_ to
-_Start_Program_xx_ for the enqueue server (Enqueue Server 2). This setting prevents the
-{sap} start framework from automatically restarting the enqueue process. A restart results in lost locks..
+_Start_Program_xx_ for the enqueue server (ENSA2). This setting prevents the
+{sap} start framework from automatically restarting the enqueue process. A restart
+results in lost locks.
 
 File */usr/sap/{mySid}/SYS/profile/{mySid}_{myInstAscs}_{myVipNAscs}*:
 
@@ -258,7 +259,7 @@ Optionally, you can limit the number of restarts of services (in the case of
 ASCS, this limits the restart of the message server).
 
 For the ERS instance, change the start command from _Restart_Program_xx_ to
-_Start_Program_xx_ for the enqueue replication server (Enqueue Replicator 2).
+_Start_Program_xx_ for the enqueue replication server (ENSA2).
 
 File */usr/sap/{mySid}/SYS/profile/{mySid}_{myInstErs}_{myVipNErs}*: