ABAP_to_the_Future

The worst part of holding the memories is not the pain. It’s the loneliness
of it. Memories need to be shared.
—Lois Lowry, The Giver
14 Shared Memory
Unless you’ve been hiding under a very large rock for several years, you may
have noticed SAP pushing the in-memory database SAP HANA with all its might
nonstop. (Arguably, the high spot was when Hasso Plattner published a video
online of himself interviewing himself: https://www.youtube.com/watch?v=UrJ8m
J3cxvs.)
However, for those SAP customers who do n’t yet have SAP HANA in their systems
(which is about 99% of them at the moment) but do have a gigantic amount
of memory floating about unused, maybe the technology known as shared memory
is worth a bit of investigation. I heard a story about a company that went
from a 32-bit architecture to a 64-bit one. The CIO said to a programmer, “I have
a vast amount of memory now sitting th ere doing nothing; are you going to tell
me what I can use it for?” Yes, the programmer could. The irony of course is that
the use of shared memory actually reduces overall memory consumption.
More specifically, there are two problem areas shared memory is designed to
address: database access and memory usage.
Problems with database access arise wh en a vast number of users execute the
exact same database query simultaneously, clogging up the system. If you look at
Transaction SM66, then you can see what database tables are being accessed by
programs that users are running at any given instant. If the screen is full of red
blobs against users running transactions in dialog mode, then that is a Bad Thing,
because it means you have assorted users staring at hourglasses on the screen and
cursing SAP in general and the IT department (i.e., you) specifically for stopping
them from getting their jobs done. If the SM66 list gets long enough, then all the
work processes fill up, and then no on e can do anything until a new process
becomes available. (This would be even wo rse if the user had a customer on the
631