Skip to Content
Technical Articles

statement WRITE and alternatives

Dear community, small survey and discussion:

  1. Who else is still using the WRITE statement?
  2. In what situation are you using it?

I know, it’s a very old statement, but it doesn’t matter. There are rare cases in which it serves well for me: small correction reports, test reports and for output in background jobs.

There are alternatives to output some text or list entries. Here are some suggestions:

  1. MESSAGE statement
  2. function module POPUP_TO_INFORM
  3. SAP List Viewer (ALV)
  4. Class CL_DEMO_OUTPUT (maybe via console of ABAP Development Tools)
  5. Application Log

Other suggestions?

 

Best regards, thanks for reading and stay healthy

Michael

 

P. S.: Not tired of reading? Check this blog by Jörgen Lindqvist.

15 Comments
You must be Logged on to comment or reply to a post.
  • Hello Michael,

    The issue is not merely with the WRITE statement. It is the need of a generic Input/Output.

    I try to generate all output from a few routines (FORM, METHOD) so that I only have to port those to whatever target (the Cloud) will be next.

    1. Who else is still using the WRITE statement? - I do
    2. In what situation are you using it? - When I need to output in a GUI report

    CL_DEMO_OUTPUT is the most generic solution so far, but it fails for generic input in the Cloud.

    I am trying to figure out how to trick the RAP framework to generate an input dialog for a new entry in a Custom Entity exposed as a service that would be linked to my ABAP Class method.

    regards,

    JNN

  • Nice question, you mentioned an answer already: for output in background jobs.

    WRITE-statements go to the spool, while MESSAGE-statements got to the job-log.
    -> I like to utilize both.

    While I use MESSAGE for a higher-lever Info ( "A total of &1 orders processed; &2 success, &3 skipped"), I use WRITE for details: " Now Processing Order &1!" ; "Delivery &1 created for it".

    Tipp: If nothing was done, don't WRITE anything -> that way, you can easily see in the job overview that there is no spool -> nothing to check.
    (In the past I had wished SAPs WS_MONITOR_OUTB_DEL_PICK (= VL06p) would also work that way!)

    best
    Joachim

    • WRITE-statements go to the spool, while MESSAGE-statements got to the job-log.

      It is extremely important not to confuse the two! Speaking as someone who got woken up at 2 am because some developer thought it'd be a good idea to add WRITE 'No data found' to all the programs scheduled to run like every 5 minutes. And then the system ran out of the spool numbers. It was not fun.

  • I use WRITE-statements for "cobbled together" reports where I'd like to get different list-formats in one go which just isn't feasible to do in ALV. I for example created a program several years ago which extracts transport data and then lists the results in one output list but in different "sections":

    • List of transports grouped by user and showing ID, title, type, transport layer, date of last activitiy, system, released to prod or not
    • List of objects in the transports with ID, PGMID, OBJECT, Object-name, username, object-language
    • List of developers active during the selected data range if requested
    • Summary of ATC-results if requested
    • Program statistics
      # of Records read from E070CTV
      # of Transport-Requests :
      # of Transports w/o QA-approval
      # of Workbench Request
      # of Customizing Request
      # of PNRs in selection
      # of Transports with PNRs ("project numbers")
      % of Transports with PNRs
      # of PNRs without identifiable CTS
      # of relevant transports
      # of Objects for selected CTS
  • Still use WRITE for small test programs, just because it's quick to write. I'm talking about those quick 4-liners to test the behaviour of a command and so on.

    If it's more than a simple value then I switch to cl_demo_output or CL_SALV_*

    I am not a big fan of writing to spool, prefer to persist in the DB in a proper searchable format, even if it's just the SLG1 log.

    • Mike Pokraka

      Hi Mike!

      Your comment about using SLG1 makes me wonder: is there an easy way to do that which doesn't require setting up new (sub)objects, doesn't interfere with existing logs and only requires a few FM and/or method calls? It's been a while since I last actively utitlized it, so am curious of how you "just" do it.

      • Hi Bärbel,

        I meant "just" as opposed to a dedicated table. There is no single answer, as every project seems to have their own way of handling SLG1, so we could "just" slot into whatever is in use.

        In my experience any jobs would typically already have an object, so we tag onto that. Most background processes have an online equivalent so it's rarely the case that we'd have to create a sub/object just for one job. Failing that, create one 🙂

        Alternatively there are also open source options, such as ABAP-Logger that let you log stuff with a line or two of code.

        Hope that helps,
        Mike