Skip to Content
Author's profile photo Richard Harper

Be Nice Now…..

There are some legitimate cases where you may want to wait a short while in your program for something to happen.  One thing I use a wait on is when I have a program running and it encounters a lock.  This is ok when you are displaying a single record – you just tell the user that it’s locked.   However,  if you are compiling an editable ALV grid for example you don’t want to stop them editing some records because one is locked.

What I do is wat a second or so,  and try again.  If the record is still locked I wait a little longer,  before after a certain number of times giving up and continuing on with the next record,  flagging the failed record as not locked.

But when you wait are you polite or do you still hog the work process ??

Instead of using the ‘WAIT’ statement use the ‘ENQUE_SLEEP function module.  The function module releases the work process for another task to use.  The WAIT does not….

Rich

Assigned Tags

      7 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Rob Dielemans
      Rob Dielemans

      Are you sure? I just tested with a test program and checked in SM50 to see if a process is reserved or not.

      I see the opposite. Or does this only work in background processing and not dialog?

      also why is this function module only used in 1 sap standard report (RPMEN1FI)

      Author's profile photo Richard Harper
      Richard Harper
      Blog Post Author

      Hi Rob,

      I first came across this about 20 years ago and I was struck by the fact that the WP was released.  I've tried to find the original documentation for this but I have had no luck unfortunately but I'll keep looking.

      Regards

      Rich

      Author's profile photo Naimesh Patel
      Naimesh Patel

      I would rather prefer the ENQUE_SLEEP over WAIT as WAIT triggers explicit COMMIT WORK and does Rollout/Rollin for all loaded programs every time it gets executed.

      As this help page mentioned: WAIT UNTIL - Application Development on AS ABAP - SAP Library

      The statement WAIT causes a switch in the work process, which is linked to the rollout and rollin of all loaded programs. For this reason, the time given in sec must not be less than one second, to avoid burdening the system with too many work process switches.

      Each time the statement WAIT is used, a database commit is performed. WAIT must therefore not be used between Open SQL statements that open or close a database cursor.

      These would become costly when you wait for 1 seconds for 100 times.

      Also, due the COMMIT WORK - Operation on DB, you will not be able to use the WAIT when you are selecting the data using the FETCH NEXT CURSOR as it would be closed after WAIT.

      Thanks,

      Naimesh Patel

      Author's profile photo Clemens Li
      Clemens Li

      Why not use the wait = abap_true parameter of enqueue function?

      Thanks,

      Clemens

      Author's profile photo Naimesh Patel
      Naimesh Patel

      Hello Clemens .. It would work if the WAIT for to check lock. If you have to WAIT to see if some other event, like File is moved by another 3rd party app.

      Thanks,
      Naimesh Patel

      Author's profile photo Richard Harper
      Richard Harper
      Blog Post Author

      Hi,

      It's just teh 'WAIT UNTIL' version that triggers a switch in the WP,  but they both cause a commit work.

      Regards

      Rich

      Author's profile photo Clemens Li
      Clemens Li

      Hi Rich,

      not a COMMIT WORK but a database COMMIT. COMMIT WORK will also trigger all queued UPDATE tasks, i.e. execution of FUNCTIONs called IN UPDATE TASK or FORMs calls with PERFORM ON COMMIT.

      In many cases results may be comparable but frequently it makes a difference.

      Every interruption of a process, i.e. screen output (such as messages or dialog screens), every RFC call, every WAIT and every transactions(reports) end will cause a database commit.

      Thanks

      Clemens