Skip to Content

In my current position, I don’t write very much code.  In fact, the only code I write is usually operating system level scripts for reporting purposes, and that’s not a large part of my responsibilities.  However, since I often look for performance issues in our enterprise systems, I read a lot of code.  Usually, this code is ABAP, whether written and delivered by SAP, or modified or created entirely in-house. Despite the fact that I don’t write ABAP code, I know a fair bit about what works well and what doesn’t.

The ABAP code that goes to the database is translated into SQL.  Though I’m no longer a full-time DBA, I can find poor performing SQL manifesting itself in various ways.  The code that doesn’t go to the database is another story.  Before that story, a short digression about reading code.


About 5 years ago, I bought the book by Diomidis Spinellis called “Code Reading: The Open Source Perspective“.  The author’s goal was to share techniques for looking at legacy programs in order to determine ways to maintain and improve it, by first understanding the logic.  Along the way, developers should pick up clues that lead to better writing.

As might be obvious by the title, the book examines open source code, as this base is widely available, freely sharable, and perhaps as a result of being contributed by multiple authors, sometimes in need of tuning or complete overhaul.  Is this true of ABAP code?  I’ve heard a few stories.

Dr. Spinellis’ Code Reading book is translated into Chinese, Greek, Japanese, Korean, Polish and Russian.  Also look for his sequel: Code Quality, and his newest release, with Georgios Gousios,Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design — “The book’s royalties are donated to the international humanitarian aid organisation Médecins Sans Frontières.” 


Meanwhile, as they used to say on the TV and movie serial shows (back at the ranch), a common dilemma in parallel operations is that one process finishes before another.  If your code depends on a database commit, an operator pushing a key, or a file to be copied from one place to another, you need to wait. The wait time required might be sub-seconds, or longer, and is often not known, or not even thought about, until the code is in production and real users find issues not seen in development.

So, what is your preferred method of waiting?  Are you a pacer?  Are you someone who sits and reads a book or magazine in the waiting room?  Or are you a snoozer, who sets an alarm or asks for a wakeup call?


In my role as software quality reviewer, I look at system statistics, of which SAP provides an overwhelming quantity.  After exhausting the first analysis at the database level, using tools such as ST04 SQL Cache Analysis, I have looked at performance traces at the application server level (ST05), memory caches (ST02) and at CPU workload statistics (ST03).  The last of these sometimes tells a funny story, where more work is being done on the application server than on the database.  A few years ago, I found code that was written to do nothing but wait.  It looked a little like this:



    C_DELAY(8)    TYPE N   DEFAULT 5000000.


What does this code do?  Besides waiting, I mean.  It counts.  From 5 million to zero.  Or maybe to one, not that it matters.  It reminds me of youthful games of hide-and-seek, where the seeker is required to delay by saying “One-Mississippi”, “Two-Mississippi”, etc. until the hiders have hidden.  

What’s the problem, you say?  This code does what is intended, it delays the execution of the next program step, as required.  The way I found out about this was when we installed newer hardware, and the developers told me “our delay loop isn’t waiting as long as before”.  The logic depends almost entirely on the specific system hardware to work correctly.

The biggest problem, which you have hopefully seen by now, is that the code uses CPU resources, and does no work.  When this code runs, it kicks out useful programs and sits on a CPU, quietly moving bits from one register to another, until it is done.


I’m not sure about developers where you work, but I’m guessing if you asked one in your shop to fix the above, they might say, “But, it isn’t broken.  It does what I want.”  It might take a few reports (see ST03 above) to management and patient explanation that correct answers don’t always imply well-written code.  The point of this blog isn’t to show you better ways to write your code, just to hint that you might consider doing so.  Here are a few options for this specific case, none of which I specifically recommend for any purpose (in other words, run your own tests).

The code gallery example is fairly self-explanatory, though the wiki page itself needs a little gardening.  The 2 function calls are documented in various places; one of my expert references (a person, not a book) said the FMCT call can be used in CATT scripts, which might not work with enqueues.  The “WAIT UP TO” seems almost too obvious a code construct, so again, run your own tests.

Another alternate would be to let the operating system manage the delay, using the UNIX “sleep” command or a Windows alternative.  These should be smart enough not to consume CPU, setting alarms that trigger after the appropriate interval.

Yet another option is to use a 3rd party external scheduling tool, with features that manage process relationships and dependencies, if the time delay is well above the second mark.


As it turns out, not every piece of bad code is simply a candidate for being exemplified as  “don’t do it this way”, once in a while (or: meanwhile in the Saturday afternoon movie serial) we can reuse code in other ways.  Once I observed that this loop was hardware dependent, I knew this would be one way to compare hardware.


The graph shows results from different hardware that I have tested, using the same 5,000,000 loop ABAP program.  The years are approximate, and it isn’t important what hardware this is, just the observation that things change.

One final note: in the same CPU family, I found different results even at the exact same clock speed.  This unexpected result tells me that more is going on than an on-CPU logic operation, with memory paging, I/O or other factors an additional influence.  As they say in the movies, “to be continued”.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Reto Probst
    Thanks for the information. I compared my always used method and the function module ENQUE_SLEEP.

    Here my old used method:

    DATA: l_time TYPE syuzeit,
          ls_time TYPE syuzeit.

    GET TIME FIELD ls_time.
    ls_time = ls_time + 300. ” 300 seconds

    WHILE l_time<ls_time.
      GET TIME FIELD l_time.

    The average CPU use for 5 minutes of delay was as follows:

    Function Module: 30
    My old solution: 262,490

    In future I will use  the function module.

  2. Krishnakumar Ramamoorthy

    Good find and well written blog. Yes, I hate to use “wait” statements or for the fact any deliberate delay in programs but have done it myself, especially when commit work and wait isn’t just enough to do an immediate select for the updated entries in the database.
    Many times we have split the process in to individual sub processes and handled through scheduling tools like Redwood as well.
    Interesting to see how far we have come hardware wise. Well who would have thought we will have gigs of space in free email 6 to 7 years back 🙂

  3. Michael Nicholls
    A few years back when I worked for DEC (OK, I joined DEC, I left Digital, but that’s another story) we released a new chip that was claimed to have the world’s fastest infinite loop. In fact, some people claimed (jokingly) that by having a really tight loop..endloop which did nothing, it would cause the CPU to melt!
  4. Somnath Manna
    Looks like your Wiki gardening effort is keeping you busy from mundane activities like code reading and hunting for clues in the system.
    Well recently I got my ABAPer to develop a From Functional to Technical – Part 4 where there is a wait of 30 seconds till a check is carried out on user lock entries (giving user 30 seconds to react). Will have to keep an eye on that program if and when hardware changes.
    1. Jim Spath Post author

        Thanks for the compliment!  Lately I have been working on a server refresh project, and many of the benchmarks I have run or investigated are covered by non-disclosure agreements.  SAP altered the SD benchmark procedures — 2-tier, 3-tier and SD-parallel, including lowering the dialog response time limit from 2 seconds to 1 second.  You can read the details in their January2009newsfaq pdf file.



Leave a Reply