SAP FAQs on Transports
1. I have error messages about logs not found during the transport.
This is usually caused by incorrect maintenance of the setting for the transport directory. Check in particular the parameters DIR_TRANS and TRANSDIR by referring to the advice given in note 556734, section “What do I need to consider when setting up the transport?”.
2. The system reports a DB connect problem! What can I do?
For the test and as a basis for a further analysis, the command “R3trans -d ” or “R3trans -x ” can be used as user
DB2: 152929, 83255, 136806
DB4: 515447, 67213, 69429
DB6: 80292, 53141, 167361
Informix: 85404, 112184
Microsoft SQL Server: 351586, 128126, 116735
Oracle: 193616, 400241, 403004, 134447, 443867, 445029, 437362, 505630
SAP DB: 39439
These notes do not apply to everything! They mostly only apply to certain R/3 or database releases. Only use the relevant notes that apply in each case!
3. When I create transport requests, they are always local!
Check in the TMS at the domain controller whether the transport routes are there. Usually the development system is the source system (the objects are created/changed there). From there, there are consolidation routes into one or several systems that can also be virtual. The consolidation route with transport layer SAP is intended for repairs to SAP objects. With customer transport layers for customer objects, the object must have a development class which is assigned to this transport layer. The corresponding development class can be displayed via transaction SE80.
4. The tp does not write requests to buffers of the subsequent system.
Check whether the transport routes are generally set up and fully activated and distributed. If it only concerns certain transports, check whether these are Workbench or Customizing requests or special transports (transport of copies/relocation). In particular with system copies and restores with incomplete recovery, you must be aware that afterwards the status of the buffer and the database may no longer agree. (For example, you import request C11K901234 into the consolidation system Q11 and then it is displayed in the Q11 buffer that the request is already imported in Q11. The request is not imported into the P11 system. Now you make a system copy from P11 to Q11. Now the request C11K901234 is not contained in Q11 (in SAP), however according to buffer Q11 it is imported).
5. An import seems to hang.
Check in the directory DIR_TRANS subdirectory tmp whether the import process regularly updates a log file for a certain import phase. The last entries in this log file provide information about what the import process is currently doing.
If the import hangs, you may find more error messages in the directory DIR_TRANS subdirectory log in the file SLOG
If no helpful information has been found in the SLOG, you should check in DIR_TRANS subdirectory tmp whether there is a file there with extension .LO and this should be compared with note 12746. You can also check the tables TRBAT and TRJOB via SE16 or SM30 to see if there are old entries there.
6. Not all clients contain client-specific entries!
For objects that enter the system via ADO or SDO import, you must check whether the corresponding jobs RDDIMPDP_CLIENTnnn were released here with the corresponding authorizations. With transports that are to be imported into several clients of a system, you must check whether you worked here with the correct unconditional modes in each case (the first import must be imported with U0 and the following one in each case with U1). Also, a further point which must be considered is the table delivery class belonging to the table. This controls which entries are imported with the various transports into which clients. You will find further information on this in note 2857.
7. An import supposedly has an error, but I cannot find an error in the log files.
This is usually due to the order-independent logs. In the order-independent steps, DDIC objects of other requests may also be edited. For example, the request to adjust a table remains for so long in the internal transport tables and is therefore also processed during a subsequent transport until the adjustment was successfully completed. An error can then be displayed for the subsequent request although its objects were all imported without any errors. Explanatory notes for this are 413993, 512493, 407116 and 330378. After every import, the order-independent logs should therefore also be checked.
If the system refers to canceled RDD* jobs, check the job log via SM37 and via ST22 the short dumps and via SM21 the syslog of the system.
8. A certain program has syntax errors after a transport into a non-development system.
Check whether the syntax errors also occur in the development system. If this is not the case, compare the versions of the program and of the function modules used by the program with the versions in the development system. Different versions can arise if corrections were not yet transported further in the development system or if the sequence of the import does not correspond to the sequence of the export. To solve the problem, import the last changes from the development system into the subsequent system as well.
Solution
1. The status in the TMS is “Import runs” although it is already finished or canceled.
In transaction STMS -> OVERVIEW -> IMPORTS you reach, by double-clicking, the import queue of the corresponding system. From there, via Goto -> Import Monitor, you reach the display of the status of both individual imports and Import all or Import subset. If the tp has already been started, you also see the tp process ID here and you can check at operating system level whether the process still exists (for example ps -ef | grep tp or via the Windows Task Manager). If the tp process still exists, execute the checks for hanging transports from note 556941. Additional notes are 486991 and 505771.
2. Why can I not see all requests in the import history?
See notes 316841 and 375230. In addition, requests whose name is longer than 10 characters can be viewed via transaction SPAM or SAINT.
3. The “large” truck is missing in the TMS symbols
The system is probably set to single import strategy. This can be set up from R/3 Release 4.6C via the transaction STMS -> TRANSPORT ROUTES -> Double-click on the corresponding system -> Tab title System Attributes, area ‘Transport strategy’ or according to note 194000 for smaller releases.
4. Both the truck and the menu option for the import are completely missing.
Here you must check whether in transaction STMS -> import overview -> double-click on the corresponding system there is an import client field with the requests or whether CTC=1 is set in the transport profile. If there is then also only one request in the import buffer, where there is explicitly no import client, the import does not work. Then add the corresponding import client in the TMS.
Symptom
This note describes all steps required to set up a common transport directory between UNIX, AS/400, and WINDOWS NT.
Additional key words
Windows NT, transport directory, mixed systems, Samba, AS/400
Cause and prerequisites
..
Solution
Overview
Setting up a central transport directory NT/UNIX
1. Problem during transport between UNIX and Windows NT
2. Additional necessary software for UNIX
3. Actions for configuration with TMS
a) Maintain the transport profile
b) Change instance profile of R/3 systems under Windows NT
c) Adjustments of R/3 profiles to UNIX format
4. Actions for configuration without TMS
a) Tools required under Windows NT
b) Setting the binary mode for R/3 tools
c) Maintain the transport profile TPPARAM
d) Change instance profile of R/3 systems under Windows NT
e) Adjustments of R/3 profiles to UNIX format
5. Example for SAMBA configuration file
6. Example for a mixed transport file
Explanation of terms:
1. TMS:
Transport Management System (Transaction STMS)
2. Transport Profile:
The name of your transport profile depends on whether you have configured the TMS. The transport profile in is located in the directory usrsaptransbin in the standard system.
When using TMS: TP_DOMAIN_
When not using TMS: TPPARAM
Setting up a central transport directory NT/UNIX
1. Problem during transport between UNIX and WINDOWS NT
When you use the transport system, various files are created in the transport directory which are written by the kernel, tp.exe and R3trans.exe, among other things.
The files in the log, buffer and cofiles subdirectories are opened in the default mode (= text mode), while the files in the transport subdirectory are written as binary data.
When you write the files in text mode, there are the following differences between the two operating systems:
UNIX writes a linefeed at the end of every line.
WINDOWS NT writes a carriage return/linefeed at the end of every line.
When you write files in binary mode, a LINEFEED is written at the end of every line under both UNIX and WINDOWS NT.
Consequently, files which are written in text mode under WINDOWS NT are not legible under UNIX, and vice versa.
To set up a common transport directory for UNIX and Windows NT, you select the binary mode as default mode for writing to the files. This can be set via environment variables as well as via profile parameters.
For transports between systems based entirely on Windows NT that are executed in standard text mode, these parameters are not required.
2. Additionally required software for UNIX systems
Currently, NT does not have a hierarchical file system like UNIX. There
is also no way to create soft links. Thus, file systems on NT machines cannot be attached to local UNIX trees or vice versa. In order to still allow a bidirectional access to the file systems, additional software must be installed.
This software must meet the following requirements:
• There must be a distinction between upper and lowercase in filenames, as filenames are case-sensitive in UNIX.
• The authentication in the other system must be possible via the LanManager API.
• The software must be able to display the contents of directories, regardless of how you access or link to these directories. Only use software that can export soft links.
Because LanManager has a large portion of the PC network market, software has been developed for UNIX systems to allow access to LanManager networks. In the meantime there is server software for almost all UNIX variants, which allows the UNIX system to appear as LanManager as far as the PC is concerned. Many hardware manufacturers offer this type of LanManager software. However, SAP cannot recommend one particular one that you should use. However, if you decide on a product, ensure that the three above-mentioned requirements are fulfilled by this software.
SAP uses the LanManager server called SAMBA (by Andrew Tridgell), which can be acquired free of charge via the Internet. However, SAP does not support SAMBA.
Internet address:
http://samba.anu.edu.au/samba
The LanManager server SAMBA provides file services. You can access the NT files in exactly the same way as though you were in a UNIX shell.
• SAMBA ensures the distinction between upper and lowercase in filenames.
• The SAMBA server can be configured so that it relies on the authentication from a Windows NT Server at logon (NT Server Authentication).
The assignment of the UNIX user to the corresponding NT user is stored in a table on the SAMBA server. The user check is then performed by NT. You can find information in the section “Example SAMBA configuration file for NT authentication”
3. Actions of configuration with TMS
a) Maintain the transport profile
o Log on to the transport domain controller and call Transaction STMS.
o Then choose ‘Overview -> System’ and choose a system by double-clicking. Then choose ‘Configuration -> Display/Change -> Transport tool -> Edit -> Insert row’.
o Record the following entries:
Global Parameters Value OpSys
x ABAPNTFMODE b wnt
x transdir
Example:
Global Parameters Value OpSys
x ABAPNTFMODE b wnt
x transdir \trans01trans4 wnt
A99/r3transpath
A99/sapevtpath
A99/system_pf
The parameter ABAPNTFMODE determines the mode for opening the files which is used by tp and all the tools which are called from tp.
o Afterwards, save the configuration via ‘Configuration -> Save’ and go back to the system overview.
o Then choose ‘Extras -> Distribute TMS configuration’.
b) Changes instance profile of R/3 systems under Windows NT
For any R/3 system under Windows NT that is going to use the central transport directory the following entries have to be made in the system-specific instance profile of the respective system:
o Mode to open the files, that is used by R/3 kernel.
abap/NTfmode=b
o Set DIR_TRANS on UNIX transport directory
DIR_TRANS=\trans01trans4 (without backslash)
o Set DIR_EPS on subdirectory of transport directory for Transaction SPAM
DIR_EPS=\trans01trans4EPS——–
o DIR_EPS_ROOT for transport directory set for Transaction SPAM
DIR_EPS_ROOT=\trans01trans4EPS
Stop the respective R/3 system under Windows NT and then restart it.
c) Adjustments of R/3 profiles to UNIX format
The profiles of all systems running under Windows NT have to be converted to binary format.
For this, log in on any system in R/3 and execute transaction RZ10.
Choose there ‘Utilities -> Import profiles -> of active servers’.
Thus the profiles are saved in binary format.
4. Actions for configuration without TMS
a) Tools required under Windows NT
For access on a common transport directory the editor SAPPAD is required:
This editor is located in the executable directory of your system and can interprete UNIX as well as WINDOWS NT file format.
b) Setting binary mode for R/3 tools
As of Release 4.5A:
Enter the following parameters into your transport profile:
ABAPNTFMODE=b
For Releases < 4.5A:
Set the environment variable abap/NTfmode=b in the user environment for the users under whom the transport program tp.exe or R3trans.exe is started.
The environment variable must be entered in any case for the user under whom the kernel was started (
(In the Control Panel -> System -> User Environment variable).
The program NTENV2REG.EXE is stored in your R/3 kernel directory
Call the program, to declare the user environment to the kernel. This action has to be performed on all machines on which transports are performed.
c) Maintain the transport parameter TPPARAM
Enter the following transport parameter into your transport profile:
o Path of transport parameter
wnt|transdir=
wnt|transdir = \trans01trans4
wnt|A99/r3transpath=\
wnt|A99/sapevtpath=\
wnt|A99/system_pf=\nt1sapmntA99sysprofiledefault.pfl
The transport profile has to be saved with SAPPAD in UNIX-Format. For this you choose Options->Save As Unix File.
d) Changes instance profile of R/3 systems under Windows NT
For any system that is going to use the central transport directory the following system-specific instance profiles of the respective system have to be included:
o Mode for opening the files that is used by R/3 kernel.
abap/NTfmode=b
o Set DIR_TRANS on UNIX transport directory
DIR_TRANS=\trans01trans4
DIR_EPS_ROOT for transport directory set for Transaction SPAM
DIR_EPS_ROOT=\trans01trans4EPS
o You must not set parameter DIR_EPS in the profile itself – it is
automatically generated depending on the parameter DIR_EPS_ROOT.
Stop the respective R/3 system as well as the Service SAP
e) Adjustments of R/3 profiles to UNIX format
The profiles of all systems running under Windows NT that are going to use the central transport directory have to be converted to binary format.
For this you log on to each system in R/3 and execute Transaction RZ10.
There, select ‘Utilities -> Import profiles -> of active servers’.
This saves the profiles in the UNIX format.
5. Example SAMBA configuration file for NT authentication
———-> NT Server Authentication
; Configuration example file for samba using computer pswdf004 as
; password server
[global]
; SECURITY OPTION guest account: the guest has the file access
; rights of this UNIX-user
guest account = nobody
debug level = 0
security = server
password server = pswdf004
getwd cache = yes
wide links = no
password level = 8
case sig names = yes
preserve case = yes
case sensitive = yes
read prediction = yes
[transdir]
comment = us0011:/usr/sap/trans
path = /usr/sap/trans
; SECURITY OPTION public: all users can access the share as a guest
; no password is checked
public = yes
; SECURITY OPTION writable: files + directories can
; be changed if writable = yes
writable = yes
; SECURITY OPTION browsable: Share is visible if browsable = yes
browsable = yes
create mask = 0664
map hidden = no
map system = no
preserve case = yes
wide links = yes
; SECURITY OPTION allow hosts: only specified hosts can access the
; share
allow hosts = us0011
1. Example of a mixed transport profile
ABAPNTFMODE = b
transdir = /usr/sap/trans/
wnt|transdir = \trans01trans4
syslog = SLOG$(syear)$(yweek).$(system)
alllog = ALOG$(syear)$(yweek).$(system)
r3transstat = $(transdir)log/STATLOG.$(system).#.$(yweek)
BIN/dbhost = hs0055
BIN/dbname = BIN
BIN/r3transpath = /bas/$(system)/exe/dbg/$(cpu)/R3trans
wnt|BIN/r3transpath = \NTPCsapmntbinsysexerunR3trans.exe
sapevtpath = /bas/$(system)/exe/dbg/$(cpu)/sapevt
wnt|BIN/sapevtpath = \NTPCsapmntbinsysexerunsapevt.exe
BIN/system_pf = /bas/$(system)/profile/DEFAULT.PFL
wnt|BIN/system_pf = \NTPCsapmntbinsysprofileBIN_D53_NTPC
BIN/impdp_by_event = yes
Source code corrections
———————
ABAPer, mail: abap.community@gmail.com http://www.erpdb.info
If you like this post, you may as well like these too:
- Transports in SAP A Transport in SAP is nothing but the transfer of R/3 System components from one system to another. The components to be transported are specified in the object list of...
Leave a Reply