Key word: r3sltratp
When you use tp to perform a transport, the following warning message appears repeatedly in the $transdir/log file:
WARN is already in use (#n), I'm waiting 5 sec ()
is a file name that starts with $transdir/tmp, #n is a number that is increased by one in each message, and is a time stamp with format YYMMDDHHMMSS.
The file mentioned in the message is a tp semaphore file. It is used to prevent two different tps from accessing the same file at the same time. A tp that needs to write to a file in the $transdir directory will first attempt to reserve the uniquely defined semaphore file for itself (these are in directory $transdir/tmp). If this does not work, tp attempts to write the above message to the $transdir/log/SLOG* file (which is again protected by the same mechanism), and tries again 5 seconds later. If this fails again, the same message is written with a higher number and a new timestamp. Normally, this activity will not be repeated very often, because the other tp that reserved the semaphore file does not take long to end its write activity. It is not possible, however, to specify a "normal" number of repeats, since one specific semaphore file remains during the entire R3trans import that is started by tp.
If the above message only appears sporadically and with small numbers of repeats, this means that the described mechanism is functioning properly and that two (or more) tps are working in the same system.
The action required depends on the name of the file.
Usually, the semaphore file from the SLOG message is not called P..
To decide whether the warning message in this situation requires administrator action or not, you must check whether the tp that reserved the semaphore file is still active. The contents of the semaphore file are helpful in this case. Semaphore files can always be read, but should NEVER be changed. The first line of the semaphore file contains the host name of the computer where the tp that reserved that semaphore file is running. First use operating system means to check whether the corresponding tp is still active - for example, whether the process still exists. If the process no longer exists, you can safely delete the semaphore file. It will then be created again immediately by the second tp file (which kept trying to reserve the semaphore file for itself). Therefore, exercise caution when deleting semaphore files, and only do so when the above condition is satisfied. Never delete the same file twice in a row.
Note that the tp that reserved the semaphore file does not necessarily have to run on the same computer where you started it. Theoretically, any computer that can access the transport directory may be involved.
During an upgrade, the semaphore file from the SLOG message may have the name P.. In this case, you must perform another action.
During the upgrade, tp is started in some phases so that a file with
this name is being created. In this case file P. is a log file and its own semaphore if it stands in subdirectory put/tmp.
If there is only one tp process that writes the SLOG messages, stop this process and copy the generated file in tmp to the existing file in log on UNIX, for example, using cat /usr/sap/put/tmp/P. >> /usr/sap/put/log/P.Afterwards, you can delete the file in tmp and repeat the phase.