rswwdhex - job gets cancelled due to locking issue

[Mike Pokraka]

Hi Sue,
Sounds like your multiple schedules are the problem. SM37 should only have
one job released/scheduled.
BTW, it's designed to be run more like every 5 or even 3 minutes so the
schedule period is definitively not an issue.
Cheers
Mike

Susan R. Keohan wrote:
> Thanks Eddie, Rick,
>
> We only have one instance of RSWWDHEX running at a time, or at least that
> is the intent. Although
> from the system logs, it appears multiple occurences are trying to get
> kicked off at the same time,
> therefore locking each other out... (extract of SM21 log)
>
> 19:15:21 sapprod1_RP1_23      BTC 33 400      EGC > Job SWWDHEX is
> currently locked
> 19:15:27 sapprod1_RP1_23      BTC 33 400      EGC > Job SWWDHEX is
> currently locked
>
> Again, this job was scheduled to run once (by a userID that is not
> WF-BATCH) every 20 minutes.
>
> Eddie, I passed on your suggestions  to the Basis team.  They had nothing
> to report as to the
> outcome (I don't know what we should have been looking for, and I didn't
> see the results myself).
>
> So we have rescheduled RSWWDHEX to run at a longer interval, 30 minutes
> this time.  I'll check to
> see if we get a failure tonight.  Frankly, at this point, with so few
> actual deadlines to look out
> for, I am wondering if I shouldn't just run the job once daily.  But we'll
> see what the results are
> later on.
>
> Happy WF-ing,
> Sue
>
> Rick Sample wrote:
>
>> 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_
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> --
> 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
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>