During a transport or support package application, the transport appears to 'hang'. In the SLOG you see a message similar to this:
ERROR: System <SID>. Warning. 20011030140113 :
ERROR: The following call returned with exit code 4:
ERROR: sapevt.exe SAP_TRIGGER_RDDIMPDP -t name=<SID>
ERROR: Background jobs cannot be started.
ERROR: Please check trace file dev_evt.
ERROR: (This warning is harmless if no further warnings follow.
This is not the exact text of the error as certain things can change based on the system settings. You may also see this error in the
dev_evt file:
Trace File of External Event Raiser (Trace Level 1)
event id: SAP_TRIGGER_RDDIMPDP
> function: BtcCreateEvtMsg
< function: BtcCreateEvtMsg
> function: BtcEvtRaise
SAP message server host:
SAP message server service: sapms<SID>
rc from MsAttach: -100
< function: BtcEvtRaise
event raise failed
In this case the SAP message server host will either be blank or will not be the correct server.
Windows 2000:
This problem can be caused by switching the QoS-Setting in Windows 2000 without changing the variable. Please look at note 180940 for more information on this issue.
All Platforms:
There are multiple application servers in your landscape, and a transport of some kind is started. If for some reason the tp program
is called from an application server instead of the message server, this problem can arise.
The transport system calls sapevt with only the event name, system name and -t options. Three other parameters are needed for sapevt to function correctly (rdisp/msserv, rdisp/mshost and SAPSYSTEM) and sapevt trys to read these from the DEFAULT.PFL. It looks for this profile on the default LOCAL path. The error is caused when 1) there is no local DEFAULT.PFL or 2) the needed parameters are not set or are set incorrectly in the local DEFAULT.PFL.
All Releases:
First determine if you have a central profile directory or maintain local directories on each machine. If you maintain separate profiles,
you will need to make one available in a shared directory, for example, in /usr/sap/trans. Every application server must be able to access it. This profile does not need to be named DEFAULT.PFL, however this is the name used in this note. Make sure that the DEFAULT.PFL defines rdisp/mshost, rdisp/msserv and SAPSYSTEM correctly. Examples:
rdisp/mshost = <hostname>
rdisp/msserv = sapms<SID>
SAPSYSTEM = 00 (this is the system number)
If you wish to maintain multiple profiles in one directory, it is necessary to give them unique names, such as DEFAULT.<SID>.
Next check the services file for the sapms<SID> entry. This entry should have the format:
sapms<SID> 3600/tcp
If your entry looks like this:
sapms<SID>###3600/tcp
The '#' marks indicate the beginning of a comment, and all text after
this will be ignored. Remove them or duplicate the entry without the
comment marks.
The services file can be found in Windows NT/2000 in:
%WIND_DIR%system32driversetc
and in UNIX it can be found in:
/etc/
After you have verified that the sapms<SID> service exists, maintain the transport profile parameter <SID>/system_pf. Your transport profile will either be TP_DOMAIN_<SID>.PFL or, for older releases, TPPARAM, and is located in DIR_TRANS/bin. The system_pf parameter should be the path to the DEFAULT.PFL for that SID. Example:
A11/system_pf=d:usrsapA11SYSprofileDEFAULT.PFL
B12/system_pf=/usr/sap/trans/bin/DEFAULT.B12
Both are valid paths, assuming that the profiles are maintained.