SAP NetWeaver 7.x Kernel Updates Explained, Part II

See Part 1 of this blog.

Now let’s explore the update procedures in more detail. 

Binary distribution with SAPCPE

Before we go on with the procedures of different system types, it makes sense to have a closer look at how the kernel updates is distributed to the different instances of a Web Application Server. The graphic below depicts the file system layout of a typical system installation on UNIX (It’s similar on other operating system like Windows).

SAP Netweaver 7.x Kernel Updates Explained

Normally each system has a so-called SAPGLOBALHOST which is shared by all instances system-wide. The kernel files of all relevant platform combinations reside on this host under the directory ///exe. Each host in the system cluster mounts this global directory to its file system beside the instance-individual directories which are depicted with the left branch in the graphic. The system directory /usr/sap/SYS is shared by all instances on the host and maintain links to the global host so that all instances can access the global host via the links. Each instance on the host points to a subdirectory beneath the system directory with the instance-specific parameter DIR_CT_RUN.

When an instance starts, a bootstrap program called SAPCPE which itself is a kernel program comes into play first. The job of SAPCPE is to compare the binaries in the local-instance executable directory with the DIR_CT_RUN. If new versions of the relevant files are available in DIR_CT_RUN, it copies them to instance’s executable directory. In this way, new kernel updates are distributed to the instances.

However, in a heterogeneous system landscape, where the instances run on hosts of different operating systems, it is possible, that the DIR_CT_RUN directory of some hosts are not linked to the global host because of file format compatibility. Thus SAPCPE cannot copy the new version of the kernel files from the global host to the local executable directory. We will discuss the update process for this case later.

Standalone ABAP system

Now let’s discuss the update of the kernel update of a standalone ABAP system.

For a homogeneous system with only the ABAP engine, it is rather straight forward. Logon as the adm user onto the central instance host. After you have stopped the system and all OS-level services of all instances, unpack the kernel patch files SAPEXE.SAR and SAPEXEDB.SAR to the DIR_CT_RUN of the central instance. Execute the command as follows:

sapcar -xvf -R

Because DIR_CT_RUN of the central instance is linked to the corresponding directory on the global host which is accessible from all hosts in the cluster, the updates will be distributed by SAPCPE when the instances start as explained.

In a heterogeneous system landscape, if there are instances whose DIR_CT_RUN directory does not point to the system’s global host, you have to patch their DIR_CT_RUN separately like on the central instance host. You can find out the value of DIR_CT_RUN of a particular dialog instance using the transaction RZ11, if the instance is running. Another way is to use the kernel program SAPPFPAR which can be invoked for the Central Services Instances in a HA installation (ASCS) and idle dialog instances. The command spells as follows:

sappfpar pf=

The instance profiles are located in the /usr/sap/SYS next to the DIR_CT_RUN. For UNIX platforms, there is one thing you have to perform before you restart the system. Due to the security implementation of UNIX, you have to re-logon as a root user and execute the kernel script saproot.sh once in order to assign all necessary root permissions to the newly copied files.

Java and double-stack systems

Applying kernel updates to a Java system is a little bit different. Unlike SPAM in ABAP, the counterpart for Java systems (JSPM) is able to apply kernel updates too. Although you can update the kernel of your system like in an ABAP system as discussed above, why not just use JSPM? In this way, you can combine the applications of the kernel update and Support Packages of standard Software Component in a single run.

Nonetheless, JSPM does not take over all manual activities. Since you can perform JSPM (which is a central tool) only on the central instance host as the adm user, JSPM is not able to restart the OS-level services of all instances situated on different hosts. For kernel update to take effect to all instances, the OS-level services of the instances have to be restarted. Therefore, you also have to logon to the hosts of the system cluster and restart the instances manually once JSPM has finished the kernel update on the central host.

It is fairly common to run a Java engine along with an ABAP engine in the same system. This type of system is called double-stack system. In the case that the ABAP engine works with a non-Unicode kernel, while the kernel of the Java engine is always Unicode, JSPM will apply both parts of kernel. It does not matter that the non-Unicode kernel actually belongs to the ABAP part. All that needs to be done is to put the non-Unicode kernel into the JSPM inbox.

When using JSPM to update the kernel, JSPM consider all platforms (OS and Unicode vs. non-Unicode) of a heterogeneous system as a whole. Not only will it update all the kernels involved, it will also update the packages of all kernel parts available. The JSPM won’t proceed with applying the updates, as long as some of the required update packages of the involved platforms are still missing.  (See my Video Blog: Patching the SAP Kernel with JSPM https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/11791)

Please see my blog video on applying Applying Support Package Stacks using JSPM. https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/11219

I hope you now have a good grasp of the subject around SAP system kernel update.