rswwdhex - job gets cancelled due to locking issue

Wed Jul 13 07:57:38 EDT 2005

Hi Sue,
You've definitely got two schedules running. Get rid of ALL deadline
monitoring jobs and then schedule one job & you should be OK.
Cheers
Mike

Sue Keohan wrote:
> Hello all,
>
> Aaarrghh.   Tonight the system log shows...
>
>
>  19:40:32 sapapp1_RP1_23       BTC 28 400      EGC > Job SWWDHEX is
> currently locked
>  19:40:38 sapapp1_RP1_23       BTC 28 400      EGC > Job SWWDHEX is
> currently locked
>
> Thank you Larry, but SAP_REORG_JOBS runs after midnight, still more than
> 4 hours from now.
>
> What annoys me is that the job ran 17 times today, no problem.  At
> 19:40, two instances kicked off (under the same userid) and killed each
> other.
> Probably need to escalate this to OSS.  Till then, SWWB might be my new
> best friend.
>
> Thanks all for the help,
> Sue
> lianghuan.x.hu at accenture.com wrote:
>
>> We had the same problem. When I found that the background job
>> SWWDHEX was not working, I used SWWB to have it fixed.
>>
>>
>>
>> Here is an 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." Our Basis team followed the instruction and
>> since then we have not had this problem anymore.
>>
>>
>>
>> I hope that the above info can help.
>>
>>
>>
>> Larry Hu
>>
>>
>> ------------------------------------------------------------------------
>> *From:* sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] *On
>> Behalf Of *Rick Sample
>> *Sent:* Tuesday, July 12, 2005 9:11 AM
>> *To:* sap-wug at mit.edu
>> *Subject:* Re: rswwdhex - job gets cancelled due to locking issue
>>
>> Had the same issue. Here is what I found and what we did to correct.
>>
>> If multiple instances of SWWDHEX are running we get locks. I verified
>> and
>> can reproduce this and fixed. Here is what I did.
>> Kill all SWWDHEX and have BASIS reschedule just one.
>> Schedule SWWDHEX to run every X time.
>>
>> Still don't know why it stopped but I assume I ran the config as
>> myself. SWU3
>> and caused mult instances to be running.
>> BASIS probably runs SWU3 for the simple fact that it SWU3 should only
>> be run
>> by a user that has SAP_ALL / SAP_NEW.
>> Reason: WF-BATCH inherits the rights of the user running SWU3. No
>> more. No less.
>> (You can search for responses from Jocelyn Dart and in "Practical WF
>> for SAP".)
>>
>> WF-BATCH should not be used for batch processing like
>> SWWDHEX, SWWERRE, SWWERRE, etc.
>> Use some other batch user for batch processing.
>>
>> SWWA set to run periodically. Like every 5 mins.
>> SWWB runs per instance of a deadline.
>> (I could have these backwards. Look them up to be sure)
>>
>> SWWA or SWWB? Depends on what you want.
>> If you have few deadlines, run per instance and it will add a batch for
>> each instance. See SM37 and you will see these being added per deadline.
>> Or, if you have lots of deadlines. set to just periodically, it
>> should rescheduled ONE
>> instance to run every X time.
>>
>> Let me know if this helps. I am interested in what works for you.
>> (And if I made any incorrect statement I am sure someone will let me
>> know)
>>
>>
>>
>>
>>
>>
>>
>>
>> Rick Sample
>> SAP Workflow Analyst/Developer
>> Graybar, Inc.
>> 11885 Lackland Rd.
>> 63146-4208
>> 314.573.5822
>> Rick.Sample at GBE.com <mailto:Rick.Sample at GBE.com>
>>
>> >>> keohan at ll.mit.edu 7/12/2005 7:34 >>>
>> Hi all,
>>
>> We are running on R/3 4.6c.
>>
>> We had RSWWDHEX running without incident until last September, when it
>> stopped, I don't know why.
>> When the matter was brought to my attention, we re-scheduled it via
>> SWWB (or is it SWWA, I can't be
>> sure because Basis does it). The interval between runs is 20 minutes,
>> which should be sufficient,
>> since there are probably less than 5 workitems 'waiting' for a
>> deadline at any given time.
>>
>> Anyway, the job gets finishes, but fails to reschedule itself daily
>> (no specific time, it could fail
>> to reschedule at 5:30, it could fail to reschedule at 7:30...). The
>> system log from SM21 says
>> 'Job SWWDHEX is currently locked' and the detail entry follows:
>>
>> > Within background processing, it was found that the specified job is
>> > being edited, for example, another user edits the job or the run-time
>> > system of background processing is accessing the job. Please attempt
>> to
>> > execute the action required by you with the job at a later date.
>> >
>> > If, in spite of repeated attempts, this should not be successful, that
>> > could be related to problems in the locking system (enqueue server):
>> For
>> > example, "locking corpses" could be available. Please check that with
>> > the transaction SM12. You can also test the function efficiency of
>> your
>> > locking system there by means of the displayed diagnosis.
>> >
>>
>> I am sure we can reschedule with a longer interval between runs, but
>> not sure if this will actually
>> solve the problem. Has anyone out there dealt with this ? OSS, and SDN
>> search of this archive
>> yield no joy.
>>
>> Happy WF-ing!
>> Sue
>> --
>> Susan R. Keohan
>> SAP Workflow Developer
>> MIT Lincoln Laboratory
>> 244 Wood Street
>> LI-200
>> Lexington, MA. 02420
>> 781-981-3561
>> _keohan at ll.mit.edu <mailto:keohan at ll.mit.edu>_
>> _______________________________________________
>> SAP-WUG mailing list
>> _SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>_
>> _http://mailman.mit.edu/mailman/listinfo/sap-wug_
>>
>> 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.
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>SAP-WUG mailing list
>>SAP-WUG at mit.edu
>>http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>

Mike Pokraka
Senior Consultant
Workflow Connections Ltd.
Mobile: +44 (0)7786 910 855