print this page
Latest Post

SAP Transports - Script to add bulk tp to buffer

As a part of SAP Basis life, we need to import many transports at a time, which is very crucial for the project at the same time its very boring job indeed.

Some of us take help of excel and notepad and create file to import those transports at OS level like separate line for each transport
tp import SA8K901203 <SID>  client=100 u0126  pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL
tp import SA8K901205 <SID>  client=100 u0126  pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL
tp import SA8K901207 <SID>  client=100 u0126  pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL

This solves the purpose, but there is no fun in it. Plus lets say if you want that in case of return code 8 or other error the import should stop then above method will not going to help at all. Solution is to create a script for it in Unix. I have done thousands of transport with help of this script on Solaris and Linux, and I don't see any reason why it should not run on other flavors like AIX, HP-UX.

Lets proceed to create script file.
Create a directory where you like, I created inside trans directory with name TrnScript. Provide read write access to <sid>adm for this directory.
Inside this directory you need to create three files.
1. /usr/sap/trans/TrnScript/transport_list.txt file, this file will contain transports list, each transport in new line, which will look like below:
$ more transport_list.txt

This is a simple text file and there is no limitation on number of transports you can have a list of thousand transports and they will be processed one by one in linear sequence, the transport in top will be processed first and it will move to second line and so on in downward direction. This file will needs read access rights for <sid>adm.

Now we need a executable file to add transports in buffer, it does not matter if the transports are already there in buffer or not, below script is not going to do any harm in system, run it anyway before starting the import script file.

2. /usr/sap/trans/TrnScript/
$ more
# Start of Script file
#! This script will add transports to buffer one by one sequentially.
# The list of transport should be given in transport_list.txt file where
# each transport should be in new line.
for i in `cat ${TPLIST}`
/usr/sap/DT9/SYS/exe/uc/linuxx86_64/tp addtobuffer $i DT9 u1 pf=/usr/sap/trans/bin/TP_DOMAIN_DT9.PFL
    print "`date`...Transport ${i} Status RC=${RC}" >> ${TPSTATUS}
# End of script file

This file should have executable rights for <sid>adm. Check this file carefully for the path mentioned for
(b) tp
(c) DOMAIN file

When above script file will execute, it will create a log file named transport_list.txt.log at same location where transport_list.txt file is present, provided <sid>adm has write access to the directory. The log file will contain information like below

$ more transport_list.txt.log
Mon Apr 30 06:49:56 CDT 2012...Transport EC6K900076 Status RC=0
Mon Apr 30 06:49:56 CDT 2012...Transport EH4K930113 Status RC=0
Mon Apr 30 06:49:56 CDT 2012...Transport SA8K901225 Status RC=0

This log file will give you chance to check if data file and cofiles are present and readable. Also, if any of the transport is imported in system without option "Leave transport Request in Queue for Later Import" then it will add it again so the request can become transportable again. If you find any other return code than zero then correct the issue rename the log file and rerun this script file again and check log file.

If everything goes fine till here then we can go for transport import script file
3. /usr/sap/trans/TrnScript/
$ more
# Start of Script file
#! This script will import transports one by one sequentially.
# The list of transport should be given in transport_list.txt file where
# each transport should be in new line.
for i in `cat ${TPLIST}`
/usr/sap/DT9/SYS/exe/uc/linuxx86_64/tp  import $i DT9  client=100 u0126 pf=/usr/sap/trans/bin/TP_DOMAIN_DT9.PFL
    print "`date`...Transport ${i} Status RC=${RC}" >> ${TPSTATUS}
    if [ "$RC" -ne 0 ] && [ "$RC" -ne 4 ]; then
# End of script file

This script file will import transports with u0126 mode which means
0 - Leave Transport Request in Queue for Later Import
1 - Import Transport Request again
2 - Overwrite Originals
6 - Overwrite Objects in Unconfirmed Repairs
Import Option.jpg
If you want to select different option then you can adjust accordingly the number appended after "u" in script.
This file will create log file transport_list.txt.RClog which will contain the timestamp and RC of each transport.
The import of transport will stop when it will get return code other than 0 or 4
Now you can read SAP tp log and resolve the issue then you need to remove those transports which are already imported through script from file transport_list.txt and execute the script again.

If you want that in case of error too, the script should move ahead with next transport then you simply need to put # in start of these 3 lines or remove them from the script file
    if [ "$RC" -ne 0 ] && [ "$RC" -ne 4 ]; then

You can also use at now or cron to schedule the script as per your need.

Hope this will be of help to some of us.

Posted by Ishteyaque Ahmad in SAP on UNIX

script for multiple tp addtobuffer and tp import Mass adding of transports SAP Add to Buffer & Import Multiple Transports using TP Scripts how import mass transport requeast at os level

SAP NW 7.5 New Features from Basis Perspective

Basis Changes
In NW 7.5 you will no more see the folder name DVEBMGS<nn>  it's replaced by just D<nn> like our Dailog app server.

NW 7.5 
SAP NetWeaver 7.5 enables technology trends like the Internet of Things (IoT), mobile, cloud, big data and analytics and offers a foundation for the easy and fast development of simple business applications. It supports Java 8 to enable Java-based hubs like SAP Enterprise Portal, SAP Process Orchestration, and SAP Business Process Management to benefit from new Java features. The innovations in ABAP and Java, together with improvements to SAP NetWeaver hubs, SAP Fiori, and lifecycle management offer significant benefits.

SAP ECC 6.0 Technical Upgrade [Basis] - Scenarios

1. ECC6 Technical Upgrade Scenarios Upgrade scenarios SPIK Zoran Popović from ECC5 to ECC6 Senior System Engineer BC Team Concerning Development Freeze, System Landscapes and Hardware 01.08.2008. Infrastructure Basic Scenario – SCENARIO 1 Official (ASAP) Upgrade Roadmap document available on Marketplace (, Upgrade Master, SDN and other official SAP sources offer several upgrade scenarios – from which the most simple one, let us call it SCENARIO 1 (“by the book”), to the more sophisticated ones (like CBU, switch scenarios, etc. which are not discussed here). I will not discuss here all the technical details of an upgrade process, only those which affect the decissions about project timeline, development freeze duration and possible hardware purchase/borrowing What is here discussed is the possibility of variants of SCENARIO 1 by using parallel Transport Management lines (or so called Support Pipelines, or just Lines) with some degree of additional hardware usage or consolidation in order to make development freeze as small as possible and support the upgrade project. In almost any standard upgrade procedure scenario we must have a test SANDBOX (CRP ?) system (as described in references). By a standard upgrade SCENARIO 1, a sandbox system as a heterogeneous copy of the production system is needed for: • Initial technical upgrade (from ECC5 to ECC6): prepare, start of upgrade, SPAU/SPDD, modifications, support packs, etc. • Functional tests needed to improve procedures, correct problems, create and plan all necessary activites – this can be iterated until achiving satisfying results • Generating upgrade script (a detailed set of upgrade activites, participants and dependencies e.g. as given in ) In business environments without so strict validation practices it is possible to use this system as a future upgraded D (development) system (as proposed, if I have understood well as I wasn’t present on his presentation/workshop), or it could be used as a place for formal functional tests (as proposed in references, upgrade/business case) and a future Q (Test and QA) system - thow they also propose creating a new (P) production system. Company needs three-tired (D-Q-P) lines in the landscape for validation purposes. In all cases, without taking into account which servers are physically used for ECC6, three- tiered systems (D-Q-P) and any upgrade scenario need this series of events (as given in reference and ADM326) - the UPGRADE LINE: 2. Fig. 1 – upgrade steps in the basic scenario – UPGRADE LINE Parallel Hardware Infrastructure – SCENARIO 1A In a variant of such a scenario (one of many which involve system copies or original systems and landscapes), whether we could use a parallel h/w infrastructure for ECC6 – let us call it SCENARIO 1A: D5 Q5 P5 ECC5 production maintenance line Development D’6 Q’6 P’6 ECC6 – temporary “sandbox“ Freeze upgrade line D6 Q6 P6 ECC6 - the main UPGRADE line Fig. 3a – „parallel“ h/w landscape D5-Q5-P5 is the existing ECC5 line of systems / physical servers which is both the maintenance and the upgrade line later on, and D’6-Q’6-P’6 is the ECC6 sandbox line made by heterogeneous system copy of each system established as a separate line in TMS on new set of servers. On the other hand, as in SCENARIO 1, there is only D5-Q5- P5 line. Upgrade scenarios with development freeze Support Pipeline 3. At one point, the following series of events (*) is inevitable in any of the previous scenarioss (SCENARIO 1 and SCENARIO 1A) – the place of the beginning of development freeze is same: 1. Development freeze 2. D: Upgrade D5 to D6, corrections, formal unit testing, possible repeating step 2. 3. Q: Transports generated by upgrade in step 2 from D5 upgrade. Including corrections (somewhat faster than complete upgrade of Q5 system instead of using transports of changes), formal integration tests, possible repeating step (2. and) 3. If successful, we have Q6 as result. 4. P: optional testing upgrade on renewed sandbox and possible repeating steps 2. or 3. 5. Transports from D5/Q5 upgrade, Final upgrade of P5 to P6 and GoLive The thing here is that integration tests should take at least few weeks (with all the performance impact on new Q6 system), without the days needed for the pure technical upgrade itself. In all scenarios here mentioned the D’6-Q’6-P’6 line plays actaully the role of the sandbox system expanded to whole landscape, which might give some downtime decrease in the development freeze phaze - but whith extra hardware and effort which is not justified (at least I seriously doubt so, if h/w not borrowed I am certain). This downtime is not important if it is not influencing Development Freeze, as explained in the next scenario – SCENARIO 1B – and this is the only important difference between these two scenarios. Hardware can be even more consolidated as in the scenario to be proposed here bellow: Parallel Hardware Infrastructure – SCENARIO 1B An alternative solution (with variants) is given in where an additional support line made of heterogeneous system copies of D and Q (or renewed copies from the SCENARIO 1A) is used: Fig. 4 – Temporary Support (pipe)line scenarios In that manner, production system stays intact until the previously described step 5 – let us call this SCENARIO 1B. Formal validation (unit and integration) tests can be done without development freeze (**). In this case we have hardware performance-ready with optionally minimal additional hardware needed for D and Q copies instead of whole parallel h/w infrastructure as in SCENARIO 1A. Therefore, I propose for SCENARIO 1B. Upgrade scenarios with development freeze Support Pipeline 4. SCENARIO 1B could be OPTIONALLY more comfortably realized with following addtional hardware (but this is not a mandatory requirement) which could be leased/borrowed (or bought) during the initial upgrade phaze as project support resources: • 1 HP rx2620 (or rx4640) for D copy, minimal configuration with 8GB RAM – one server, AND/OR second: • 1 HP rx4640 for Q copy, minimal configuration with 8GB RAM (this is OPTIONAL, as explained w/Fig. 5) In this case it is even possible to make several levels of h/w consolidations with existing hardware infrastructure (and our future SAP systems if bought, depending on business needs, e.g. additional D/Q Solution Manager system, BI requirements, additional archiving solution with SAP Content Server, etc) – our existing SAP hardware was recently upgraded with additional RAM, so ERQ (and BWQ is needed just for a physical node) in the support line servers (ECC5) might even be temporarily left on only one cluster node with functionally intact performing system copy. The performance pressure can only be expected on new ERQ (Q5/Q6) servers. Sandbox system can be established on one of our integrity servers (also upgraded with RAM, SAP5 or SAP6). MSCS switchover tests are necessary only on new (ECC6) ERQ servers. If possible, borrowing servers or some RAM from our hardware vendor (HP, Belgrade) or his partners could significantly simplify this scenario. This would save a lot of time, effort and minimize the risk about these activities. Nevertheless, it is possible to make sufficient hardware consoloditions by replacing existing RAM modules from our existing servers which are less loaded in order to improve performance on critical servers (e.g. Q5 systems for testing, D5 for upgrade to D6), with insignificant risk of performance issues on old development and sandbox systems. Upgrade scenarios with development freeze Support Pipeline 5. Possible h/w Consolidations with SCENARIO 1B The SCENARIO 1B could be compared with SCENARIO 1A with a diagram on Fig. 3b similiar to Fig. 3a: D5 Q5 P5 ECC6 main UPGRADE D6 Q6 P5 line D’5 Q’5 sandbox ECC5 – Temporary Development Support (Pipe)line P6 Freeze (**) Fig. 3b – Upgrade and Temporary Support (Production Maintenance) lines But here D5 and Q5 are copied into D’5 and Q’5 (and so is P5 into SANDBOX system), which together with P5 form the new Temporary Support (Production Maintenance) line: D’5-Q’5-P5 - which is used for urgent changes in the system (so called „fast-tracks“, minimized in number as much as possible). These additional changes need to be taken care of in the post-GoLive phaze or during upgrade. Physically same servers D5 and Q5 are then upgraded to D6 and Q6 by the upgrade script generated on SANDBOX system. Development freeze is smaller than in SCENARIO 1A. The bottom line here is that it is possible to buy NO NEW HARDWARE for project support (no servers at least) with only potential performance issues with new ERD (and sandbox) consolidated on one of our existing servers which could be handled successfully. In the Fig. 5 bellow is a diagram of SAP System Landscape in our company with systems, transport lines and physical server names. The idea is to „borrow“ two servers from ERQ and BWQ servers, using existing clusters and leaving temporary support line out of the cluster (which should not be an issue). Q’5 SAP- SAP-ERP1 SAP-ERP3 D5 / D6 ERQ1 P5 / P6 ERP ERQ ERP (CI) ERP ERD (CI+DB) (MSCS) (DI) SAP3 MSCS SAP- ERQ2 SAP-ERP2 SAP-ERP4 possible consolidati Q5 / Q6 consolidation on for SAP- for SAP-ERP5 ERQ1 ERC + D’5 SANDBOX BWP BWD BWQ (CI+DB) SAP5 SAP3 (MSCS) MSCS SAP- ERQ2 SAP-ERP6 SAP Router ERA sap- SOL + SOL + (ECC5 gateway-n1 CEN (migrated, Web IDES) upgraded- Dispatchers SAP2 to be … ) SAP1 MSCS SAP6 sap- Upgrade scenarios with development freeze gateway-n2 Pipeline Support 6. Upgrade steps in SCENARIO 1B in a skecth would then be steps (*) described earlier, which now need no Development Freeze in step 1, but only during final step – upgrade of production: 1-3. Same as steps (*) 2-4. 4. Development Freeze (**) 5. Transports from D5/Q5 upgrade, Final upgrade of P5 to P6 and GoLive 6. Copying fast-tracks back upgraded D and Q systems. Hardware Requirements and Sizing Estimations Concerning ECC6 Upgrade In all these scenarios I find that pure technical upgrade of ECC systems can be estimated as follows (by Note 901070, SAP benchmark information, and Oracle documents given all in references) – by upgrading from ECC5 to ECC6 (and from Oracle 9.2 to 10.2) we have only a slight increase in need for the h/w resources: System Component CPU RAM DISK SAP INSTANCE 0-5% 5-10% insignificant ORACLE 0-5% / insignificant 0-5% / insignificant 5% Table 1 – technical upgrade resources requirements without project sizing Some indications and experiences were made in references that it is possible to have 25% DB growth, but this any is not an issue for ERP system as it has already more than 50% free space in the database files. The only important issue about all these scenarios is the currently available Storage space for Temporary Support hardware (in any scenario, but especially for SCENARIO 1A) and during project implementation. With some additional effort and incoming resources for backup disks this might be solved, too, but this needs to be carefully estimated. But in any case, Storage space has to be well planned for the future. Hardware Sizing and Other Project Requirements - Quicksizing On the other hand, system sizing and Storage space is also significantly influenced by Sizing produced by the Rollout & Optimizitaion activities and appropriate parts of the project. This has to be discussed separately, BC needs input from each team about estimated number of users and their types, significant changes of system usage (numbers of document generated, etc) and other infor needed for the quicksizing utility which should be part of the regular project BBP activities. These are planned to be until 01.09.2008, but we need this info ASAP in order to inform out h/w vendor (HP) on time and to place orders as needed. Timelines are still not cleared. I expect that it would be mostly about additional RAM, CPUs and Storage, and optionally about borrowing servers. HP also offered us help from his SAP experts at least on this topic, which could be very useful for the whole project. Upgrade scenarios with development freeze Support Pipeline 7. BI hardware landscape and system sizing is unknown in terms of project scope (tbd in BBP as proposed by Robert Gamauf). For Solution Manager, company has requirements for only one upgraded system (as seen from workshops). Using Web GUI for BI and Java instances for BI should also be considered in system sizing. Borrowing servers as temporary resources and support during the project is also a good option which influences mainly the project timeline, but are not important after GoLive if no User Requirements emerge during BBP (e.g. BI systems and Solution Manager usage).

Solution Manager SAP - Where do I assign product instances to the product system?

When you maintain a product system, assign technical system + product instances to the product system - do NOT change the instances marked as installed on the technical system! Technical system information should always be sent by data supplier - do not change it manually.

SAP RFC Parameters - Performance Tuning

abap/arfcrstatecol_delete_: value X
Activates deletion of ARFCRSTATE records in background. Forces report RSTRFCEU to run in batch periodically every 5 minutes (see SAP Note 539917)

gw/maxconn_: value 2000
Sets maximum number of active connections (Gateway)

gw/maxoverflow_size_: value 10000000
Sets size of local memory area for Gateway

icm/HTTP/maxrequest_size_KB_: value 2097152
Maximum size of HTTP request accepted by ICM

rdisp/appcca_blk_no_: value 2000
Sets TCP/IP communication buffer size

rdisp/forcesched_after_commit_: value no
Disables automatic rollout of context after commit work

rdisp/maxarq_: value 2000
Maximum number of internal asynchronous messages

rdisp/maxcomm._entries_: value 2000
Sets maximum number of communication entries

rdisp/rfcmax_own_login_: value 90
Sets RFC quota for own logins

rdisp/rfcmax_own_used_wp_: value 90
Sets RFC quota for own used work processes

rdisp/rfcmax_wait_time_: value 5
Sets RFC maximum wait time after load check

rdisp/tmmax_no_: value 2000
Sets maximum number of available connections (instance)

rdisp/wpca_blk_no_: value 2000
Sets block buffer size for work process communication

ztta/maxmemreq_MB_: value 2048
Limit for a single memory allocation request (default 64). This value depends on the maximum document size.

SAP OS DB Migration Project Milestones

Project Milestones 

  • Preparation completed 
  • New hardware ordered and installed 
  • Sandbox (SBX) migration 
  • Functional/Operational Testing 
  • DEV migration Functional/Operational Testing 
  • QAS migration Functional/Operational Testing 
  • PRD migration – Go-Live

Why SAP OS DB Migration Export Import takes long?

Export and import can take a very long time – tune and re-run those steps until timing is satisfactory.

Database statistics are important to both the import and export processes. Statistics from previous migrations can be exported and imported to save time.

Migration tools provide a means of optimizing the export and import process
Package splitting
Table splitting
Migration Monitor
Distribution Monitor.

SAP OS DB Migration - Post Migration Steps

Post processing
  • Check for missing objects 
  • Tune System Modify SAP profile parameters 
  • Modify Database parameters 
  • Adapt application specific parameter from source system 
  • System level checks (sick) 
  • Follow post processing steps per migration guide 
  • Check Batch jobs with target systems 
  • Printers Integration points 
  • Apply new license 

SAP OS-DB Migration - Target System Steps - Import

  • Import of target system Use SAP Migration Utility (similar to an installation) 
  • Install the database software 
  • Install the SAP instance 
  • Import data from source system 
  • Review import performance – re-run if necessary

SAP OS DB Migration - Source System Steps - Export

  1. Export of source system Start with a procedure document to record process. 
  2. Run pre-checks and setup steps per migration guide 
  3. Any upgrade post processing must be complete (ex. ICNV) 
  4. SAP data dictionary and database data dictionary must be consistent 
  5. Database statistics must be up to date Remove failed updates 
  6. Delete TEMPSE inconsistencies 
  7. Suspend batch jobs (BTCTRNS1) 
  8. Run selective business reports (finance, inventory, etc) 
  9. If SID changes, all transports must be released! 
  10. Run migration utility to export source database 
  11. Review export performance – re-run if necessary

Related Post

SAP Maintenance certificate Download Location

Quick Link:

  • Search with SID name of your system
  • Click on License keys Tab
  • Download the maintenance cert with a valid date and a valid hardware key
  • Download to your PC
  • Login to ABAP Go to Tcode SLICENSE and Install 


SAP OS DB Migration Project Plan

Blueprint Phase
  • Migration project related issues
  • Technical data of the source system environment
  • Technical data of the target system environment
  • The migration project schedule
  • Hardware sizing feasibility
  • Load distribution (if necessary, optimization recommendations are given)
  • Configuration of the new system
  • SAP system parameters
  • Database parameters
  • User/load distribution
  • Performance before migration
  • Transaction profiles
  • Number and distribution of users
Post Go-Live

  • Comparison of response time before and after migration
  • Performance analysis on the new OS/DB combination
  • Verification of whether all the required SAP recommendations were implemented
  • SAP system parameters
  • Database parameters
  • User/load distribution
  • Optimization of load distribution and identification of potential bottlenecks
Example Project Plan
Example Project Scope - SAP OS -DB Migration

Related Question
What happens to the data in my SAP system during the OS/DB migration? Is there something I need to tell to the financial auditor?  Click for Answer

SAP REVREC Revenue Accouting Download Location for Installation

Login to SAP Service Marketplace


REVREC Installation & Configuration consulting Contact Us:

SAP SCM Optimizer Install Steps - Easy

Step 1: Download the SCM optimer SAR file from SAP Marketplace

SCM Optimer Download Location --> click here

Step 2:
Download SWPM 10 to install SCM Optimizer

Step 3
Install Optimizer from SWPM

For SAP systems based on SAP NetWeaver 7.0 and SAP NetWeaver 7.0 including enhancement package
Choose your product --> choose Standalone Engines SCM Optimizer Installation 

For SAP systems based on SAP NetWeaver 7.3 and higher: 
Choose Generic Installation Options -->SCM Optimizer Installation

Post Steps
Follow SAP Optimizer Installation guide
Copyright © 2011. SAP BASIS ANSWERS | SAP BASIS ADMIN BLOG - All Rights Reserved
Proudly powered by Blogger