following CTS document is going to help each and every
person who is already involved in the correction and
transport procedure of this company or wants to know
about the correction and transport system(CTS) from
SAP. I have tried to cover the SAP versions 2.2, 3.1
and 4.5. I found out that most of our systems in Pandesic
are using 3.1H version and users are not using the
Transport Management System (TMS); so the Transport
Management System is not covered in this document.
I used lot of tips to help the basis users to solve
the transport problems. Users will find some differences
in the features between the 3.1H version and 45B version
of Correction and Transport system .This document
also covers the CTS difference between 2.2 version
and 3.1 version.
I hope each and every person of this company who is
performing the transport can take advantage of this
Correction and Transport System
created in the development system must somehow be
moved, then incorporated into the test system, then
subsequently moved and incorporated into the production
system. The SAP Correction and Transport System (CTS)
serves this purpose and is the vehicle by which SAP
moves objects such as programs, screens, configurations
or security settings from one system to the next.
Additionally, the CTS ensures consistency between
systems by maintaining log entries for any attempted
or completed activities. If used correctly, the CTS
creates an effective and standardized procedure for
managing and recording changes made to the system
while providing an excellent mechanism for integrating
either newly created objects or existing objects that
have been altered to meet the customers needs.
Changes in CTS
a user of the CTS it is important that you become
highly knowledgeable about its capabilities (i.e.
changing objects, incorporating them into other systems
and optimal use of existing error prevention methods).
As a Basis administrator your goal is hopefully to
be able to effectively communicate with other users
of your SAP system. Therefore, "speaking the
language" of CTS becomes an important aspect
of your job. However, with new releases of SAP it
is sometimes the case that terminology may need to
be changed to better reflect the purpose of specialized
utilities or to show the expansion of utility functionality.
Such is the case within the CTS. Upon installing the
newer 3.0 and higher releases of the system, version
2.x user will find that the correction control utility
originally referred to as correction/repair,"
is now called task.
Additionally, where a transport, previously moved
objects in release 2.x, is now the change request
in version 3.0 and higher. Although, for the sake
of simplicity, this book will focus on terminology
specific to software releases 3.0 and higher, learning
the differences in the terminology used from one system
release to the next can benefit you greatly if you
intend to work with various system releases.
Another change that you may wish to note is that from
release 3.0 and up, the ABAP/4 development workbench
includes the workbench organizer for managing software
development objects. More importantly however, is
that SAP recommends that the workbench organizer be
used, as it has the added advantage of being fully
integrated into the ABAP/4 development workbench.
Transaction Terminology: Release 2.x versus 3.0 (&
3.0 (& up) Release 2.0
Workbench Organizer (SE09) Correction and Transport
Customizing Organizer (SE10)
Transport System (SE01)
Change Request Transport request
-Transportable - Consolidation request (K transport)
Transport request Transport request
-Transport Originals -Transport with change authorization(C
-Transport of Copies - Transport without change authorization
- Development/Correction -Correction request
- Repair -Repair request
Change Request Transport
-Client Dependent customizing
-Client Independent customizing
IMG Tools -> Customizing
SE09 and SE10 transactions to use Only SE01
SE06 Setup workbench organizer SE06 Setup workbench
process of integrating objects moved using the CTS
is called migration. Migration involves two aspects
of the CTSs functionality, namely the correction
control system and a transport system. As objects
are migrated from the development environment to the
test environment (ideally) and finally into the production
environment. The correction control system uses tasks
to record changes in the development environment.
The transport system uses change requests to move
objects from development system to other systems.
Using SAPs correction and transport tools, table
data such as configuration and application data, can
be moved from one system to another and from one client
to another client in any given system.
a SAP object has been changed, it is referred to as
a "repair. SAP designed the system in such a
way that all the changes for any SAP object are automatically
recorded. Always the system generates the repair requests
for you and after the repair is done to the object
it is entered automatically to the repair editor by
the repair process. After all the steps to the repair
process is done you can release the repairs from the
source SAP system database. Later in this chapter
we will find more about repairs and how to release
the change requests.
note that in this chapter the release 3.0 and higher
terminology will be used to address the CTS. In the
CTS process, after the objects are created or changed
in the development environment, a task is assigned
to those objects. To automatically generate the tasks
in the system, the recording for the individual client
should be on in T000 table. It has to be done manually
by executing transaction SCC4 and changing the client
attributes there as shown in chapter 9. Many objects
can be assigned to a single task. It is always recommended
to place all the related objects in one task. A change
request consists of one task or number of tasks. After
the task is released from the system, all the objects
from the task get transferred to the change request
editor. The second step is to release the change request
and export all the objects to the data directory and
cofiles directory of the system. The third step is
to use the system level SAP command TP in the target
system to move the object from one system to another
or one client to another. The TP command is executed
in the operating system level to import a change request
to the target system. It is very important to remember
that objects can be directly transported using change
requests. When the change recording is not on for
a client as we have seen in chapter 9 the change request
screen does not pop up for the users automatically;
so some times developers put their objects directly
in the change request editor to transport objects.
of the R/3 CTS system:
CTS system is actually made up of various components
which allow for the movement of objects and help to
maintain comparable and up-to-date changes from one
system to the next. Here is a list of the components
you may encounter while using the CTS to perform various
Change requests and Repairs
- Correction system or Workbench Organizer
- Transport System
- Development class
- Transport layer
- System types in the CTS pipeline.
- Repository objects
- Customizing objects
- Unix file systems in the transport process
- Important SAP delivery class and table types and
tables in the CTS process
- Programs in the CTS process
- Version Management
- TP and R3trans program
of Task, Change Request and Repair:
Corrections and repairs are recorded in tasks and
transported using the change requests. It can control
changes to internal components of the system that
includes data dictionary objects, ABAP/4 programs,
screens, CUA definitions, and documentation. The task
can register and can keep the documentation of all
the changes to the system objects. Once the objects
are locked the system prevents parallel changes to
the system objects. For existing objects, the system
ensures that only a single original copy of each object
exists. The previous version of an object can be restored
and two versions of the objects can be compared. The
CTS system asks for a change request number (if the
recording is on in that client) whenever a customizing
change is done or a new object is created with a development
class other than $TMP (local object development class).
A task is automatically created under a change request.
User has to release the task first to release the
change request. The user can be able to create or
modify the object only after he or she opened a task.
Opening a task registers the change with the system.
Once the user releases a task, the objects in task
get transferred to the change request.
the unit testing in customizing master client is completed,
a task is released to its change request. After a
task is released, it can no longer be modified. If
the user wants to modify the same objects, which were
included in the released task, he has to create a
new task. A task can not be deleted after it is released.
The attributes also can not be changed. All the objects
in the tasks should have a development class other
then $TMP(local objects development class); otherwise
those objects can not be transported.
user needs to take the following steps to release
the release icon
the user is going to see a large editor for the
documentation. Provide a good documentation about
the task and save it.
the task will be released
that the task is released by looking at the log
for the task or if you refresh the SE09 or SE10
screen then the task can be found in released section
of that screen.
Tips: A task can not be released if it
is empty, user does not have the proper authorization,
the objects are not locked properly and the objects
are not locked in another task or change request.
Some objects can be manually added to a task. When
creating a change request and task, the user should
create the right type of request (CUST or SYST). Changes
to customizing objects belong to CUST and Changes
to client independent and ABAP/4 development workbench
belong to SYST category. If a task is already released
then the objects of that task or change request can
be easily added to the new one by selecting include
template from file menu in SE01, SE09 or SE10.
Requests: After a task is released, the objects
are moved to a change request. Using the change requests
the sap objects get transported from one system to
another. There are four categories of change requests:
Transportable, Customizing, Local and Not assigned.
Change requests containing SYST type changes and CUST
type changes belong to transportable category. Only
client dependant changes or CUST type changes belong
to Customizing category. If the change request contains
Local Objects, then it belongs to Local
category. If the change request is created manually
through Workbench Organizer and no repository object
is assigned to it then that belongs to Not assigned
After the task is released, if the task does not have
a change request then a window pops asking for one
has to choose from either existing requests category
or new request category. It is very important for
the user to know that he should not select a change
request that is already released. As we have seen
before, in a development team usually the team leaders
assign the tasks to the developers. After the work
is done, developers release their tasks to the change
request created by the team leader. To release the
change request, select the request and then select
the release button in the toolbar..
is recommended that the users should describe the
purpose and status of the development with every change
request. This gives complete change documentation
for all the developments and the changes made to the
system. After the change requests are released, the
new versions for those objects are created in the
version database of the system. The cycle goes on
for every change request created for every change
made to the objects. The version database helps the
user the compare the old version with the new version
and restoring a particular version in case it is necessary.
tips: A transport can be created manually
through SE01 and different types of objects can be
directly added to the editor to get transported to
the target system. Also a released change request
or task can be included as a template in that transport.
The way SAP system is designed, the users can only
edit an original version of an object. So the user
has to access the system, where the original of an
object is located. In the other systems the users
can only display the objects. Anytime the user wants
to edit an object other than its original system;
he has to create a repair for that object. When the
repair is done to an object, the entire object is
locked. As long as the repairs are not released, the
objects in the repairs can not be overwritten by any
are displayed separately at the top of the correction
and transport menu. User gets a warning if the repaired
object in the target is being transported. If the
original objects of SAP are changed then repairs are
created, also if the original objects of development
system are changed in staging or production systems
then the repairs are created. To create a repair for
SAP objects, those objects must be registered in OSS
system and after the objects are registered the registration
keys from the OSS system must be applied to the repaired
system. The OSS is the online service system that
is connected remotely with the customer system and
it has the following features for the customers:
and information database
Up-to-date release, upgrade and installation information
Registration for SAP software change
the transport logs:
logs are written to common directory in operating
system. The logs can be displayed within any SAP system
in the CTS pipeline. To examine the log files using
SE09 and SE10, select the change request and then
Goto -> Action logs and Goto -> Transport logs.
Action logs records and shows all the actions in the
transport process. For example, export, test import
and import. The transport logs keeps all the information
about the log files generated by the transport process.
A user can also display the logs from transaction
SE01. After going to the display screen of a released
transport, the user can press the log button to display
the logs. The following four levels of information
are available in the transport log.
performed and the return code for those actions.
error messages if any.
for developers and other users.
level can be selected from the summery of a transport
45B version you can use the expand button to expand
the transport log screen as following:
As we know already from the return code helps a user
to know the status of the transport. A return code
can be from 0 to12, 0 being the best and 12 being
the worst. The following are the return codes and
Transport was successful in export phase and import
4 Warning messages are there. The objects in the change
transported, but there are some warnings the system
wants the user to be aware of. For example if you
want to transport some object deletions then the system
will show you a warning.
Individual object could not be transported successfully.
For example while using "tp import" command
you might get a return code 8 if you are trying to
transport user table data to the target system without
transporting the table structure.
The system has generated a fetal error. The error
is not generally caused by the transport, but it can
be a database error.
Operating system terminated the transport .
System or Workbench Organizer:
correction system or workbench organizer uses tasks
to record all the changes in the SAP system (The recording
option for the client must be turned on if you want
to record all the changes). The workbench organizer
records and manages the changes to objects in the
SAP system. There are different types of objects involved
in the process. For example ABAP/4 dictionary objects,
ABAP/4 programs, Screens, CUA definitions, documentation,
Application defined transport commands and Customizing
objects. The workbench organizer prevents parallel
changes to the same object by ensuring that only one
copy of each and every object exists within any particular
system. If one developer changes the object then it
locks the object for other users until it gets released
from the system. The main objective of this is to
manage the system in such a way that correction and
development work can only be carried out on the original
object in the original system. As a user you are only
allowed to modify an object if you open a change request
to record the changes. The workbench organizer gets
activated for every change to the system automatically,
then save all the changes to the objects in the original
system on a version database that stores all the change
versions of a object.
release 3.0 onwards, The Workbench Organizer is completely
integrated in the ABAP/4 development Workbench, which
includes the customizing tools. A group of people
can work on a project by adding tasks and change requests.
Using the SAP security profiles and authorizations
access to the functionality of Workbench Organizer
can be controlled.
for the CTS system
the required authorizations you can control the user
access for creating, modifying, releasing or exporting
the tasks or change requests. SAP provides all the
predefined authorizations for Workbench Organizer
(transaction SE09) and Customizing Organizer (transaction
SE10) and Transport system (transaction SE01). Though
the SAP provides essential CTS authorizations for
a SAP project, still for further requirements you
can define your own authorizations. In a SAP implementation
project, different users play different roles. For
example, a basis administrator should have all the
authorization to configure and manage the CTS system,
a functional team leader should have complete authorizations
to Workbench Organizer (transaction SE09) and Customizing
Organizer (transaction SE10) and functional user or
developer at least should have authorizations to edit
and release a task. The following profiles from SAP
can be used for different areas of responsibility.
Basis System administrator (user gets All authorizations
within the Workbench Organizer and the transport system)
"S_A.SYSTEM" contains the authorization
"S_CTS_ALL" that permits the user to execute
all the transactions within the Workbench Organizer
and the transport system. This authorization also
allows the user to execute the enhanced transport
tools (SE03 transaction or Goto->Tools in the Workbench
Organizer) and the special function "Set System
Change Options" (transaction SE06). We recommend
assigning this profile and authorization to only basis
administrators for security of the SAP system; so
the authorizations for system change options remain
in one group of users. If you are a 2.2 user then
you must know that from release 3.0 you do not have
to logon as DDIC to execute all the transactions Workbench
Organizer and the transport system if you have "S_CTS_ALL".
Any user can execute those special transactions (for
If they have "S_CTS_ALL".
Display authorizations to all the basis components
S_A.SHOW contains the authorization "S_CTS_SHOW"
that permits the user to display transport logs, information
about tasks and change requests.
For Project leaders responsible for customizing
"S_A.CUSTOMIZ " profile contains authorization
"S_CTS_PROJEC" and this authorization allows
a user to create, edit, and lock and release/export
tasks and change requests.
for Developers in a SAP project
"S_A.DEVELOP" profile contains authorization
"S_CTS_DEVELO" and this authorization restricts
the user to development work on tasks. The user can
only release the task to a change request. The user
is not allowed to change the owner of a task or release
a change request.
authorization object used in the Workbench Organizer
and Transport System is called S_TRANSPRT. It consists
of the fields Activity and Object in the Workbench
Organizer/CTS. The following values are used:
01 Insert or generate
30 Set up object list
70 Management, administration
72 Create object lists
75 Release external requests
90 Change owner
Objects in Workbench Organizer/CTS
INIT SE06: Initialize Workbench Organizer and transport
ORDR Change request
PATC Patches, Hot Packages
PIEC Object list
TASK Task (repair or correction)
TRAN Transport of copies
request management and Workbench organizer are very
important tools used in customizing process of an
R/3 system. To customize an R/3 system, first make
any changes to the system environment required by
specific customer needs. Since all changes that are
made to the system are recorded in order to transport
changes to another system, any changes you do make
are kept consistent between systems. Average environment
of SAP consists of three systems. For example: DEV
for development, STG/TST/QAS for staging or testing
and PRD/PR1 for production. The architecture of all
SAP systems involved in the correction and transport
process of a SAP implementation project is called
a CTS pipeline or CTS landscape.
a SAP recommended customizing process the following
steps are followed.
The functional team leader creates a change requests
and tasks under it. Then he/she assigns those tasks
to the team members for customizing.
2. The team members perform the customizing work and
all the changes to the objects are recorded to task/tasks.
3. The team members release the task or tasks manually
to change request or change requests.
4. Finally the functional team leaders release the
change request/requests and export the objects from
the source system database to the operating system.
5. Then the Import process starts into the QAS/STAGE
system and the appropriate testing is performed.
6. If the objects are functioning properly in a staging
or QA environment, the same change request is moved
to production environment. On the other hand if those
objects are not functioning the way they are suppose
to, then those objects will be fixed in DEV environment
and go through the same cycle again.
CTS pipeline and customizing:
following is an example of a change request management
process in a project where there are three clients
in development environment (DEV). Client 100 for customizing
and for development and client 300 for sandbox (this
client is used as a playground). There will be a QAS
environment having only one client 100. After all
transports are tested properly in QAS environment,
they would be transported to the Production (PRD)
client 100 environment.
customizing process in Client 100:
the start of a customizing project, the project leader
creates a change request and assigns the project team
members to it. The customizing organizer then creates
a task for each project team member. When the project
team member performs a customizing transaction in
the IMG, the settings are saved to the task in the
change request. A task contains all the customizing
settings that the projects team member made during
the customizing project.
project team members finish their project work, they
release their tasks. The task objects are then passed
to the change request. When all team members have
released their tasks, the project team leader releases
the change request. The change requests contain all
the customizing efforts for the whole project.
development process in Client 100 or configuration
The development and customizing processes are very
similar. A project leader is required to create one
or more change requests for all project members and
is responsible for the release of that change request
for transport to the downstream system. The workbench
organizer is responsible for all change requests containing
client-independent objects, such as ABAP/4 programs,
screens, menus, data dictionary changes and global
setting. If a Repository object is created, it must
be assigned to an appropriate development class.
a change request, you can specify which team members
work on the project. Every team member specified in
a change request can access all the objects in the
change request. Only project team members are allowed
to maintain the objects in the change request. This
prevents other users from unintentional changing of
Questions to ask yourself before following the Transport
What time will transport take place daily.
- Who is responsible for a change request during the
various phases of transporting? For example who will
be creating the change requests? Who will release
them after the development work is done? Who is going
to keep the change request master list for a functional
- How will all transports be verified before being
distributed and re-distributed? The verification process
defined by the functional and basis group to make
sure that all the objects of the change request goes
through proper test in test system before moving forward
in the CTS path.
- What if a transport is successful, but testing proves
that the contents are incorrect? The change request
should be checked properly before you release it.
Sometime the developer uses same task or change request
for different development objects; if the wrong objects
are transported then you can not perform a good test
in the target.
- Is notification sign-off required for transporting?
If you get a notification signoff from the user who
released the change request, then the objects for
a particular configuration are being transported and
all those objects should not be changed in the source
system until it is tested properly in the target system.
- For example security profile changes will be effective
for Client100 (master configuration client) so that
only project team leaders will have authorization
to create the transport/change request. The project
team leads have responsibility as gate keepers
for the configuration. Following this procedure a
SAP project will have two advantages: the control
of all the change requests will be handled by one
person in that module and every body will not try
to configure their own by not talking to each other
in the team.
Enterprise and Project IMG is created and defined
in client 300
Project team leader or customizing team leader creates
initial IMG view for the projects within the customizing
and development client 300.
Project team leader or customizing team leader creates
a change request for every IMG view. (Therefore, an
IMG view must be the highest unit of customizing activities
that can be independently tested or transported.)
Customizing activities occur.
Customizing occurs in the configuration and development
Once the prototype hierarchy customizing has occurred,
the master client (client 100) is created.
Automatic recording of all changes is established
in the configuration and development master client
When customizing is complete for a view, it is tested
properly in client 300 before applying it manually
to the master client 100.
If customizing changes are not up to the requirements
after unit testing, they are completed in the configuration
and development client 300.
Once unit testing is complete, the customizing is
done manually and documented in master client 100;
tasks are created for every customizing activity in
a view and the project team leader or customizing
team leader releases the transport.
Transports are released from the development master
into the CTS buffer until the Quality Assurance System
Quality Assurance System/ Test or QA system:
Quality Assurance System QAS is created.
Quality Assurance System is installed.
The CTS buffer contents are transported into the quality
assurance test master client.
Any outstanding customizing activities are completed.
The 10-20% customizing that could not be completed
in the first phase of transports needs to be completed.
The customizing views are created in configuration
and development client 300. After the customizing
is complete in 100, before the test continues a client
copy will be done to create a reset client 050 in
DEV with all the customizing and no data. We recommend
having a backup configuration master client (in this
example client 050) that is a copy of just customizing
data from client 100. In case something happens to
Master configuration client 100 and configured objects
gets corrupted, you can restore the configured objects
from the backup client instead of restoring the whole
Then the test will continue with the data in client
100 and transported into QA test master client 100.
Validation testing takes place in the quality assurance
test master client.
Any discrepancies or customizing changes are done
in the configuration and development clients and transported
into quality assurance test master.
Test master client is validated and signed off. By
validating and signing off from the QAS system, you
are ensuring that all the tests are conducted successfully
without any error. The entire configuration is working
according to the customers requirement.
After the signoff procedure is completed in QAS environment,
it is time to create the production instance and applying
the signed off change requests.
Important Tip: The project or customizing team leader
creates a change request for each IMG view. When change
requests are associated with an IMG view level, it
is necessary that the change requests be created by
assigning the IMG views to the appropriate team member
or group. This enables the change requests to be integrated
within project management and become an integral part
of the process.
The following is procedure is very important for the
customizing or development process:
Release a development change
2. Freeze development of the object(s) included in
the change request
3. Import and verify the change in the quality assurance
4. Sign-off on the change
5. Release the development object(s) so that further
development may be allowed
There are four different kinds of objects that can
be transported in SAP environment.
Locally created in development environment objects
such as tables, dynpros, screens, ABAP/4 programs,
2. Objects originally came from SAP. (Changes to these
objects are called repairs)
3. Table entries.
4. Scripts (Forms and layout sets)
make the CTS process easy for the users, SAP uses
workbench organizer and customizing organizer from
release 3.0 onward. Later in the chapter we will learn
more about workbench organizer and customizing organizer.
The following is the complete process to transport
objects from one system to another in CTS pipeline
using workbench organizer and customizing organizer:
For the workbench organizer and customizing organizer
to work properly, the CTS system should be initialized
and configured first using transaction SE06 transaction.
It is recommended to have a CTS pipeline design first
before using SE06 transaction. If you know how your
CTS pipeline is going to look like then it will be
easy to chose the right option from the following
screen. In this process all the systems are defined
in TSYST table, the transport route is defined in
TWSYS table and the recipient systems are defined
in TASYS table. The SE06 initialization process goes
through screen by screen to configure TASYS, TSYST
and TWSYS tables.
Make sure that the RDDIMPDP program is scheduled as
a background job in each client. RDDNEW PP program
should be executed to start the RDDIMPDP in a client.
It is recommended to schedule RDDIMPDP program as
Development class and Transport layers needs to be
Customizing and development work starts in development
Task and Change requests are released from the system
using SE09 or SE10 (SE01 can also be used, but not
recommended from 3.X onward) and exported to the data
file and cofiles of the system.
Make sure TP is working properly using different tools.
Logon to the Unix level or NT level and do the transport
to target system. Going to /usr/sap/trans/bin in the
UNIX level and use the tp command. Example: tp import
devk902345 qas client<X> U1.
If the TMS (Transport manageent system is available
from 3.1H) system is available then use that tool
for transporting the change request.
Check the return codes of the logs in SE10/SE09/SE01
or TMS to find out if the objects are transported
the CTS system:
CTS system or the Workbench Organizer (WBO) must be
setup at least once using SE06 transaction.The above
procedure can be done after the SAP instance is installed.
It is recommended to know the CTS pipeline beforehand;
when the user is doing CTS configuration using SE06.
It is very important to know the roles of all the
systems in the CTS pipeline. For a successful implementation
of a SAP project, it is very important to design an
appropriate CTS landscape. The user has to logon as
DDIC in client 000 to configure the CTS system. The
DDIC user needs S_CTS_ALL authorization to setup the
workbench organizer using SE06.
tips: If the user gets a message in SE06 transaction
to use the transport management system to do any changes
to CTS configuration, then he/she should know that
the Transport Management System (TMS) is already configured
that system and all the changes to CTS system should
be done there.
will see more about the Transport Management System
later in this chapter. User should know different
system types before configuring the Workbench Organizer
system types in a typical SAP environment: Integration
(Development), Consolidation (Quality Assurance) and
a SAP project the development work is done in the
integration system. This system is the original owner
of all the objects. The development system does not
permit to transport originals to the consolidation
system. After the customizing and development work
is done, then the pre-defined change requests are
released to the quality assurance or consolidation
system. The development class of an object defines
the integration and consolidation system for that
the change requests are transported to the consolidation
system using transport utility TP. Then all the changed
objects are tested and verified in the consolidation
system. This system is used as a staging area for
the changed objects, so this system is also called
staging system. The correction of original object
is not allowed here; any change to the original objects
is called a repair. SAP recommends doing the corrections
only in the original system or in this case development
system except some special scenarios.
all the change requests are tested properly in the
consolidation system, they get transported to the
delivery or production system. In a CTS pipeline there
can e multiple delivery or production systems.
To make the multiple delivery systems work properly
in the CTS pipeline; they should be defined properly
in the TASYS table and in Workbench organizer settings.
the initial screen for setting up the Workbench Organizer
SE06 as shown in figure 10.5 , the <sid name>
appears by default. The system picks up the exact
sid name that was given to the SAP instance when it
was installed. This name is very unique in the CTS
pipeline. Also as shown in figure 10.5 the system
status box there are two fields: R3 standard installation
and Database copy or migration (in 45B system); there
are three fields as: new installation, database copy
and modified with workbench organizer in 3.1H version.
The first entry "New installation" can be
used if it is a new installed system or the system
was installed from SAP R/3 CDs using R3INST utility.
second entry "Database copy" can be used
if the system is database copy of another R/3 system.
For example, DEV system is installed first and then
it was copied to TRN system for end user training.
Now while doing the configuration for Workbench Organizer
in TRN system, the user can use the entry "Database
third entry "Modified with the Workbench Organizer"
is used when the Workbench Organizer is already been
the right hand side of the 3.1H SE06 transaction screen
"System configuration" box is there. To
chose the right entry from this box, the user should
know how many systems are there in the CTS pipeline
and what role each system will be playing. For example
if there are three systems in the CTS pipeline and
they are acting as develop, consolidation and delivery
system then the user should chose "3 system group".
It is very important for the user to know that the
option that will be selected here can directly affect
the TSYST, TASYS, TWSYS and DEVL tables.
following are the options in system configuration
system: This entry is selected if there is only one
system in the CTS pipeline. This system will act as
development, consolidation and delivery. Usually in
very small implementation (training centers) this
kind of system is found.
and Production system: In this case the test system
acts as integration and consolidation; the other system
acts as a delivery system. The current system can
be a test system or it can be a production system
or delivery system.
system group: This entry is chosen if there are three
systems in the CTS pipeline. Three of them are acting
as development, consolidation and production system.
This kind of implementation is very common in the
configuration: In this case user needs to enter the
values in TSYST, TASYS and TWSYS tables. When the
CTS pipeline is real complicated or user wants to
configure the Workbench Organizer in his/her own way
this entry is chosen.
By selecting the "create" button after the
selection is done, user can start configuring the
Workbench Organizer. The list of available systems
is shown in the next screen and the user can enter
other systems here. After each screen user should
continue with the "continue" button until
the whole process is done.
It is better to check TASYS, TSYST, DEVL and TWSYS
tables to see if all the entries are defined correctly.
The consolidation and delivery system name can be
changed any time after the configuration is done,
but the user has to release all the change requests
from the system to do that.
are the tables used to setup the Workbench Organizer:
(figure 10.6): Table TSYST defines all the systems
in the CTS pipeline. This table must be identical
in all the systems in the CTS pipeline.
(figure 10.7): Table DEVL contains all the transport
layers. As we have seen before a transport layer defines
the transport path from the integration system to
the consolidation system. DEVL also must be identical
in all the systems in the pipeline.
(figure 10.8): This table defines all the systems
in the CTS pipeline for which change request will
be delivered automatically after the successful import
into the consolidation system. Change requests other
than those defined by the consolidation path can be
made to the delivery system if the cross transports
are allowed. This table must be identical in all the
system in the CTS pipeline.
(figure 10.9): This indicates the consolidation routes
for the change requests. This table also must be identical
in the CTS pipeline.
the appropriate system change option:
can follow path SE06 -> System change option to
set the system change option. There are four different
change options and user can use each of this option
in different systems and in different phase of the
cannot be changed: This option does not allow creation
or changes to the objects in ABAP/4 Development Workbench.
This option is suitable for a production environment
when the objective is not to allow any user to do
any change to the system.
original objects: With this option only the SAP owned
or system owned objects could be changed. For example
when SAP specialists are working in the production
environment and they want to change some system objects,
this option can be chosen.
customer objects: All objects not owned by SAP can
be modified or repaired using the Workbench Organizer.
This is the right option for a sand box system, where
end users want to change their customizing or development
objects. In this environment it is not secured to
give the system object change access to the users.
objects can be changed: This option allows changing
any object in the system. With this option the system
is totally open for any changes. All changes are made
using the Workbench Organizer. This option is chosen
generally in the development or sandbox environment.
Dependant and Client Independent objects
are two kinds of SAP objects: client dependent and
client independent. A SAP system can have several
clients. Objects used in several clients are called
client dependant objects such as ABAP/4 programs.
Objects used in a specific client are called client
dependant objects. In SAP system, a table can be client
dependant or client independent. The best way to know
whether a table is client dependant or not a user
can open the table attributes in SE12 or SE11 transaction
and look for a mandt field. If the mandt field is
there in a table then that table is a client dependant
table. MANDT implies the client name or number.
Organizer and Customizing Organizer:
objectives of Workbench Organizer are logging of system
changes with change management, organizing development
objects, revision management and transport functionality.
The change management is automatically activated.
It registers all changes, maintains original copies
and tracks the customization in each client. The Workbench
Organizer records and controls changes to the following
dictionary objects, ABAP/4 programs, Screens, User
interface definitions, Documentation, Application-defined
transport objects and customizing objects.
Workbench Organizer is automatically activated every
time a user edits a repository object. The recording
of the objects in the request ensures that all changes
made in the ABAP/4 development workbench is customizing
are registered. The Workbench Organizer is fully integrated
into the ABAP/4 development workbench and the customizing
tools. Using the above feature user can switch to
the Workbench Organizer from all the transactions
of customizing and ABAP/4 development workbench. The
entire Workbench Organizer change requests and tasks
can be found in transaction SE09 as we have seen before
in figure 10.1.
team leaders in a SAP project implementation divide
the project work using the Workbench Organizer. Different
change requests are created for different developers
to record all the changes in the customizing and development
process. The process of linking several users to enable
to work in-group in a project is controlled by tasks,
which belong to a common change request. Developments,
Corrections and repairs are recorded in tasks a transported
using change requests. First the team leader creates
a change request for a particular group of developers
or individual developer. The tasks under the change
requests are assigned to different developers. A very
important feature of Workbench Organizer is the transport
type and the target system is automatically assigned
and no longer need to be maintained by the user as
2.2 version. The change requests record all the changes
made to development objects or customizing settings.
The customizing objects and the ABAP/4 Development
Workbench objects are recorded in separate requests.
The tasks are released first by different developers
that are assigned to them in the project and then
the team leaders or the appropriate user release the
change requests to export them to the common transport
file system. In SE10 and SE09 transactions, the users
can see the requests and task numbers with the short
descriptions and user names. Authorizations are available
to restrict the access of particular user groups to
the functions of the Workbench Organizer. Once the
objects are included in a change request, they are
locked against all the development work. Only the
users who created the change request can edit it.
Other users are only allowed to display the objects
in the request, until they have been released. Each
development object is assigned to a development class
that indicates the area that object belongs to. The
objects of entire ABAP/4 Development Workbench are
based on development classes.
Organizer in detail: the Customizing Organizer manages
the customizing requests. The Workbench Organizer
(SE09) only records the changes to SYST objects (ABAP/4
repository and customizing for all clients), the SAP
R/3 system also provides Customizing Organizer transaction
(SE10) that can used to record changes to both SYST
and CUST (client specific customizing) objects. As
we know already in release 3.0 and onward the Workbench
Organizer, Customizing Organizer and the transport
system also automatically record all changes to customizing
settings. If the recording is on for the client in
client maintenance process using T000 table, mainly
customizing requests are generated. This ensures that
the changes to customizing objects can be transported
to target client with out affecting the other clients
in the target. If the recording is not on for the
source client then no guarantee can be given that
the result of the transport can be restricted to one
client in target system. If the transport contains
client independent objects, then it is recommended
from SAP to adjust the corresponding settings in the
target client in order to assess the changes in all
the clients. The figure 10.10 shows an example of
client level settings.
of the client shows whether the client is development,
test, demo, training, and customizing or production
Record Keeping can be set for each client separately.
For example no change option does allow any users
to change anything in the system.
procedure lock by the flag is set in the target client
while the client copy is going on. Only SAP* and DDIC
users are allowed to logon at this time. Other users
get the warning message about the client copy when
they try to logon.
cascade lock is restricted to user DDIC to prevent
a normal customer client from being damaged by an
upgrade. In upgrade process many client specific tables
are cascaded in all customer clients. For example
in client 066 (early watch client) this setting is
applied, because the client is not meant to use the
normal SAP standard.
of the CATT (Computer Aided Test Tool) procedure allows
restarting test run repeatedly. This process changes
the database contents, so user should know whether
to declare this as property in the client or not.
Customizing Organizer the configuration decides whether
customizing requests will be transported or it is
local. After the Customizing Organizer decides that
the request will be transported, it finds out the
destination of the change request. The customizing
objects are not locked against the other users. They
do not have any original system like ABAP/4 Development
Workbench. Changes to the customizing settings can
be recorded in a development/correction that is assigned
to a change request or to a customizing request. In
transaction SE10 we can see SYST category change requests
and CUST category change requests. Most of the changes
made to the customizing objects fall into CUST category.
Client independent customizing and the development
objects from the ABAP/4 Development Workbench fall
in SYST category and are recorded in Workbench Organizer,
but also we can see them in Customizing Organizer
(SE10). The following figure 10.11 displays an example
of Customizing Organizer.
system is a complementary tool to the workbench organizer.
The workbench organizer records all the changes in
a SAP system and transport system transport all those
changes to other SAP systems. The transport system
is used to move objects from one SAP system to another
SAP system in an orderly manner. The transport system
uses the change requests to copy objects from a source
system to the target system. The objects are transported
in two steps:
All the objects from the source system database are
exported to common transport directory.
2. The objects are imported to the target system database
using a SAP UNIX command TP.
the SAP systems in the CTS pipeline share a common
transport directory /usr/sap/trans; that file system
is mounted to all the other systems. All the R/3 systems
in the CTS pipeline or landscape must have unique
names or sid ids. For example development system can
have a unique <SID> name DEV. In the case where
objects at the source and target systems share a common
name, the source system object as part of the transport
overwrites the target system object. If a change request
has been recorded for an object indicating that it
is to be deleted, this task will be accomplished by
the system after the transport is complete.
As we have seen earlier in this chapter in a development
project, the team leaders define the change requests
and the tasks first for all the team members. The
team members start doing the customizing and development
work and all the changes get recorded in the tasks.
After the team members release all the tasks, the
team leaders release the change requests. In the release
process all the objects get exported to the common
transport directory and the transport to the appropriate
target system takes place at the Unix level or operating
If the recording for a particular client is on then
all the customizing table entries automatically get
recorded in the workbench organizer. Users can also
manually add the entries to the editor of the change
requests and transport them from one system to another.
A change request contains a list of objects to be
transported, information on the purpose of the transport,
the type of the transport that is taking place, one
of two possible request categories (SYST or CUST)
and the target system.
All the ABAP/4 repository and customizing for all
the clients belong to SYST category while all client
specific customizing belong to CUST category. Tasks
and change requests from CUST category can only have
CUST category objects; that is client specific. As
SYST allows combination of objects the CUST category
can be a part of SYST category. The tasks and requests
of category SYST can have CUST category objects too.
The CUST category is like a subclass of the SYST category.
figure 10.12, we can see how the tasks and change
requests are presented in a tree structure for a user
from release 3.0 it is recommended to use SE09 or
SE10 to perform all the CTS tasks, you can still create
a transport request using transaction SE01 and add
the objects to it as release 2.0. The user can go
through the menu from Workbench Organizer to come
to SE01 (The SE01 screen has changed from version
3.1 to 4.5 B). The path is Environment -> Transport
system. To create a new transport request a user can
click on create button. The user can use different
transport types (K- Transportable change request,
C- Transport of originals and T- Transport of copies)
as described in transport types section of this chapter.
In version 4.5B version, in se01 screen the user can
chose transports of copies, relocations to create
a T type transport or can display an individual change
the user can click on the create button to create
a change request as shown in the following figure
is very important for the users to provide the right
information for the transport. For example the target
system from development system in a project is usually
a staging or Quality Assurance (QA) system except
some special cases.
In version 3.1 and below the C transport type is chosen
if the user wants to move the original objects from
source to target. That means the target system is
going to be the owner of the objects after the transport.
If transport is done to an integration or development
system from a sandbox system the C transport type
is chosen. K transport is chosen, if the target is
test, consolidation, and delivery or production system.
transport types and how they are used
type: The system owner does not get changed with K
type transport. This kind of transport is only allowed
to consolidation and production system. After the
K type of transport is done no correction is allowed
to those objects. Any changes to K type transport
objects in consolidation system are called repair.
The repairs can be done to those objects if the change
option is selected in SE06 and change option is there
in client level selection in T00 table. Generally
K type transport is used for stage and production
type: With the C type transport the ownership of that
object is also transferred to the target. After the
transport is done, the target system is the owner
of the transported objects. The objects will be originals
of the target system. These kind of transports are
generally done in a four tier architecture, where
a bundle of development objects can go from the sandbox
environment to development environment or development
environment to integration environment and vice versa.
SAP recommends doing these transports when the objects
should move to another system for further development
type: T type is called a transport of copy. The ownership
of the object remains with the source; the target
system just gets the copy of the objects. When a sap
patch is applied to the development system and transported
to other systems, those are perfect example of T type
the short description, target system and transport
type is provided, now the user is ready to put the
objects in the transport editor. When working with
Workbench Organizer, the objects are automatically
in the editor after the tasks are released. To go
to the editor user can press the editor button on
the toolbar. The system now will display a maintain
object list window as shown in the following figure
can enter the objects in the editor by pressing the
insert button on the tool bar. There are following
five columns in the maintain object list screen:
Obj Obj. Name Funct. ObjStatus
TABU ZBAS K LOCKED
This is used for an object type in the system. R3TR
is a very important program ID used for table, data
elements and domains. User can use F4 key to find
all the possible entries.
This is used for the object type. For example TABL
is used for the table structure, TABU for data, DOMA
for the domain, TRAN for transaction. Using the F4
key can see all the object types available.
Name: This is the name used to identify the object
within the system. If the object is a table then the
table name is used here.
This field is normally grayed out but can be used
if part of the table contents s need to be transported.
Although some object types do not have an associated
object function, for those that do, simply select
the <Extras> menu, then the <Modify Object>
function to access the Funct field.
following are the possible entries for Funct field:
transport to the target system
D The object was deleted (only functions with deleted
M Delete and recreate on the database
K Object keys according to entries in the key list.
If you drill down on an object in the transport editor,
all the table keys can be found.
is the most used function type. Users generally see
this kind of transport request. Most of the time some
entries or keys are transported from the table using
function type K. while doing the customizing, users
can create a manual request and use this key to take
the right entries or keys from the table.
Status: This is the object status field. This field
is maintained by the system. The following are the
possible entries for this field and each of this entry
has different meaning to it.
NOT_IMP Object not imported
ERR_IMP Error importing object
OK_IMP Object imported
OK_GEN Object imported and generated
transport request should be protected using the path
Request/task -> Request -> Protect, so that
no other tasks can be assigned to the transport request.
If the transport is protected, the objects in the
transport object list get a LOCKED status and no other
users can modify the objects in the list. The protection
utility is very helpful for those developers who work
on the same objects for a long period of time and
not ready yet to release the transport. If the transport
has a LOCKED status instead of LOCKEDALL status, then
some of the objects in the request are not locked.
The status of a transport can be DOCUMENT or RELEASED
the status of a transport is RELEASED, that means
the transport is already released from the system
and incorporated into a target system. It also cannot
be modified anymore. If the status is DOCUMENT, then
the owner of the transport is still modifying the
transport request. If the transport is a brand new
transport and no objects are added yet to the transport;
then the status of that transport will be DOCUMENT.
the objects are placed in the maintain object list
window without any error, it should be saved by clicking
the save button. Now you are ready to release the
transport by pressing the release button. After the
transport is released the objects are no more locked
and the transport can not be modified anymore. If
the user wants to work on the same objects again then
a new transport must be created. The release job exports
the objects from the transport to the operating system.
A data file and cofile is created for that transport.
The SAP utility TP uses the cofile or a control file
to do the transport to the target system. The release
function also performs an import test in the target
system to verify if the objects in the transport would
overwrite originals. The user can disable this function
by using "<SID>/testimport = no" parameter
in TPPARAM file. Where <SID> would be the System
IDentification tag created when the system is installed
(e.g. DEV for the development system). The user should
always check the system log after doing the transport
to insure that the transport has proceeded as expected
and that there have not been any errors. From the
return code of the export, user can know whether the
objects were released and exported successfully.
development class is a set of development environment
objects that are mutually dependent upon one another.
The development class binds a class of objects together.
Those classes of objects must be developed and transported
together. By basing the development work on development
classes, a developer or customizing person can ensure
that no required objects are missed. A developer can
generate a list of the objects that belong to a class;
then he/she can use this list as a command file in
a change request. A development class also specifies
the attributes that help to organize tasks and change
requests. A development class specifies an integration
and a consolidation system for the objects in the
class. The development class can be defined in the
TDEVC table. To create a development class use the
menu path tools -> ABAP/4 Workbench and select
the button <Object Browser>. Enter the name
of the development class you wish to create and press
the <display> button. You will be asked if you
wish to create a development class. Complete the development
class screen and make sure to provide a brief description.
transport layer is assigned to each development class
and therefore also to all objects contained in the
class. A transport layer defines the transport path
from the integration system to the consolidation system
or from development system to the staging system.
For example the transport layer is like a bus and
the transport objects of different development class
are the passengers in the bus. The bus moves from
source (DEV system) to target (Stage system) and then
to production (PRD) system.
DEVL contains the definition of the transport layers.
DEVL must be identical in all the systems in the CTS
pipeline. Review the transport layer table DEVL using
transaction SE06 and either the display button or
Configuration->Display in your installation. The
listing will display all transport settings for the
current R/3 system. To review the contents of a specific
table such as DEVL containing the transport layers,
use the appropriate button on the button bar or the
menu path Environment -> Transport layers.
Types in the CTS pipeline:
note that your implementation may use entirely different
system names than these, depending on the preference
of the person who did the initial installation. It
is the purpose of the system that is important. However,
some set-up are such that some of these function may
be incorporated into a single implementation, not
used or replaced by other functions that better serve
the client needs.
systems- For carrying out development work and performing
Development systems- For developing critical parts
of a project in a isolated environment
Consolidation or Staging systems- For the final testing
and freezing the development objects. When you totally
stop changing any customizing objects in a SAP development
system that is called freezing.
Recipient systems or Production systems- After all
the objects are tested properly in the Consolidation
system, they are transported to the production environment.
The Sap customer goes live with this system.
ABAP/4 development objects play very important role
in SAP environment. Such objects consist of several
components. R3TR is the object type for complex ABAP/4
development workbench objects. LIMU is the object
type for individual components of a complex project.
For example LIMU REPO is used for a report. For example,
an object type R3TR PROG has an ABAP/4 program, user
interface definitions, and screens, with text and
documentation. Most repository objects belong to two
object types: R3TR and LIMU. There is another object
type R3OB; and they are used for application-defined
objects and are developed and programmed by SAP application
development group. The object types are used in the
task and change request editor to transport objects
from one system to another. The SAP pre defined object
types helps the developer to transport different kind
of objects. For example a single screen can be transported
using the predefined object types from SAP. In addition
to the predefined SAP objects, the developers can
also define and change his own repository objects.
to the customer requirements some objects are changed
in the process of customizing; those objects are called
customizing objects. For example, the customizing
objects can be the client specific table entries grouped
together to form a customizing objects for specific
are five types of R/3 system changes:
Customizing: This type of system changes, involve
customizing using the special customizing transaction.
Changes are scheduled in advance.
Client or customer developments: Creation of customer
Enhancements: Customer changes the SAP repository
objects according to the requirement.
Modification: Customer changes the SAP repository
objects. In this case customer version has to be modified
to match the new SAP version. In the upgrade, SPDD
and SPAU plays a very important role to determine
whether to keep the modifications to the existing
object or returning to SAP standard.
Advanced correction: To apply bug fixes to the R/3
system from SAP directly using a hot package.
each change request, the developer needs to include
required documentation that gives meaningful information
to other users who can refer the change request any
time in the project and understand the objective behind
it. All changed objects are recorded automatically
in the object lists of a change request. The documentation
and version management gives the user a complete control
over all the configurations done in a R/3 system.
It is very important for the developers to know that
the development of the original objects should be
performed in the appropriate development environment
to ensure the stability and consistency. Only original
objects may be modified to prevent parallel work on
the same object. To make the implementation cycle
( development -> stage-> production) go smoothly,
SAP recommends Development, Consolidation and Delivery
systems (different terminology are used in different
environment). Development takes place in the integration
system. Changed objects are then released to the consolidation
system. The integration system is therefore commonly
known as the development system. The changed objects
are tested and verified in the quality assurance or
consolidation system. After the successful testing,
they are transferred to the production system.
Workbench Organizer is linked to the transport system;
and we have already learned how the transport system
works. Transport system uses change requests to carry
objects from one system to another. Each change request
has its own transport log; this log keeps all the
transport information about that change request. The
Information system is an important tool in Workbench
Organizer (transaction SE03). The Information system
assists the users to display, analyze, edit and find
tasks, transports and change requests. The following
figure 10.15 shows an example of the information system.
system level files in the transport process:
SAP C program TP, requires a special file structure
for the transport process. The file system is operating
system dependent. TP uses a transport directory or
file system, which is called /usr/sap/trans.
The /usr/sap/trans file system is generally NFS mounted
form the development system to other systems unless
a system is defined as a single system in the CTS
pipeline. All the sub directories should have <SID>adm
as the owner and sapsys as the group; and proper read,
write and execute access should be given to owner
and the group. The TP imports are always performed
following are the subdirectories in /usr/sap/trans:
holds the data of transport objects after they are
released . The example of a data file is R904073.DEV.
The extension DEV means the data file was released
from the DEV or development system.
The cofiles directory holds the command files for
all change requests. These files are like a command
or control files used to import the data files. The
common directory for CTS system is /usr/sap/trans.
After a change request is released from the source
system , the data is exported immediately to the file
system of the operating system. The SAP transport
utility TP uses the cofile to transport a data file.
The example of a file in cofiles directory is K904073.DEV.
holds the most important file TPPARAM in the CTS system.
TPPARAM file has all the information about the CTS
systems in the CTS pipeline. TPPARAM file is the parameter
file for the transport program TP and it is the common
file for all the systems in the CTS pipeline. As you
know already that /usr/sap/trans should be NFS mounted
to all the systems in a CTS pipeline, TP program has
access to the TPPARAM file from all the systems. The
following is an example of typical TPPARAM file for
five SAP systems in the CTS pipeline:
TPPARAM.sap 20.6 SAP 95/03/28
# Template of TPPARAM for UNIX #
# First we specify global values for some parameters,
# later the system specific incarnation of special
# global Parameters #
transdir = /usr/sap/trans/
dbname = $(system)
alllog = ALOG$(syear)$(yweek)
syslog = SLOG$(syear)$(yweek).$(system)
# System spezific Parameters #
# Beispiel T11 #
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
QAS/dbhost = sap8f
QAS/r3transpath = /usr/sap/QAS/SYS/exe/run/R3trans
TRN/dbhost = sap17
TRN/r3transpath = /usr/sap/TRN/SYS/exe/run/R3trans
PRE/dbhost = sap19f
PRE/r3transpath = /usr/sap/PRE/SYS/exe/run/R3trans
PRD/dbhost = sap18f
PRD/r3transpath = /usr/sap/PRD/SYS/exe/run/R3trans
holds the entire log files, trace files and statistics
for the CTS system. When the user goes to SE09 (workbench
organizer) or SE10 (customizing organizer) transaction
and opens the log for a transport, the log file for
that transport will be read from /usr/sap/trans/log
directory. Each change request should have a log file.
Examples of log files are DEVG904073.QAS, DEVI904073.QAS
and DEVV904073.QAS. The name of a log file consists
of the names of the change request, the executed step,
and the system in which the step was executed:
we can analyze the above example DEVG904073. QAS.
The <source system> = DEV, <action> =
G or report and screen generation, <6 digits>
= 904073 (these six digits numbers are exactly the
same number as the six digits of the transport) and
the <target system> = QAS
values for <action> are:
D: Import of application-defined objects
E: R3trans export
G: Report and screen generation
H: R3trans dictionary import
I: R3trans main import
L: R3trans import of the command files
M: Activation of the enqueue modules
P: Test import
R: Execution of reports after put (XPRA)
T: R3trans import of table entries
V: Set version flag
X: Export of application-defined objects.
holds action log files. The example of an action file
is DEVZ902690.DEV. The following are the contents
of the file:
1 ETK220 "=================================================="
1 ETK191 "04/30/1998" Action log for request/task:
1 ETK220 "=================================================="
1 ETK185 "04/30/1998 18:02:32" "MOHASX01"
has reincluded the request/task
4 EPU120 Time... "18:02:32" Run time...
1 ETK193 "04/30/1998 18:02:33" "MOHASX01"
owner, linked by "MOHASX01" to "DEVK902691"
4 EPU120 Time... "18:02:33" Run time...
1 ETK190 "05/04/1998 11:02:40" "MOHASX01"
has locked and released the request/task
1 ETK194 "05/04/1998 11:02:40" ****************
End of log *******************
4 EPU120 Time... "11:02:40" Run time...
~"DEVZ902690.DEV" 10 lines, 783 characters
transport buffer of the target systems; contains control
information on which requests are to be imported into
which systems and in what order the imports must occur.
The /usr/sap/trans/buffer will have a directory for
each system in the CTS pipeline. For example the buffer
file for DEV system is /usr/sap/trans/buffer/DEV.
holds information pertaining to transport requests
for each system user. There are files for each user
who released change requests from the system.
holds information about temporary data and log files.
While the transport is occurring the Basis administrator
can find a file that is related to the transport in
the tmp directory; that file shows the exact status
if the transport (What objects are being imported
at that time).
SAP delivery class and table types and tables in the
delivery class defines who (i.e. the SAP system itself
or the customer) is responsible for maintaining the
table contents. In addition the delivery class controls
how the table behaves in a client copy and an upgrade.
For example when you select a SAP defined profiles
to perform a client copy, certain tables are selected
according to their delivery class. DD02L table can
show what delevery class a table belongs to.
following delivery classes exist:
A: Application table.
C: Customizing table, maintenance by customer only.
L: Table for storing temporary data.
G: Customizing table, entries protected against
E: Control table.
S: System table, maintenance only by SAP.
W: System table, contents can be transported via
own TR objects.
The table type defines whether a physical table exists
for the logical table description defined in the ABAP/4
Dictionary and how the table is stored on the database.
following are different table types in SAP:
There is a physical table on the database for each
transparent table. The names of the physical table
and the logical table definition in the ABAP/4 Dictionary
are same. For every transparent table in SAP, there
is a table in database. The business and application
data are stored in transparent tables.
No data records exist on the database for a structure.
Structures are used for the interface definition between
programs or between screens and programs.
An Append structure defines a subset of fields which
belong to another table or structure but which are
treated as a separate object in the correction management.
Append structures are used to support modifications.
following table types are used for internal purposes,
for example to store control data or for continuous
Pooled tables can be used to store control data (e.g.
screen sequences, program parameters or temporary
data). Several pooled tables can be combined to form
a table pool. The table pool corresponds to a physical
table on the database in which all the records of
the allocated-pooled tables are stored.
Cluster tables contain continuous text, for example
documentation. Several cluster tables can be combined
to form a table cluster. Several logical lines of
different tables are combined to form a physical record
in this table type. This permits object-by-object
storage or object-by-object access. In order to combine
tables in clusters, at least part of the keys must
agree. Several cluster tables are stored in one corresponding
table on the database.
in CTS process:
and TRBAT are the major tables in the CTS process.
After TP program has sent the event to the r3 system,
RDDIMPDP checks table TRBAT in the target system to
find out if there is an action to be performed. Mass
activation, distribution, or table conversions are
the examples of actions. If there is action to be
performed, RDDIMPDP starts the appropriate program
in the background task. RDDIMPDP then reschedules
checking table TRJOB, RDDIMPDP automatically recognizes
if a previous step was aborted, and restarts this
step. For each transport request , TP program inserts
an entry into table TRBAT. If the return code 9999
in this table then the step is waiting to be performed.
Return code 8888 indicates that the step is active
and currently being processed. A return code of 12
or less indicates that the step is finished. In addition,
TP inserts a header entry to let the RDDIMPDP program
know to start processing. The column return code will
therefore contain a B for begin. When RDDIMPDP is
started, it sets the header entry to R(un), and starts
the required program. When all the necessary actions
are performed for all the transport requests, the
column return code contains all the return codes received,
and the column TIMESTAMP contains the finishing time.
The header entry is set to F(inished). TP monitors
the entries in TRBAT and TRJOB tables. When the header
entry in TRBAT is set to finished. The entry in TRJOB
- Development classes
TASYS - Details of the delivery. Systems in the group
that should automatically receive requests, have to
be specified in table TASYS.
TSYST - The transport layers will be assigned to the
integration systems. ( Define all systems)
TWSYS - Consolidation routes ( define consolidation
DEVL - Transport layers are defined here
"Configuring the CTS system" section, We
will learn more about the transport tables in SE06
in the CTS process:
the CTS table section we learned about the RDDIMPDP
program. RDDIMPDP program needs to be scheduled in
all the clients in an instance. It is recommended
to schedule the RDDIMPDP as event driven.
RDDPUTPP and RDDNEWPP programs can be used to schedule
RDDIMPDP program in the background.
ABAP/4 programs that RDDIMPDP starts are determined
by the transport step to be executed that is entered
in the function field of table TRBAT.
Job Name Description of transport Steps
RDDMASGL Activation of ABAP/4 dictionary objects
M RDDMASGL Activation of match codes and lock objects
S RDDDISOL Analysis of database objects to be converted
N RDDGENOL Conversion of database objects
Y RDDGENOL Conversion of matchcode tables
X RDDDICOL Export of AD0 objects
D RDDDIC1L Import of AD0 objects
E RDDVERSE Version management update during export
V RDDVERSL Version management update during import
R RDDEXECL Execution of programs for post - import
G RDDDIC3L Generation of ABAP/4 programs and screens
of the important features of Workbench Organizer is
Version Management. This feature works for all the
development objects. Using the version management
feature the users can compare and retrieve previous
versions of objects.
management provides for comparisons, restore of previous
versions, documentation of changes and assistance
in the adjustment of data after upgrading to a new
release. With the release of a change request, version
maintenance is automatically recorded for each object.
If an object in the system has been changed N times,
it will have N delta versions and one active version.
To display version management, for ABAPs use transaction
SE38 and for tables, domains and data elements use
SE11. The path to follow is Utilities -> Display
version. Using version management the users can view
existing version for previously created ABAP code,
make changes to the code, compare code versions and
restore original version of the code. Now the users
will be restore previous versions without cut and
paste steps of the past.
and R3trans program:
basis administrator uses TP program to transport SAP
objects from one system to another. TP is a C program
delivered by SAP that runs independently of the R/3
system. TP program uses the appropriate files located
in a common transport directory /usr/sap/trans. TP
starts C programs, ABAP/4 programs and special operating
system commands to its job. R3trans is one of the
most important utility program called by TP. Before
using the TP program, the basis administrator needs
to make sure that the CTS system is setup properly
and the right version of TP is running in the system.
The TP program is located in the run time directory
/usr/sap/<SID>/SYS/exe/run directory. It is
automatically copied in the install process. A global
parameter file TPPARAM that contains the databases
of the different target systems and other information
for the transport process controls TP. The global
parameter file determines which R3trans is used for
each system. If the parameter r3transpath is not defined
properly then no export and import can be done. The
basis administrator should make sure that the default
value "r3transpath" is properly defined.
Later in this chapter we will learn more about TP
and R3trans; also we are going to see how they are
the TPPARAM file:
time TP is started, it must know the location of the
global parameter file. As we have seen before TPPARAM
file should be in directory /usr/sap/trans/bin. The
parameters in TPPARAM can either global (valid for
each and every system in the cts pipeline) or local
to one system. Th parameters are either operating
system dependant (these parameters preceded by a keyword
corresponding to the specific operating system) or
database dependant (contain a keyword corresponding
to a specific database system).
global parameter file provides variables that can
be used for defining parameters. The variables can
be defined in format: $(xyz). The brackets can be
substituted with the "\"-character if required.
following pre-defined variables are available for
the global parameter file:
The CPU name can be sun or as4 for example. In heterogeneous
networks this variable is very important.
Acronym for the name of the operating system. The
example for this variable can be
hp-ux, or sunos . This is an operating system specific
Used for the day of the week (SUN,MON,....).
Used for the day of the current month (01-31).
Used for the name of the month (JAN...DEC).
Used for the Month (01-12).
R/3 System name.
Day of the week (00-06, Sunday=00, Monday=01, Tuesday=02
and so on).
Day of the current year (001-366). Using the number
any day of the year can be chosen.
Year (Example:1998 or 1999).
Short form of the year (two positions).
Calendar week (00-53). The first week begins with
the first Sunday of the year.
the database connection:
transport environment also needs parameters to connect
to the R/3 System database. As we know already the
every instance in the R/3 CTS pipeline has its own
database, therefore specific parameters should be
defined for each database system. From dbtype parameter
of RSPARAM file, TP program identifies the database
two parameters "dbname" and "dbhost"
are required for ORACLE databases.
DBHOST: is the name of the computer on which the database
processes execute. TCP/IP name of the host if NT is
DBNAME: is the name of the database instance.
As of Release 3.0E, two new parameters have been introduced.
DBLOGICALNAME: The default value is $(system). The
logical name that was used to install the database.
DBCONFPATH: The default value is $(transdir).
parameters "dbname" and "dbhost"
are also used for INFORMIX databases in an installation:
DBHOST: Same as Oracle.
DBNAME: Name of the database instance, uppercase and
lowercase are distinguished here.
INFORMIXDIR : "/informix/<SAPSID>"
is the default value. Defines the directory namewhere
the database software can be found.
default value under Unix. The name of the SQLhosts
file with its complete path is defined with this parameter.
is the default value. The name of the database server
may be specified for a local connect.
"$(dbhost)$(dbname)tcp"is the default vlue.
The name of the database server can be specified for
a remote connect.
Microsoft SQL Server database the two parameters "dbname"
and "dbhost" are also required. DBHOST:
The TCP/IP name of the host on which the database
DBNAME: The database instance name.
DB2 in AS/400 only "dbhost" is required.
DBHOST: System name of the host on which the database
If the"OptiConnect" is used, the following
line should be specified:
two parameters "dbname" and "dbhost"
DBHOST: The host on which the database processes are
running. It is the TCP/IP name of the host for Windows
NT (As we have seen in the earlier examples).
DBNAME: Database instance name.
The DB2 for AIX Client Application Enabler Software
must also be installed on the host on which tp is
ALLLOG: "ALOG" $(syear) $(yweek)"is
the default value. This variable can be used in TPPARAM
file to specify the name of a file in which tp stores
information about every transport step carried out
for a change request anywhere in the transport process.
The file always resides in the log directory.
"SLOG $(syear) $(yweek).$(system)" is the
default value. This variable can be used to name a
file in which tp stores information about the progress
of import actions in a certain R/3 System. The file
does not store information for any particular change
request. The file always resides in the log directory.
Zero is the default value. If this parameter is set
to not equal to zero, a lower version of tp may not
work with this TPPARAM file. If the default value
(zero) is set, the parameter has no affect.
(Numeric value) The default value is 9. When STOPONERROR
is set to zero, tp is never stopped in the middle
of an "import" or "put" call.
When STOPONERROR is set to a value greater than zero,
tp stops as soon as a change request generates a return
code that is equal to or greater than this value (The
numeric value of the STOPONERROR parameter is stored
in the variable BADRC). Change requests, which still
have to be processed for the current step, are first
completed. A "SYNCMARK" in the buffer of
the R/3 System involved, sets a limit here. tp divides
the value of this parameter between two internal variables.
STOPONERROR itself is treated as a boolean variable
that determines whether tp should be stopped, if the
return code is too high.
(Numeric value too): The default value is 9. The REPEATONERROR
parameter is similar to STOPONERROR. The difference
is, REPEATONERROR specifies the return code up to
which a change request is considered to be successfully
processed. Return codes less than REPEATONERROR are
accepted as "in Order". Change requests
that were not processed successfully stay in the buffer.
Default value is "FALSE". A file is created
for each user of the R/3 System group in the "sapnames"
subdirectory of the transport directory. Except some
of the operating system,the name of the user is the
name of the file. It is very important to remember
hat the special characters or length of the file name
could cause problems. If all the R/3 Systems in the
transport group have at least Release level 3.0.;
TP program is efficient to handle this problem. The
user names are modified to create file names that
are valid in all operating systems and the real user
names are stored in a corresponding file.
we have seen so many parameters, for the minimum configuration
the following two parameters are very important.
specifies the name of the common transport directory.
The following is a typical example from TPPARAM of
Unix as we have seen before.
contains the name of the database host. In Windows
NT environment, this is the TCP/IP host name. The
following is an example in Unix:
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
TP, to control Start and Stop command
files and database in R/3 the following important
parameters are specified in TPPARAM:
for the tp Function "PUT": LOCK_EU (boolean)
default value is "TRUE". Though from version
3.1 onward the tp put command is used seldom in cts
process still it is important to know how this parameter
works. When "tp put" is used, it changes
the system change option . If the parameter is set
to "FALSE" nothing gets changed. If the
parameter is set to "TRUE", the system change
option is set to "Objects cannot be changed"
at the beginning of the call, and gets changed back
to its previous value at the end of the call. The
"tp put" command will give the exact status
of the locking mechanism.
(used as boolean value): Default value is "TRUE".
This parameter is about the user login while tp put
call is executed. If this parameter is set to "FALSE",
no locking mechanism for the users takes affect. If
this parameter is defined as "TRUE" then
a character is set in the database level; so only
DDIC and SAP* can log on to the system. Users that
have already logged on are not affected (this is a
reason for activating the parameters STARTSAP and
STOPSAP). The charactertor is removed at the end of
the call, and all the users can log on to the SAP
R/3 System again.
Default value is " ".or "PROMPT"
for Windows NT . This parameter is used by TP to start
an R/3 System. It is not necessary for the clients
to make tp start and stop R/3 system..
Default value is " "or "PROMPT"
for Windows NT. TP uses this parameter to stop an
Default value is " ". TP uses the value
of this parameter to start the database of an R/3
The parameter is not active under Windows NT.
Default value is " ". TP uses the value
of this parameter to stop the database of an R/3 System.
This parameter is not active under Windows NT.
above parameters in UNIX can be used as following:
= startsap R3
STOPSAP = stopsap R3
STARTDB = startsap db
STOPDB = stopsap db
R3 <SID> <HOST NAME> <START PROFILE>
STOPSAP = \\$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\stopsap.exe
R3 <SID> <HOST NAME> <INSTANCE>
<PROFILE PATH + Instance profile>
The parameters STARTDB and STOPDB are not active under
for the tp function "CLEAROLD"
(Numeric): Default value is "200". When
the data file has reached a minimum age, it is moved
to the subdirectory old data with tp check. tp clearold
all. The life span of the data files in the data sub
directory can be set in days with this all, parameter.
(Numeric): Default value is "365". When
a file located in the olddata subdirectory is no longer
needed for further actions of the transport system
and has reached a minimum age, it is removed with
tp check.all, tp clearold all. The minimum age in
days can be set with this parameter.
(Numeric): Default value is "365". This
parameter is used just like DATALIFETIME parameter.
(Numeric): Default value is "200". This
parameter applies to the life span of the log files.
When the log files in log subdirectory is no longer
needed for the transport system and has reached a
minimum age, it is deleted with the calls tp check.all,
tp clearold all. The minimum age in days can be defined
with this parameter.
Three Key Utilities of the CTS system (TP, R3trans
Earlier in this chapter we have seen the objectives
of TP. The TP transport control program is a utility
program that helps the user to transport objects from
one system to another. TP program is the front-end
for the utility R3trans. TP stands for "Transports
and Puts". To make the TP work successfully the
CTS system needs to be correctly configured. The following
steps are very important for TP to run properly.
transport directory /usr/sap/trans must be installed
and NFS mounted to all the systems in the CTS pipe
RDDIMPDP program must be running (event driven is
recommended) in each client. RDDIMPDP can be scheduled
in the background by executing RDDNEWPP or RDDPUTPP.
Use the tp checkimpdp <sap sid> command in /usr/sap/trans/bin
directory as <sid>adm user to check RDDIMPDP
the tp connect <sap sid> command in /usr/sap/trans/bin
directory to see whether the tp program is connecting
to the database successfully or not. To run TP command
the user has to logon as <sid>adm in source
or target system.
R/3 Systems in the CTS pipeline must have different
Global CTS Parameter File TPPARAM must be correctly
source system (for the export) and target system (
for the import) must have at least two background
work processes. TP always schedules the C class job,
so if all the background jobs are defined as A class
job then there will be problems in transport steps.
Tips :.It is always better to have the up to date
TP version installed in your system. A user can ftp
a current version of TP from SAPSERV4 of SAP. Though
R3trans and other utility programs can be used to
do the transport, it is recommended to use TP whenever
possible for the following reasons..
exports and imports are done separately using TP program.
For example: when a transport is released from the
system, the objects are exported from the source database
to the operating system and then the import phase
starts to transport those objects to the target system.
takes care of the order of the objects. The order,
that was followed to export the objects; the same
order will be followed to import them to the target
TP command processes all change requests or transports
in the SAP system buffer that have not yet been imported
successfully. All the import steps are executed automatically
after TP calls R3trans program to execute the following
Import: ABAP/4 dictionary objects will be imported
in this step.
Activation: Name tabs or runtime descriptions will
be written inactively. The R/3 system keeps running
until the activation phase is complete. The enqueue
modules are the exceptions in the running phase. After
the activation of new dictionary structure the new
actions are decided to get the runtime objects to
the target system.
conversion: If necessary the table structure is changed
in this phase.
Nametabs: The new ABAP/4 Dictionary runtime objects
which were inactive up to now are moved into the active
runtime environment in this process. The database
structures are adjusted accordingly. From the first
step to the Main import step inconsistencies can occur
to the R/3 system. After the main import phase all
the inconsistency ca be solved.
import with R3trans: All the data are imported completely
and the system comes to a consistent state.
of enqueue-objects: The enqueue-objects cannot be
activated in the same way as the objects of the ABAP/4
Dictionary, so they have to be activated after the
main import in this step. They are then used directly
in the running system.
Conversion of match codes, Import application defined
objects, versioning and execution of user defined
activities are some of the steps after activation
of enqueue-objects. The next step is generation of
ABAP/4 programs and screens, where all the programs
and screens associated with the change request are
generated. When all the import steps are completed
successfully, the transport request is removed from
the import buffer.
is recommended by SAP to schedule regular periods
for imports into the target system (e.g. daily, weekly
or monthly). Shorter periods between imports are not
advisable. The transport to production should not
be done in the off hours when the users are not working
can be started with different parameters. The "tp
help" command can help user to generate a short
description about the use of the command.
The following are the some important commands of TP:
export <change request>: The complete objects
in the request from the source system will be transported.
This command also used by SAP System when it releases
r3e <change request>: R3trans export of one
sde <change request>: Application defined objects
in one transport request can be exported.
tst <change request> <SAP system >: The
test import for transport request can be done using
createinfo <change request>: This command creates
a information file that is automatically done during
verse <request>: This command creates version
creates versions of the objects in the specified request.
Check the transport buffer, global parameter file
and change requests:
showbuffer <sid>: Shows all the change requests
ready to be imported to the target system.
count <sid>: Using this command users can find
out the number of requests in the buffer waiting for
go <sid>: This command shows the environment
variables needed for the connection to the database
of the <sid> or target system.
showparams <sid>: All the values of modifiable
tp parameters in the global parameter file. The default
value is shown for parameters that have not been set
import the change requests or transports:
addtobuffer <request>.<sid>: If a change
request is not in the buffer then this command is
used to add it to the buffer, before the import step
import all <sid>: This command imports all the
change requests from the buffer to the target system.
put <sid>: The objective of this command is
same as "tp import all <sid>", but
this command locks the system. This command also starts
and stops the SAP system, if the parameters startsap
and stopsap parameters are not set to " ".
import <change request> <sid>: To import
a single request from the source system to target
r3h <change request>| all <sid>: Using
this command user can import the dictionary structures
of one transport or all the transport from the buffer.
act <change request>|all <sid>: This command
activates all the dictionary objects in the change
r3i <change request> | all <sid>: This
command imports everything but dictionary structures
sdi <change request>|all <sid>: Import
gen <change request>|all <sid>: Screen
and reports are generated using this command.
mvntabs <sid>: All inactive nametabs will be
activated with this command.
mea <change request>|all <sid>: This command
will activate the enqueue modules in the change request.
When you call this command, note the resulting changes
to the import sequence.
tp utility options:
check <sid>|all (data|cofiles|log|sapnames|verbose):
User uses this command to find all the files in the
transport directory that are not waiting for imports
and they have exceeded the minimum time specified
using the COFILELIFETIME, LOGFILELIFETIME, OLDDATALIFETIME
and DATALIFETIME parameters of TPPARAM file.
delfrombuffer <request>.<sid>: This command
removes a single change request from the buffer. In
case of TMS, the request will be deleted from the
setstopmark <sid>: A flag is set to the list
of requests ready for import into the target system.
When the user uses the command tp import all <sapsid>
and tp put <sapsid>, the requests in front of
this mark are only processed. After all the requests
in front of the mark have been imported successfully,
the mark is deleted.
delstopmark <sid>: This command deletes the
stop mark from the buffer if it exists.
tp cleanbuffer <sapsid>: Removes all the change
requests from the buffer that are ready for the import
into the target system.
locksys <sid>: This command locks the system
for all the users except SAP* and DDIC. The users
that have already logged on are not affected by the
unlocksys <sid>: This command unlocks the system
for all the users.
lock_eu <sid>: This command sets the system
change option to "system can not be changed"
unlock_eu <sid>: This command unlocks the system
for all the changes.
backupall <sid>: This command starts a complete
backup using R3trans command. It uses /usr/sap/trans/backup
directory for the backup.
backup delta <sid>: Uses R3trans for a delta
backup into /usr/sap/trans/backup directory.
sapstart <sid>: To start the R/3 system.
stopsap <sid>: To stop the R/3 system.
dbstart <sid>: To start the database.
dbstop <sid>: To stop the database.
modes for TP: Unconditional modes are used with the
TP program and these modes are intended for the special
actions needed in the transport steps. Using unconditional
mode user can manipulate the rules defined by the
workbench organizer. The unconditional mode should
be used when needed, otherwise it might create problems
for the R/3 system database. Unconditional mode is
used after the letter "U" in the TP command.
Unconditional mode can be a digit between 0 to 9 and
each has a meaning to it. The following is a example
of a import having unconditional mode.
import devk903456 qas client100 U12468
Called a overtaker; change request can be imported
from buffer without deleting it and then uncoditional
mode 1 is used to allow another import in the correct
If U1 is used with the export then it ignores the
correct status of the command file; and if it is used
with import then it lets the user import the same
change request again.
When used with tp export, it dictates the program
to not to expand the selection with TRDIR brackets.
If used in tp import phase, it overwrites the originals.
When used with tp import, it overwrites the system-dependant
During the import to the consolidation system it permits
the source systems other than the integration system.
When used in import phase, it helps to overwrite objects
in unconfirmed repairs.
During import phase it ignores the limitations caused
by the table classification.
During import it ignores that the system is locked
for this kind of transport.
TP uses R3trans program to transport data from one
system to another in the CTS pipeline. efficient basis
administrator can use R3trans directly to export and
import data from and into any SAP systems. Using this
utility transport between different database and operating
system can e done without any problems. Different
versions of R3trans are fully compatible with each
other and can be used for export and import. The basis
administrator has to be careful using R3trans for
different release levels of R/3 software; logical
inconsistency might occur if the up to date R3trans
is not used for the current version of R/3 system.
syntax for using the control file is following:
[<options>] <control file> (several options
used at the same time; at least one option must be
For example: R3trans u 1 w test.log test
the above example a unconditional mode is used, a
log file "test.log" file is used to get
the log result and a control file "test",
where the instructions are given for the R3trans to
follow. The user needs to logon as <sid>adm
to execute R3trans.
following options are available for the R3trans program:
-d : This command is used to check the database connection
-u <int>: Unconditional mode can be used as
we have seen in the above example.
-v : This is used for verbose mode. It writes additional
details to the log file
-i <file>: This command directly imports data
from data file without a control file.
-l <file>: This provides output of a table of
contents to the log file.
-n : This option provides a brief information about
new features of R3trans.
t: This option is used for the test mode. All
modifications in the database are rolled back.
-c <f1> [<f2>]: This command is used for
conversion. The <f1> file will be copied to
<f2> file after executing a character set conversion
to the local character set.
tips: Do not confuse the backup taken using R3trans
with database backup. The backups taken using R3trans
are logical backups of objects. In case something
happens to the SAP system these backups can not be
used for recovery. R3trans backups can be only used
to restore a copy of a particular object that has
been damaged or lost by the user.
-w <file>: As we have seen in the above example
this option can be used to write to a log file. If
no file is mentioned then trans.log is default directory
for the log.
also can be used for the database backup.
ba: This command is used for a complete backup.
we will see in the next paragraph how to use
the control file for the backup.
R3trans bd: This command is used for a delta
backup if the user does not want a complete backup.
R3trans bi: This option will display backup
following are some of the examples of control files:
have already learned how to use a command for the
logical backup of the objects in the database. To
get a complete backup the following example control
file can be used.
file = /usr/sap/trans/backall
option "file = ..." is the name of the directory
into which the data files are to be written. If you
are taking a complete backup of DEV system then the
backup file is going to look like "DEV.A000.bck"
the next complete