Ansicht
Dokumentation
00446 - Transports going to 'sleep'
TXBHW - Original Tax Base Amount in Local Currency Addresses (Business Address Services)This documentation is copyright by SAP AG.
Transports going to 'sleep'
Thanks Volker for this information on the transports, I will file this away
for reference. In this instance I found the problem outside of the
transport. We have been setting up a separate client in PRD. Using ALE,
some master data was being moved from client to client. I'm not clear on
how it occurred (yet), but the short of it, this process had flooded the
que with 6400+ jobs. These jobs were worthless and were not actually
updating anything, just tieing the que in a knot. They were running in
subsecond times, and was not seen by SM50. It wasn't until I did SM37 with
* for both jobname and user that I found the problem.
Concerning
Database |-------------------------------|
Name: | (*) Public Contact Manager |
| ( ) Executive Contact Manager |
|-------------------------------|
Organization
Name:
Project:
Contact
Name(s):
"Gueldenpfennig,
Volker" To: "Sap400 (E-mail)"
<sap400Zm...>,
<volker.gueldenpfenni "'JCumminsZy...'"
<JCumminsZy...>
gZs...> cc:
Subject: RE:
Transports going to 'sleep'
01/23/2001 02:01 AM
Hi all,
the sleep of TP is for a small time absolutely OK. This happens for 2
possible reasons:
a)
there is a lock-file still set so that TP seems already to be active. This
can be seen in the SLOG as the "new TP" writes what file is causing the
delay.
b) (currently more likely on 4.6x)
there is currently a step going on to import data in the SAP system. This
is
done as follows:
- write the request to table TRBAT
- trigger the event SAP_TRIGGER_RDDIMPDP in order to activate the SAP job
RDDIMPDP that should always be in released status
- sleep (for 5 seconds?) till a return code is set in table TRBAT
- reschedule the event about every minute. Write every 5-10 minutes into
the
SLOG that something might be wrong with the SAP system.
The sleep can last indefinetely when there doesn't occur any returncode.
When you see that the tp takes this long it might be useful to have a look
in SM37 for the last run of RDDIMPDP. This should be the case since the
start of the TP. Otherwise you can try and trigger the event
SAP_TRIGGER_RDDIMPDP via SM64 without any parameters. When the TP now runs
through, the SAPEVT didn't come through.
Otherwise you could reschedule the RDDIMPDP with the user DDIC in client
000
with the ABAP RDDNEWPP and retrigger the event afterwards as well.
The joblog of the job RDDIMPDP should tell more details.
It is for me very interesting that such a TP runs through after 12 hours
instead of being stuck for ever.
Regards
Volker Gueldenpfennig
This e-mail is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. Any
review, dissemination, copying, printing or other use of this e-mail by
persons or entities other than the addressee is prohibited. If you have
received this e-mail in error, please contact the sender immediately and
delete the material from any computer.
Durban Tours - Südafrika Safari
General Data in Customer Master CPI1466 during Backup
This documentation is copyright by SAP AG.
Length: 4153 Date: 20240426 Time: 182140 sap01-206 ( 3 ms )
