Skip to Content
author's profile photo
Former Member

During BOP processing , row lock on table TTSTR is held for very long time

Dear Friends,

Given the fact that we have a large number of sales order line items to process, we have numerous BOP batch jobs that are running at the sametime.

Our issue is that when one of our BOP batch jobs are running, it appears to lock table TTSTR (lock object name = ETSTRID) for a long period of time. The BOP job has to complete before the lock is released. And it appears that it is the same Time Stream Id (SAPxxxxxxx) that is causing this lock. The other BOP jobs will then wait for the TTSTR table to be released. If these other BOP jobs cannot access table TTSTR within 10 minutes, they start to abend with a 913.

Any reason why this particular Time Stream would cause the TTSTR row to be locked for a long time?

I am not sure how to check for INVALIDATE situation with this particular Time Stream.

I looked at OSS Note 311258 but since we are onSAP_Basis 7.0, that note was for lower versions.

If anyone has any suggestions, it would be greatly appreciated.

Thank you.

Michael Tylisz

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

4 Answers

  • author's profile photo
    Former Member
    Posted on Nov 04, 2011 at 02:07 PM

    HI Michael.

    Have you checked report ZZTSTRREGENERATE from note 986925 ? Run the report once and check if the issue stilll occurs.

    Maybe there is a issue with the RFC call to ECC to read the unloading points for the ship-to parties during the BOP.

    best regards,

    Michael

    Add comment
    10|10000 characters needed characters exceeded

  • author's profile photo
    Former Member
    Posted on Nov 07, 2011 at 09:25 PM

    Hi Michael,

    Thank you very much for your response. Sorry that I am getting back to you so late.

    Yes, back in 2009, my co-worker implemented that note and a few others related to report ZZTSTRREGENERATE. I thought my co-worker indicated that this report was not working as intended. I will review this report myself.

    SAP just gave us another report to create called 'ZZ_TIMESTREAMS_CALC_REMOTE' and suggested that we use these 2 reports in conjunction with each other and run them just before we start out nightly BOP processing.

    So I will be testing these 2 reports.

    Using debugger, I did find out why we had a row lock on table TTSTR for so long, up to an 1 hour this lock would last causing other jobs or transactions that needed that row in the TTSTR table to time out.

    The report /SAPAPO/BOP regenerates numerous timestream id's and after updating table TTSTR for each regenerated timestream id, a DB_COMMIT was performed. And that works well. But it appears that when the last timestream id is regenerated, a system field called SY-BINPT which normally is spaces, now has a value of 'X'. And since SY-BINPT = 'X', the DB_COMMIT statement is bypassed. So a row lock on this one timestream is kept until the BOP job completes, which is about 1 hour later. So this lock is kept for 1 hour or longer.

    Why did the value of SY-BINPT change from spaces to an 'X' during the execution of report /SAPAPO/BOP, I don't know.

    I really appreciate your help, Michael.

    I am going to leave this thread open until I have tested those 2 reports just in case they do not work.

    Thank you.

    Michael Tylisz

    Add comment
    10|10000 characters needed characters exceeded

  • author's profile photo
    Former Member
    Posted on Nov 16, 2011 at 04:37 PM

    Dear Friends,

    I am marking this message as Answered as we have detern=mined an error in the SAP code. Currentky SAP is working on a fix and will create an OSS Note for distribution when they have the solution completely tested.

    Thank you.

    Michael Tylisz

    Add comment
    10|10000 characters needed characters exceeded

  • author's profile photo
    Former Member
    Posted on Nov 16, 2011 at 04:39 PM

    Ah, so this is the right way to poast a last comment for a thread. Ok, as stated above, we have found an issue with the SAP code. They are analysing and will create an OSS Note when a final solution has been tested and verified. Thank you. Michael Tylisz

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi All

      We had performance issues for ATP check from R/3 to APO and while we asked SAP for help SAP responded saying the data volume for table TTSTR is high and we need to delete unnecessary data by running report -/SAPAPO/SCHED_DELETE_TSTRS and ZZSTRDELE. After running these two reports in test environment we found the data volume has reduced to 96 records from 105000 records. We asked SAP to know whether this is safe to run this and got response that we need to be carefull while running these as data is permanently deleted by this

      Can anybody tell whether its completely safe to run these two reports or we may delete genuine Time Streams by running these?

      Regards

      Mridul