rswwdhex - job gets cancelled due to locking issue
Dart, Jocelyn
jocelyn.dart at sap.com
Sun Jul 17 22:54:10 EDT 2005
Sue,
Check out whether Basis is using SM36 to schedule the job instead of
SWWA/B. If they've been using SM36 that could be why you are ending up
with duplicates. Make sure you check for "scheduled but not released"
jobs as well.
But if you've been having problems for a little while then probably what
is going on is there are too many entries outstanding to process in the
window given - regardless of the window size (remember max window is
only 99 minutes). Check table SWWWIDH to see how many entries you have
waiting to be processed.
Suggested approach:
Stop all jobs, run the job once manually, e.g. from SA38, under a basis
id. Watch the job queue - if it starts any additional SWWDHEX jobs
automatically - which it probably will - kill the jobs (NOT your manual
run). (You might also want to check the locks via txn SM12 - there's a
report execution lock held for this report. - Just don't kill the lock
for the manual run.) Wait for the manual run to finish. Then restart
the jobs via SWWA/B.
If you are still having problems another approach is to schedule
RSWWDHEX to run dependent on the previous RSWWDHEX job finishing.
That's something you need to use SM36 to do.
Regards,
Jocelyn Dart
Senior Consultant
SAP Australia Pty Ltd.
Level 1/168 Walker St.
North Sydney
NSW, 2060
Australia
T +61 412 390 267
M + 61 412 390 267
E jocelyn.dart at sap.com
http://www.sap.com
The information contained in or attached to this electronic transmission
is confidential and may be legally privileged. It is intended only for
the person or entity to which it is addressed. If you are not the
intended recipient, you are hereby notified that any distribution,
copying, review, retransmission, dissemination or other use of this
electronic transmission or the information contained in it is strictly
prohibited. If you have received this electronic transmission in error,
please immediately contact the sender to arrange for the return of the
original documents.
Electronic transmission cannot be guaranteed to be secure and
accordingly, the sender does not accept liability for any such data
corruption, interception, unauthorized amendment, viruses, delays or the
consequences thereof.
Any views expressed in this electronic transmission are those of the
individual sender, except where the message states otherwise and the
sender is authorized to state them to be the views of SAP AG or any of
its subsidiaries. SAP AG, its subsidiaries, and their directors,
officers and employees make no representation nor accept any liability
for the accuracy or completeness of the views or information contained
herein. Please be aware that the furnishing of any pricing information/
business proposal herein is indicative only, is subject to change and
shall not be construed as an offer or as constituting a binding
agreement on the part of SAP AG or any of its subsidiaries to enter into
any relationship, unless otherwise expressly stated.
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Susan R. Keohan
Sent: Wednesday, 13 July 2005 10:33 PM
To: SAP Workflow Users' Group
Subject: Re: rswwdhex - job gets cancelled due to locking issue
Hi WF-ers,
Basis has been scheduling this job once. The job runs once every 30
minutes (we tried increasing
the interval to see if that helped, no joy) for the day... then, round
about 7:30 PM - or a little
later - it fails. So I have asked my Basis team to dig in a little
deeper to see what else is going
on at the time.
Another funny thing... although the SM21 log shows two entries for the
job failing due to locking
errors, the SM37 log shows only one job kicked off at the offending
time. So I am wondering the
SM21 log is not writing duplicate entries.
Anyhow, I am hoping Basis can solve this before I have to escalate to
OSS.
Thanks for all the help! You folks are great!
Sue
Rick Sample wrote:
> I noticed if I (as WF Admin with not SAP_ALL / SAP_NEW) run SWWB
> then I get two instances running. Once from me starting it and one
> from our BASIS folks running. Does not stop other instances from
running.
>
> If you look at the program there is references to this issues about
> multiple instances running. How and who is scheduling RSWWDHEX?
>
> I would have BASIS kill all scheduled instances and have BASIS
> create the batch run and call it a day.
>
> I would like to know what you do to get this issue resolved.
>
> Rick
>
>
>
> 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>
>
> >>> wug.replies at workflowconnections.com 7/13/2005 6:57 >>>
> 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
<mailto: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>_
> _[mailto:sap-wug-bounces at mit.edu]
> <mailto:[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 <mailto: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>_ <_
> mailto:Rick.Sample at GBE.com_ >
> >>
> >> >>> _keohan at ll.mit.edu <mailto: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
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> 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
More information about the SAP-WUG
mailing list