This problem occurs not only now, but some time ago. Now, we only record the processing method.
STMsTransmission, No matter how long it takesStatusIt's always running, noEnd. Check the content to be transmitted and find that the content contained in the change request has been transmitted to the target client. The process is as follows:
1. The change request content has been transmitted to the target client, eliminating the possibility of an RFC error. Of course, I checked the RFC again and did not find any problems.
2. table related to the STMs transmission task, which is known to me as tmstlock, trbat, and trjob. check the tmstlock and find that there are the same number of locks with the change request in the running status. view trjob. There are also the same number of jobs running in trjob.
3. unlock a locked task. the unlock method is to delete the records in tmstlock. the delete method is to use the ddic account Delete under the 000 client, or change the status field value to 'dele' for delete in the form of debugging under other clients. of course, the precondition for delete is to ensure that all Delete tasks have been transferred to the target client. After deleting the records in tmstlock, you can enter the transaction STMs to view the transmission status. At this time, the transmission status is complete.
4. view the trjob table. At this time, the trjob has no records.
5. Check the trbat table and find that there are still two records in trbat. According to the time indicated by the timestamp, the two records are found for a long time in the past. All transfers after this time cannot end. Clear the two records (of course, the delete method is used ).
6. generate a new change request and perform the transmission test. At this time, the transmission can end normally.
Handle this problem.