Failures scheduling background monitoring

[Namit Bhargava]

Hi Mark:
 
Something similar happened to me also about a month ago - let me ask you
this - can you do this in Dev environment and not in QA & Prod.?
Try this - first delete all the jobs that might have been scheduled. Then
ask the BASIS team who have the autho. to schedule Background jobs to do
this scheduling for you. This should work.
 
Regards
Namit Bhargava
Principal Consultant
IBM Business Consulting Services
 
 
 
                      "Pyc, Mark"
                      <Mark.Pyc at amersham.        To:       SAP-WUG at MITVMA.MIT.EDU
                      com>                       cc:
                      Sent by: SAP               Subject:  Failures scheduling background monitoring
                      Workflow
                      <Owner-SAP-WUG at MITV
                      MA.MIT.EDU>
 
 
                      01/08/2003 05:05 AM
                      Please respond to
                      "SAP Workflow
                      Users' Group"
 
 
 
 
 
G'day WFers,
 
I hoping someone has some insights into error messages returned when trying
to schedule the deadline monitoring job in 46C.
 
When selecting the "Schedule backgr. job for case-specific deadline
monitoring" option the following message is returned:
Message no. WL 864
Work item 000000000000: Background job RSWWDHEX cannot be scheduled (error
13)
The specified error number should indicate possible reasons for the error.
It is possible that the system is in an inconsistent state. The scheduled
start of the specified background job must be compared with the minimum
date/time of all work items in table SWWDHMIN. It may be necessary to
delete
the scheduled background job by hand and reschedule it by calling report
RSWWDHEX.
 
When selecting the "Optional: Schedule permanent deadline monitoring"
option
the following message is returned:
Message no. WL 818
Table SWWDHMIN cannot be written
 
Debugging, searches of OSS and the archives have provided no real joy. Both
messages complain about SWWDHMIN and ddic tools reveal nothing unusual
about
this table. No authorization failures are reported. I will report this to
OSS as well, but I thought I'd try this avenue as well in case someone else
has hit it...
 
Many thanks,
Mark