<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1505" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV dir=ltr align=left><SPAN class=996551118-12072005><FONT face=Arial>We had
the same problem. </FONT></SPAN><SPAN class=996551118-12072005><FONT
face=Arial><SPAN class=996551118-12072005>When I found that
the </SPAN>background job SWWDHEX<SPAN class=996551118-12072005> was
not working, I used</SPAN> SWWB<SPAN class=996551118-12072005> to have
it fixed.</SPAN></FONT></DIV>
<DIV dir=ltr align=left>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=996551118-12072005></SPAN><?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" /><o:p><FONT
face=Arial> </FONT></o:p></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><FONT face=Arial><SPAN
class=996551118-12072005>Here is an </SPAN>OSS explanation: "The job SWWDHEX
that is required for date monitoring, sometimes no longer reschedules itself and
therefore disappears almost inexplicably. ... The job SWWDHEX runs at the same
time as the job SAP_REORG_JOBS. The latter blocks the table TBTCO and stops the
job SWWDHEX from rescheduling itself. As SAP_REORG_JOBS usually takes several
seconds, the implicit waiting that is built-in to the background management (see
note 41037) does not suffice for the lock to be released in this case. You must
therefore ensure that both jobs are not run at the same time. As SAP_REORG_JOBS
usually runs at the most once a day, the execution of SWWDHEX is only prevented
for the duration of this job."<SPAN class=996551118-12072005> Our Basis team
followed the instruction and since then we have not had this problem
anymore.</SPAN></FONT></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><o:p><FONT
face=Arial></FONT></o:p> </P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><o:p><SPAN
class=996551118-12072005><FONT face=Arial>I hope that the above info can
help.</FONT></SPAN></o:p></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><o:p><SPAN
class=996551118-12072005></SPAN></o:p> </P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><o:p><SPAN
class=996551118-12072005>Larry Hu</SPAN></o:p></P></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<B>From:</B> sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] <B>On
Behalf Of </B>Rick Sample<BR><B>Sent:</B> Tuesday, July 12, 2005 9:11
AM<BR><B>To:</B> sap-wug@mit.edu<BR><B>Subject:</B> Re: rswwdhex - job gets
cancelled due to locking issue<BR><BR></DIV>
<DIV></DIV>
<DIV>Had the same issue. Here is what I found and what we did to correct.
</DIV>
<DIV> </DIV>
<DIV>If multiple instances of SWWDHEX are running we get locks. I verified
and </DIV>
<DIV>can reproduce this and fixed. Here is what I did. </DIV>
<DIV>Kill all SWWDHEX and have BASIS reschedule just one. </DIV>
<DIV>Schedule SWWDHEX to run every X time. </DIV>
<DIV> </DIV>
<DIV>Still don't know why it stopped but I assume I ran the config as myself.
SWU3 </DIV>
<DIV>and caused mult instances to be running. </DIV>
<DIV>BASIS probably runs SWU3 for the simple fact that it SWU3 should only
be run </DIV>
<DIV>by a user that has SAP_ALL / SAP_NEW. </DIV>
<DIV>Reason: WF-BATCH inherits the rights of the user running SWU3. No
more. No less. </DIV>
<DIV>(You can search for responses from Jocelyn Dart and in "Practical WF for
SAP".)</DIV>
<DIV> </DIV>
<DIV>WF-BATCH should not be used for batch processing like
SWWDHEX, SWWERRE, SWWERRE, etc. </DIV>
<DIV>Use some other batch user for batch processing. </DIV>
<DIV> </DIV>
<DIV>SWWA set to run periodically. Like every 5 mins. </DIV>
<DIV>SWWB runs per instance of a deadline. </DIV>
<DIV>(I could have these backwards. Look them up to be sure)</DIV>
<DIV>
<DIV> </DIV>
<DIV>SWWA or SWWB? Depends on what you want. </DIV>
<DIV>If you have few deadlines, run per instance and it will add a batch for
</DIV>
<DIV>each instance. See SM37 and you will see these being added per deadline.
</DIV>
<DIV>Or, if you have lots of deadlines. set to just periodically, it
should rescheduled ONE </DIV>
<DIV>instance to run every X time. </DIV>
<DIV> </DIV>
<DIV>Let me know if this helps. I am interested in what works for you. </DIV>
<DIV>(And if I made any incorrect statement I am sure someone will let me
know)</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Rick Sample<BR>SAP Workflow Analyst/Developer<BR>Graybar, Inc.<BR>11885
Lackland Rd.<BR>63146-4208<BR>314.573.5822<BR><A
href="mailto:Rick.Sample@GBE.com">Rick.Sample@GBE.com</A></DIV>
<DIV><BR>>>> keohan@ll.mit.edu 7/12/2005 7:34 >>><BR>Hi
all,<BR><BR>We are running on R/3 4.6c.<BR><BR>We had RSWWDHEX running without
incident until last September, when it stopped, I don't know why.<BR>When the
matter was brought to my attention, we re-scheduled it via SWWB (or is it SWWA,
I can't be <BR>sure because Basis does it). The interval between runs is 20
minutes, which should be sufficient, <BR>since there are probably less than 5
workitems 'waiting' for a deadline at any given time.<BR><BR>Anyway, the job
gets finishes, but fails to reschedule itself daily (no specific time, it could
fail <BR>to reschedule at 5:30, it could fail to reschedule at 7:30...). The
system log from SM21 says<BR>'Job SWWDHEX is currently locked' and the detail
entry follows:<BR><BR>> Within background processing, it was found that the
specified job is <BR>> being edited, for example, another user edits the job
or the run-time <BR>> system of background processing is accessing the job.
Please attempt to <BR>> execute the action required by you with the job at a
later date. <BR>> <BR>> If, in spite of repeated attempts, this should not
be successful, that <BR>> could be related to problems in the locking system
(enqueue server): For <BR>> example, "locking corpses" could be available.
Please check that with <BR>> the transaction SM12. You can also test the
function efficiency of your <BR>> locking system there by means of the
displayed diagnosis. <BR>> <BR><BR>I am sure we can reschedule with a longer
interval between runs, but not sure if this will actually <BR>solve the problem.
Has anyone out there dealt with this ? OSS, and SDN search of this archive
<BR>yield no joy.<BR><BR>Happy WF-ing!<BR>Sue<BR>-- <BR>Susan R. Keohan<BR>SAP
Workflow Developer<BR>MIT Lincoln Laboratory<BR>244 Wood
Street<BR>LI-200<BR>Lexington, MA. 02420<BR>781-981-3561<BR><U><A
href="mailto:keohan@ll.mit.edu">keohan@ll.mit.edu</A></U>
<BR>_______________________________________________<BR>SAP-WUG mailing
list<BR><U><A href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</A></U> <BR><U><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A></U>
<BR><BR></DIV><div id="##disclaimer##"><p></p><p style="FONT-SIZE: x-small; FONT-FAMILY: Arial, Sans-Serif">This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.</p></div></BODY></HTML>