Skip to Content

In a recent discussion I’ve seen someone was testing whether a loop was executed by placing a WRITE statement inside. Maybe it was a beginner’s error but maybe others tend to do that too. Since the discussion is locked, I say it here:

WRITE is not appropriate for error analysis.


WRITE writes to he list buffer (or to the SAP spool system). A display of the list buffer in form of a classic list only takes place after calling the list. An automatic call of a classic list happens only in the program flow of a submitted executable program. As a rule, in any other framework there is no automatic list display. Therefore, the fact that you don’t see any list output normally does not allow you to conclude that the WRITE statement was not executed.

  • For finding bugs during development, you use checkpoints (breakpoints, assertions, logpoints).

  • For testing during and after development you use module tests of ABAP Unit.

For the most of you this is crystal clear, but sometimes I get the impression that the knowledge about the fundamentals of classic ABAP programming – that unfortunately can freely be mixed into all the modern stuff – is taking a backseat more and more. Reminds me of the old days when I started with ABAP and also believed that WRITE is simply a kind of printf for creating a console output.

PS: As some of the below comments pointed out (thx), a more general rule would be:

Use WRITE only if you know what you are doing.

And that involves some knowledge about classic lists, because no, WRITE is not a printf.

But please be aware, that productive usage of WRITE is not recommended since long.  The point of this blog is that even non-productive usage of WRITE can be unfavorable and that you should be aware of that.

To report this post you need to login first.

23 Comments

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

  1. Amit Sawant

    Hi Horst, thanks for sharing this info

    the fact that you don’t see any list output normally does not allow you to conclude that the WRITE statement was not executed.

    Do we have an example where write is executed but there is no list output? or did you mean some other error/code is preventing the write from displaying…

    Thanks

    Amit

    (0) 
    1. Horst Keller Post author

      As simple as follows:

      CALL SCREEN 100.

      MODULE user_command_0100 INPUT.

         WRITE ‘Blah’.

      ENDMODULE.


      Already in classic dynpro programming there is no list output  if you don’t call it with LEAVE TO LIST-PROCESSING.


      And now think about frameworks that don’t rely on SAP GUI at all …

      (1) 
    2. Loyd Enochs

      Amit, another example is when the START-OF-SELECTION event is not explicity coded but another event, such as AT SELECTION-SCREEN is.

      True, this is a programming error, but is easy to do when the users come back with a change to the functional requirements during QA testing – not that such a thing could ever happen 😯 –  and a screen validation and event are hastily added.

      Another reason to make a program template accessible in the PATTERN button, but that is a whole other topic…… 😉

      (0) 
      1. Horst Keller Post author

        Yep, in code:

        REPORT ...

        PARAMETERS p.

        AT SELECTION-SCREEN.

           WRITE ‘BLah’.

        No list output. Why? Each dynpro sequence has its own list buffer and the above WRITE statement writes to the list buffer of the selection screen.

        PARAMETERS p.

        AT SELECTION-SCREEN.

           WRITE ‘BLah’.

           LEAVE TO LIST-PROCESSING.

        Now a list output but without GUI status, haha …

        (0) 
  2. Jelena Perfiljeva

    Thanks, Horst! One more point to add – it’s also bad when WRITE is used to output messages in a background job instead of MESSAGE.

    We had an issue a while ago when some consultant thought it was a great idea to add something like WRITE: / ‘Nothing happened’ in a program that ran every 10 min. and was not expected to do something every time. So in a few days our SAP crashed at night because it ran out of spool numbers.

    Do not use WRITE unless it is actually required and expected to produce a list.

    (1) 
    1. Joachim Rees

      [Edit: what you experienced as a problem, I use as a feature:]

      I actually like using “write” in reports that run as jobs, to produce some kind of protocol;

      But if ‘Nothing happened’, I don’t use write.

      That way, I only get a spool, if the job actually did something -> that way, in the job overview (SM37), you see at firts glance which jobs might be worth looking at.

      (I often whished VL06p would behave like that!)

      My Tipp:

      In Jobs MESSAGE goes to the Job-Log, WRITE goes to the spool -> if you know this, you can make use of it.

      best

      Joachim

      (0) 
      1. Jelena Perfiljeva

        Joachim, we are on the same page here and we do the same thing. It’s actually quite convenient when a spool can be created on purpose and we can simply add a recipient list in a background job to get a notification by email when there is some exception.

        (0) 
    2. Chaouki AKIR

      If your system does not support the creation of a spool each/per 10 minutes then the problem is not the fellow “developer”, the problem is your system.

      (0) 
      1. Jelena Perfiljeva

        Chaouki AKIR wrote:

        If your system does not support the creation of a spool each/per 10 minutes then the problem is not the fellow “developer”, the problem is your system.

        So by this logic if a “system” can’t handle a poorly written SELECT then it would be its problem too? Sorry but I’d have to disagree. When there is a legitimate business requirement to have gazillions of spools it’s one matter and when it’s sloppy programming it’s another.

        (0) 
        1. Chaouki AKIR

          I thank you for sharing your experiences and your knowledge.

          So by this logic if a “system” can’t handle a poorly written SELECT then it would be its problem too?

          It is not the same logic. It is not the same to have a poorly written SELECT (this should be avoided).

          In your previous message you write about a program that :

          ran every 10 min

          ==> It means a program that creates one spool (of one line) every 10 minutes.

          ==> 6 spools per hour

          ==> 144 spools per day

          ==> 1008 spools per week

          ==> 4320 spools per month

          ==> it can be legitimate to have this kind of requirement (as you said)

          ==> My supposition is that it might not be the only reason to run out of spool in few days

          So in a few days our SAP crashed at night because it ran out of spool numbers.

          I checked in “our system” production system and at this time there is 43374 spools. The oldest spool has been created on 1Sept2016 (all previous spools have been deleted).

          • september 1: 14034 (monthly jobs)
          • september 2:  6562
          • september 3:  2642 (saturday)
          • september 4:  1436 (sunday)
          • september 5:  7018
          • september 6:  8114
          (0) 
          1. Jelena Perfiljeva

            Chaouki AKIR wrote:

            It is not the same to have a poorly written SELECT (this should be avoided).

            It is the same in a sense that both are poor programming practices.


            There is no reason to write inefficient or redundant ABAP code. The system capacity does not matter here, it’s the principle.

            (0) 
            1. Daniel BD Nguyen

              I guess what he was trying to say is, it could be bad programming practice along with some bad system configurations. It’d be interesting to have a check in your system as well, see his analysis above.

              (0) 
              1. Jelena Perfiljeva

                The story I mentioned occurred 10 years ago, so I can no longer check anything. It was merely an illustration of what a bad programming practice could lead to.

                Of course, bad ABAP could also be compounded by other issues but what does it change fundamentally? Take away the other issue and bad ABAP is still there. It’s like having two STDs. Sure, just one would be better but it’s still an STD.

                (1) 
  3. Rob Dielemans

    Hi Horst,

    I usually test with message type X mostly  x016(rp), if I want to test if something is carried out or not. Beats creating endless loops when you’re only interested in the question ‘will this line be executed’.

    Kind regards,

    (0) 

Leave a Reply