In this update for SAP on IBM i, we would like to call your attention to an issue that we have recently discovered in the SAP kernel releases 7.40 and 7.41. Note that this only applies to you if you have configured ES/TABLE=SHM_SEGS. If you are running with the default ES/TABLE=UNIX_STD, you will not experience this problem. While ES/TABLE=UNIX_STD is the default and used to be significantly faster in IBM i releases prior to IBM i 6.1, the alternative ES/TABLE=SHM_SEGS can be significantly faster in IBM i releases 6.1 and higher when hardware with a large number of processors is used.
If you follow our blog, you may remember that we introduced the memory model ES/TABLE=SHM_SEGS for SAP on IBM i through the update in July 2013: SAP Memory Model on IBM i. At that time, the switch was enabled and tested for SAP kernel release 7.20 at patch level 220.
With SAP kernel release 7.40, SAP has introduced a new paradigm for memory management in SAP. Prior to 7.40, a large set of memory management related profile parameters had hard-coded default values, while with 7.40 and beyond, these default values will be calculated based on the size of the main storage available (PHYS_MEMSIZE). The details of these changes are documented in SAP Note 1864189.
Even though not listed in this SAP Note, profile parameter ES/SHM_MAX_SHARED_SEGS will also be calculated in 7.40 and show values between 1 and 9 depending on the available main storage. When ES/TABLE=SHM_SEGS is configured and ES/SHM_MAX_SHARED_SEGS is calculated to a value larger than 1, your SAP instance will not come up because the dispatcher discovers a conflict between the parameters ES/SHM_MAX_SHARED_SEGS, ES/SHM_MAX_PRIV_SEGS and ES/SHM_PROC_SEG_COUNT. We are going to provide a kernel patch for release 7.40 and 7.41 in the near future. Until the patch becomes available, you can follow the instructions of SAP Note 1998233 to work around that problem.