cancel
Showing results for 
Search instead for 
Did you mean: 

Issue regarding BI_WRITE_PROT_TO_APPLLOG

Former Member
0 Kudos

Hi,

I'm facing some issue regarding BI_WRITE_PRO_TO_APPLLOG job and DBA: UPDATESTATS job: BI_WRITE_PRO_TO_APPLLOG is scheduled every 5 minutes, DBA: UPDATESTATS once a week.

The first BI_WRITE_PRO_TO_APPLLOG job after completion of DBA: UPDATESTATS never terminates... it runs and runs, days and even weeks until I cancel the job manually. Every other BI_WRITE_PRO_TO_APPLLOG runs fine and terminates in few seconds. Also DBA: UPDATESTATS works fine without any problems.

Does anybody have a solution for this issue or can somebody explain this behaviour? Any help is highly appreciated

Best regards,

Björn

Accepted Solutions (0)

Answers (2)

Answers (2)

edwin_harpino
Active Contributor
0 Kudos

hi Björn

checked oss note 769414 ?

hope this helps.

Solution

This is only a consulting note that explains why the RSBATCH_WRITE_PROT_TO_APPLLOG/job BI_WRITE_PROT_TO_APPLLOG report runs in your system every 5 minutes since Support Package 23 (3.0B) and the equivalent Support Package 16 of 3.1 and Support Package 04 (Stack 04) of 3.5.

This report must neither be descheduled nor deleted, as long as BW is working live, because otherwise any error messages that appear are not written to the application log.

If you prefer another user under whom the report should run, you can of course first deallocate the report in sm37 and reschedule it again under the desired user.

You MUST use the sm37 job name BI_WRITE_PROT_TO_APPLLOG for this.

The 5-minute execution interval is only a default value, and can be extended up to one hour. However, obviously the error messages may then only appear in the application log after one hour.

If you shut down the system (import to the Support Package and so on), you can then of course deallocate this sm37 job.

There should also only be one active periodically running sm37 job that executes this report, therefore you can delete any multiple scheduling in sm37.

The job usually schedules itself as soon as either the monitor assistant is executed - then with the user who executes the monitor assistant

or if the AdminWorkbench is called - then with the user who calls the AdminWorkbench.

If a scheduled job is already found in sm37, no further one is scheduled.

The job must of course run in the BW client.

The job user needs authorizations to write application log entries.

Note:

In the sm37 log of the current BI_WRITE_PROT_TO_APPLLOG job, you will still find all the messages that the job has written into the application log.

If there were no new messages for writing into the application log, only message RSBATCH 020 (which indicates that no logs were found for writing into the application log in RSBATCHDATA) appears in the sm37 job log.

"No logs found for writing to appl. log in RSBATCHDATA."

This is not an error it is simply a note to indicate that the job was executed correctly and that a new message was not to be written at this time because no new messages have accumulated.

Former Member
0 Kudos

Hi A.H.P.,

yes, I read this note and also those threads in SDN. I'm also clear about purpose and frequency of this job, question is why do I have one job per week that runs without any ending?

Best regards,

Björn

Former Member
0 Kudos

Sorry for bringing this topic back to top, but it's quite important for me... Any idea?