SAP Note 309711 - SAP Servicetools Update: Online help (Part I)

Symptom


News and problem solving for SAP Servicetools Update


Other terms
RTCCTOOL,  SAP GoingLive & EarlyWatch Service preparation


Reason and Prerequisites
Servicetools and R/3 upgrade / transport error messages / automated FTP


Solution

Topics:

1. Procedure before&after R/3 system upgrade
anonymize old servicetools objects as preparation before upgrade -
After upgrade servicetools get lost - DB02: "BDL* STSL* BAM* tables not in DDIC" -> Run procedures from RTCCTOOL

2. Procedure after implementation of addon ST-A/PI
uncomment analysis coding for smaller software components

3. Transport error handling
analysis - transport logs - warnings (rc=4) - errors (rc=8) - fatal errors (rc=12/14/16) - reimporting transports (U1) & unconditional modes - RTCCTABG - ascii<->bin mode - new transporttools - enqueue object errors

4. About automated FTP
longrunning FTP check

5. Modification info in (very) old servicetools transports
run report /SSF/RTCCSMOD before Upgrade

6. About RTCCTOOL recommendations
Shortened procedure for customers with internet VPN/SNC connection - List of recommended notes

1. PROCEDURES BEFORE&AFTER R/3 SYSTEM UPGRADE

These two procedures prevent or solve minor issues with servicetool objects duing system upgrade. They are short and can be implemented anytime without problems.
In previous servicetools transports the objects were not always fully anonymized. In upgrade to target release >= 6.20 basis, such non-anonymized objects would be regardered as modified. To prevent this proactively, choose 'Addon&Upgr' from inside RTCCTOOL and press 'Procedure before upgrade'. This will anonymize the original system to 'SAP' for old servicetools objects. When this procedure is recommended by RTCCTOOL, it should be executed as soon as possible, i.e. you do not need to wait until the next system upgrade date.
After an R/3 upgrade, the SAP servicetools are lost, but certain database objects BDL* STSL* or BAM* may remain. This may cause messages 'Table .. exists without DDIC reference' during CHK_POSTUP phase or in transaction DB02.
For clearing these DB<->DDIC inconsistencies, please
(a) implement the addon ST-A/PI for the new release from note 69455.
(b) then execute report RTCCTOOL. Choose 'Addon&Upgr' from inside RTCCTOOL and press 'Procedure after upgrade'. This will clean unreferenced BDL* STSL* BAM* database objects.

2. PROCEDURE AFTER IMPLEMENTATION OF ADDON ST-A/PI

Addon ST-A/PI contains analysis coding in comments (*) for smaller software components like IBU Banking, SEM-BW, PI (CIF Plug-In) and others. If one of these components is fond on your system, RTCCTOOL will recommend to have the corresponding analysis coding uncommented. Choose 'Addon&Upgr' from inside RTCCTOOL and press 'Procedure after addon implementation' to do this.

3. TRANSPORT ERROR HANDLING

In RTCCTOOL click on the lights icon to display the results of the status checks. Click on the transport log icon to view the logs. You can also access the logs using transaction SE09, 'Request/task->Display individually', 'Goto->Transport logs'.
In the last column you see the returncode for each transport step. Doubleclick on the single steps in order to see the error details. Expand the logs, either by doubleclick on the log lines (rel 3.x) or using the expand icons to the left (rel 4.x).
The error handling depends on the highest transport log returncode.

a) returncode rc=4  meaning 'warning'
Warnings will not affect the functionality of the transport.
For example 'table E071: entry in DB is 10 bytes bigger than in file' appears if the R/3 release of source and target system are different, but this is only for information. Warnings can safely be ignored.

b) returncode rc=8 meaning 'error'
Doublecheck the implementation text of the transport in RTCCTOOL and the related SAP note whether you can maybe ignore the error. Verify that the recommended transport order has been kept.
In case of activation problems you can try to regenerate the transport using report RDDMASG0 (with function=TRGEN) or from 4.0B the report RADMASG0. Enter the transport request number and execute. If this was successful, then only reimport the transport once more with unconditional mode U1 (see 'Reimporting transports' below).
If the problem appears to be general, it may help if you fetch the latest versions of the transport tools tp and R3trans as described below.

c) returncode rc=12/14/16 meaning 'fatal error'  or
  tp finished with return code: 210   meaning: emergency brake
A frequent reason is that the datafile is corrupted, either because it was transferred in ascii mode, or if the transfer was not successful (note 2050). The transportlogs indicate 'unexpected EOF' 'Internal error in DB interface' etc.
Please check whether the datafile (R*..) has the same size as on sapserv3, and if it can be read with R3trans -l <datafile>. If not, try to fetch the datafile once more from sapserv3-7 in binary mode (FTP command 'bin'). If there are FTP transfer problems because of long distance with unstable connection, try to use another FTP program.
Errors can also be due to bugs in the transport tools, especially in older versions. See the description below how to implement the latest versions of tp and R3trans.
Other possible reasons

      -  check the implementation text&the note whether you have to
         specify a target client
         (tp import <tr.request> <SID> client=000)
      -  Unix: verify that the transportfile owner is the <SID>adm user
      -  AS/400 Import stops on error 12 during MOVE NAMETABS, MCH5003:
         please follow note 317633.
      -  the transport demon RDDIMPDP (note 34964) is not scheduled in
         the target client. For checking this, use the report SAPBTCJO
         (batch job overview) with 'RDDIMPDP' as input parameter. You
         can schedule RDDIMPDP by running report RDDNEWPP as user DDIC
         in the target client, esp. client 000.
      -  verify that the R/3 profile parameter DIR_TRANS is the same as
         the parameter transdir in the /usr/sap/trans/bin/TPPARAM file
      -  for other possible reasons, please see points 1cd) in
         note 128835.

d) tp finished with return code: 152   meaning 'nothing done'
In this case you have to specify an unconditional mode U1 (see 'reimporting transports' below). It could also be that there was no tp addtobuffer before the tp import command.

e) returncode rc >= 1000
Only the last two digits of the returncode indicate real errors (mod 100). The higher digits represent additional info/warnings. For example a returncode=6000 during export indicates that the export was o.k. (00), but the target system was not known, which is often the case for a 'transport of copies' to a dummy system.

Re-importing transports & Unconditional modes
  1  During import: Ignore that the change request was already imported
  2  During import: Overwrite the originals.
  6  During import: Overwrite objects in unconfirmed repairs.
  8  During import: Ignore restrictions based on table classification.
The most important unconditional mode is 1. It must be specified whenever a transport has been imported before, even before an R/3 upgrade. Example: tp import <tr.request> <SID> U1
If you use transaction STMS to import, then you must use the option 'Ignore that the transport has already been imported' or 'Import transport again' (under 'Expert mode' or 'Options' in the dialog window after 'Request->Import'). In Release 4.6x the transports must be newly added to the transport queue 'Extras->Other requests->Add'.

New transport tools
The newest version of the transport tools tp.exe and R3trans.exe can be found on sapserv3-7 under general/R3server/patches. Please consult note 19466 in order to determine the proper subdirectory depending on your R/3 release, OS and DB. Fetch the files tp_<patchlvl>.CAR and R3trans_<patchlvl>.CAR in binary mode and unpack them with the command 'car -xvf <name>.CAR'. Save backup copies of your old tp.exe and R3trans.exe files which you find in your /usr/sap/<SAPSID>/sys/exe/run directory, and then replace them by the new files.

Enqueue object errors
For each enqueue object two function modules are created automatically. If a table for an enqueue object is not successfully imported (pressing the 'Generate' button in display mode gives errors), also the enqueue function modules shows syntax errors. Then the whole function group containing ~20 enqueue objects cannot be generated anymore, and this may affect other transactions (e.g. in QM, happens very rarely).
In this case proceed as follows: in SE37 execute function module DEL_ENQUEUE_FUNCTION in test mode. Enter the name of the TCC enqueue object causing the errors (e.g. EBAMUIDTL) and execute. After this you should be able to generate the enqueue function group in display mode and the errors on your other transactions should be solved. Then try to solve the import error for the table. When the table is activated successfully, please reimport the transport with unconditional mode U1.
Enqueue objects from TCC are: EBAMUIDTL (on table ->BAMUIDTL), E_BAMMAPNG (->BAMMAPFCGR), E_BAMUIBT (->BAMUIB and BAMUIBT), EBDLCUSDEF (->BDLCUST), EBDLSRVDEF (->BDLSERVICE), ESQLR (->SQLRCUST).
Enqueue function group names are like /1BCDWBEN/SAPLBENQ

(Continued in Part - II)