System Administration Made Easy 11

Chapter 1: Prerequisites and General

nformation
Contents
Target Audience......................................................................................................12
Whats New..............................................................................................................12
Prerequisites ...........................................................................................................13
User...........................................................................................................................13
Special Definitions..................................................................................................14
System ......................................................................................................................15
Who Is an R/3 System Administrator?..................................................................16
Roles of an R/3 System Administrator ......................................................................16
Requirements of an R/3 System Administrator.........................................................18
R/3 System Guidelines ...........................................................................................18
Protect the System....................................................................................................19
Do Not Be Afraid to Ask for Help ..............................................................................19
Keep It Short and Simple (KISS) ............................................................................110
Keep Proper Documentation...................................................................................110
Use Checklists ........................................................................................................111
Use the Appropriate Tool for the Job......................................................................112
Perform Preventive Maintenance............................................................................112
Do Not Change What You Do Not Have To ...........................................................113
Do Not Make System Changes During Critical Periods..........................................114
Do Not Allow Direct Access to the Database..........................................................114
Keep all Non-SAP Activity Off the R/3 Servers.......................................................115
Minimize Single Points of Failure............................................................................115
Network with Other Customers and Consultants....................................................116
Corollaries to Murphys Law....................................................................................117
Types of Tasks ......................................................................................................118
Regularly Scheduled Tasks ....................................................................................118
Nonscheduled Tasks ..............................................................................................119

Chapter 1: Prerequisites and General Information

Target Audience
Relese 4.0B
12
Target Audience
The target audience for this guidebook is:
< The customer person or team where:
The SAP R/3 administrator is of a small to mid-size company with a small (one to
three people) technical team.
Each person in the team has multiple job responsibilities.
The system administrator has a basic knowledge of the operating system and
database.
< The junior consultant
Senior consultants, experienced system administrators, and DBAs may find portions of this
guidebook very elementary, but hopefully useful.
Whats New
Philosophy
This Oracle on SAP R/3 Release 4.0B System Administration Made Easy Guidebook departs
from the direction of prior editions. Of primary focus here is the importance of the on-
going nature of system administration.
This book is written for an installed system, where all installation tasks have been
completed.
Installation and installation related tasks, which are usually performed one-time, have not
been included in this guidebook. These tasks are normally done by your Basis consultants.
Organization
An entire section of this guidebook is organized around the regularly scheduled tasks an
administrator would perform.
The last section is unscheduled tasks, or those performed as needed.
Content
Real world practical advice from consultants and customers has been integrated into this
book. Because of this real world perspective, some of the statements in this book are blunt
and to the point.
Because the subject area of system administration is so large and the pool of knowledge so
extensive, it has been very difficult to reduce the volume to what one may call Made Easy.
Although material was carefully chosen for inclusion, it is by no means comprehensive.
A disaster recovery chapter has been added at the beginning of the book, emphasizing its
real world importance.
Chapter 1: Prerequisites and General Information
Prerequisites
System Administration Made Easy
13
Two new features of Release 4.0B are:
< Transport Management System (TMS)
< 4.0 CCMS Alert Monitor
A listing of various SAP and third-party resources has been added in appendix A .
This guidebook is an evolution of previous guidebooks. As such, future printings will also
be different in response to customers and consultants technical needs and desires. We
welcome your comments on this edition.
What s Not Provided
This guidebook is not a trouble-shooting manual. Most problems are investigative, which
means you need to examine the clues to find out how to proceed. When you find a problem,
attempt to first solve it yourself using your own resources before contacting your Basis or
technical consultant. You will learn to better analyze the exceptions with time and
experience.
Prerequisites
To help you use this guidebook, and to prevent this guidebook from becoming as thick as
an unabridged dictionary, we defined a baseline for user knowledge and system
configuration.
The two following sections (User and System) define this baseline. Please review these
sections to determine how you and your system match up. If you are deficient in an area be
aware that this book is written with certain presumptions about your knowledge and
expectations that particular system requirements have been met.
User
We have assumed that you have a baseline knowledge of R/3, the operating system, and the
database. If you are deficient in any of the following points, we recommend that you consult
the many books and training classes that specifically address the operating system and
database you use.
You should know how to complete the following tasks at:
< The R/3 System level
Be able to log on to R/3
Know how to navigate within R/3 using both menus and transaction codes
There are transactions that do not have menu paths and the only way to get to them
is by using the transaction codes.
< Operating system level
Be familiar with the file and directory structure
Be able to use the command line to navigate and execute programs
Set up a printer
Chapter 1: Prerequisites and General Information
Special Definitions
Relese 4.0B
14
Perform a backup using standard operating system tools or third-party tools
Perform basic operating system security
Copy and move files
Properly start and stop the operating system and server
< Database level
Properly start and stop the database
Perform a backup of the database
R/3 runs on more than five different versions of UNIX. In many cases, significant
differences exist between these versions. These differences contributed to our decision not
to go into detail at the operating system level.
8pecial Definitions
There are terms used in this guidebook that have very specific meanings. To prevent confusion, they are
defined below:
Application server
This is where R/3 application runs. On a 2 tiered system, this would be combined with the
database server. Application servers can be dedicated to online users, batch processing or a
mix.
Database server
This is where the R/3 and the database resides. The system clock of the database server is
the master clock for the R/3 system.
nstance
An installation of R/3 on a server. Many instances (central, and dialog) make up a system.
More than one instance could exist on a physical server.
8ystem
The complete R/3 installation for a System ID (SID), for example PRD. This logically
consists of the R/3 central instance and dialog instances for that SID. This physically
consists of the database server and application servers for that SID.
Chapter 1: Prerequisites and General Information
Special Definitions
System Administration Made Easy
15
Three-tiered R/3 Configuration
Layers Physical Devices R/3 Instances What Runs on Each Layer
Presentation Desktop PC
many
N/A SAPgui
Application Application Server
none many
Dialog R/3
Database Database Server
- only one
Central Database
Oracle, SQL Server, DB2, Informix,
ADABAS
A two-tiered configuration combines the Application and Database layers on a single server.
8ystem
For an ongoing productive environment, we assume that R/3 is completely and properly
installed and the infrastructure set up and functional. The following checklist will help you
determine if your system is set up to the baseline assumptions of this book. If you can log on
to your system, most of these tasks have already been completed.
Hardware
< Is the server installed?
< Is the backup equipment installed and tested?
nfrastructure
< Is the Online Service System connection established and tested?
< Is the Uninterruptible Power Supply (UPS) installed?
< Is the network configured and tested?
< Is a master time server (clock) available?
< Is a server or system monitor available?
8oftware
< Is the operating system installed?
< Is the database installed?
< Are the following utility software installed (as appropriate)?
Backup program
FTP client
Hardware monitors
Job scheduler
System monitors
Time sync
UPS control
Chapter 1: Prerequisites and General Information
Who Is an R/3 System Administrator?
Relese 4.0B
16
< R/3 System
Is R/3 installed according to SAPs recommendation?
Is the kernel upgraded?
Are hot packs installed to bring you current (as of the installation date)?
Is the TPPARAM file configured?
Is the TMS/CTS configured?
Is the SAProuter configured?
Is the OSS1 transaction configured?
Is the ABAP workbench configured?
Has initial security been configured (default passwords changed)?
< Can users log on to R/3 from their desktops?
Desktop
For optimal results, we recommend that the minimum screen resolution be set as follows:
< For the users 800 600
< For the system administrator 1024 768
Who s an R/3 8ystem Administrator?
Depending on the size of the company and available resources, R/3 administrator(s) may
range from one person to several dozen specialized people in several departments.
Factors that affect an R/3 system administrators tasks, staffing, and roles:
< Size of the company
< Available resources (the size of the Basis group)
< Availability of infrastructure support for:
Desktop support
Database
Network
Facilities
Roles of an R/3 8ystem Administrator
The R/3 system administrator may wear many hats both within or directly related to R/3
and indirectly or external to R/3.
Within R/3
< User administrator
Set up and maintain user accounts
< Security administrator
Create and maintain SAP security profiles
Chapter 1: Prerequisites and General Information
Who Is an R/3 System Administrator?
System Administration Made Easy
17
Monitor and manage security access and violations
< System administrator
Maintain the health of the system
Monitor system performance and logs
< Transport administrator
Transport changes from one system to another
Manage change requests
< Batch scheduler
Create and manage the scheduling of batch jobs
< Backup operator
Schedule, run, and monitor backup jobs of the SAP database and any required
operating system level files
< Disaster recovery technical manager
Create, test, and execute the SAP disaster recovery plan
< Programmer
Apply Online Service System note fixes to programs
< Data Dictionary (DDIC) manager
Change the Data Dictionary (when applicable)
< Data Base Administrator (DBA)
External to R/3
< DBA for the specific database on which the system is running
Manage database specific tasks
Maintain the databases health and integrity
< Operating system administrator
Manage the operating system access and user IDs
Manage operating system specific tasks
< Network administrator
Manage network access and user IDs
Manage network support and maintenance
< Server administrator
Manage the servers
< Desktop support
Supports the users desktop PC
< Facilities
Manages facilities-related support issues, such as:
Power/utilities
Air conditioning (cooling)
Physical server access
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
Relese 4.0B
18
Requirements of an R/3 8ystem Administrator
An R/3 system administrator should:
< Have a proper attitude
Protect and safeguard the system.
The system administrator is the guardian of the system.
Know when to call for help.
The ability to know when you need to get help is a strength.
The weakness is not knowing when to get help and getting into trouble.
Be willing to work the hours required to support the system
Certain tasks must be done after hours or on weekends to avoid disrupting normal
business operations.
< Be technically competent.
When necessary, the company must invest in training for the Basis staff.
You must also take responsibility for your own training and education, whether
your company pays for it or not.
< Be a team-player.
The system administrator will have to work with various functional groups, users,
the IS staff, and others to successfully complete the necessary tasks.
R/3 8ystem Guidelines
When working on an R/3 System, remember to:
< Protect the system
< Ask for help
< Network with other customers and consultants
< Keep it short and simple (KISS)
< Maintain proper documentation
< Use checklists
< Use the appropriate tool for the job
< Perform preventive maintenance
< Not change what you do not have to
< Not make changes to the system during critical periods
< Not allow direct database access
< Keep all non-SAP activity off the SAP servers
< Minimize single points of failure
< Keep Murphys Law in mind
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
System Administration Made Easy
19
Protect the 8ystem
What
Everything you do as a system administrator should be focused on protecting and
maintaining the systems integrity.
Why
< If the systems integrity is compromised, the data in the system could be altered and
people could be making incorrect decisions based on invalid data.
< If the system cannot be recovered after a disaster, your company could be out of
business.
How
< The system administrator must have a positive, professional attitude.
If the system administrator has less than this, critical tasks may not be properly
completed (for example, backups may not be taken as scheduled and backup logs may
not be checked, thus putting at risk a successful recovery of the system in the event of a
disaster).
< System administrators should maintain a my job is on the line attitude.
This attitude helps to ensure that administrators focus on maintaining the integrity of
the system. The company may not survive if the system crashes and cannot be
recovered.
< The system must be protected from both internal and external sources.
One problem today is employees poking around in the network.
Do Not Be Afraid to Ask for Help
Why
< R/3 is so large and complex that no one person can be expected to know everything.
If you are unsure which task to complete or how to complete it, you could make a
mistake and cause a larger problem.
< Mistakes within the system can be very expensive.
Certain things cannot be undone, and once set, are set forever.
< The only way to learn is to ask.
There are no dumb questionsonly dumb reasons for not asking them.
How
< Online Service System notes
< Various Internet web sites and news groups
< Consultants
See also the section in this chapter on networking with other customers and consultants.
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
Relese 4.0B
110
Keep t 8hort and 8imple {K88}
Why
< Complex tasks are more likely to fail, especially as situations change.
A process with 27 steps has 27 chances to fail.
< Complex tasks are difficult to create, debug, and maintain.
< It is difficult to train people for complex tasks.
< If you have to explain a complex task to someone over the telephone, it is likely that
what is said will not be properly understood and an error will be made. If the error is
severe, you may have a disaster on your hands.
How
Keep tasks as simple as possible.
Keep Proper Documentation
What
Document processes, procedures, hardware changes, configuration changes, checks
performed, problems, errors, and so on. If in doubt about what to document, write it all
down.
Why
< As time passes, you will forget the details of a process or problem.
At some point in time, you may not remember anything about the process or problem.
Taken to an extreme, which happens with short-term memory, you can forget the
information in minutes.
< If you violate the KISS principle, then complete documentation becomes even more
important.
< If the process is complex, complete documentation reduces the chance of errors.
< If you are sick or otherwise unavailable, someone else may have to do the job.
< If it becomes necessary to undo the changes you have made, you will know exactly
what needs to be undone.
< Documentation helps train new people.
Turnover is a fact in every company, and you must plan for it. Proper documentation
makes the training and transition of new employees easier and faster.
When
< When documented items change, or when something changes which will affect your
documentation, you must update it.
Inaccurate documentation could be dangerous because it describes a process that should
not be followed.
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
System Administration Made Easy
111
< When changes are made to the system.
< When problems occur (this includes hardware failures, error log entries, and security
violations).
Hot projects or emergencies tend to take precedence over writing documentation. Do
not postpone writing documentation, or the task may never get done. Record everything
that is done to the systemas it is being done.
How
< Record everything done to the system, as it is being done, so details are not
forgotten.
< Document items clearly and sufficiently enough so that, without assistance, a
qualified person can read what you have written and perform the task.
< Re-read older documentation to see where you need to improve it. Obvious items
get fuzzy over time and are no longer obvious.
< Use graphics, flowcharts, and screenshots to clarify documentation.
Where
< Keep a log (notebook) on each server, and record everything that you do on the
servers.
< Keep a log for everything done remotely to any of the servers.
< Keep a diary/log for other related items.
Use Checklists
What
A checklist lists the steps required to complete a task. Each step requires the
acknowledgement of completion (a check) or an entry (date, time, size, and so on).
Why
< Checklists enforce a standardized process and reduce the chance that you will
overlook critical steps (for example, if you were to use a checklist every time you drive a
car, then you would remember to turn off your headlights when you park your car).
< Checklists force you to document events, such as run times, which may later become
important.
When
Checklists are especially useful for tasks that are:
< Complex or critical
If a step is missed or done incorrectly, the result could be serious (for example, inability
to restore the database.
< Done for the first time
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
Relese 4.0B
112
< Done infrequently
It is very difficult to remember how to do a complicated task that you do only once a
year.
How
See examples in Scheduled Tasks.
Use the Appropriate Tool for the Job
Sometimes a low-tech solution is the best. Depending on the situation, a paper-and-pencil
solution may work better and be more cost effective than a computerized solution. And,
paper and pencil still work during a power failure.
Perform Preventive Maintenance
What
Preventive maintenance is the proactive monitoring and maintenance of the system.
Why
< It is less disruptive and stressful if you can plan a convenient time to do a task,
rather than have it develop into an emergency situation.
< Fix a potential problem before it negatively impacts the system and company
operations.
An extreme situation is that the entire system is down until a particular task is
completed (for example, if the Oracle archive redo log file space goes down to zero (0),
the database will stop, and then R/3 stops too. Until sufficient file space is cleared out,
R/3 will not run. When this happens, certain business operations, such as shipping, may
stop).
When
< Checking for problems should be a part of your regular routine.
< The scheduling of tasks to fix a problem should be based on your situation, and
when least disruptive to your users.
How
< Monitor the various logs and event monitors
< Obtain additional disk storage before you run out of room
< Regularly clean the tape drive(s)
< Check the database for consistency and integrity
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
System Administration Made Easy
113
Do Not Change What You Do Not Have To
What
< If the system works, leave it alone.
< Do not change something just to upgrade to the latest version.
Why
< Risk
When something changes, there is a chance that something else may break.
< Cost
Upgrading is expensive in terms of time, resources, cost, consulting, and so on.
< When to Change
A business need exists.
Legal requirements call for an update.
This really is not an option. If you do not keep up you will be out of compliance with
legal requirements. Penalties associated with this could be very expensive.
If the hardware or software release is no longer supported by the vendor.
The new release offers a specific functionality that offers added business value to
your company.
Fixing a problem requires an upgrade.
A fix is unavailable in a patch or an advance release.
Patches are available to solve known problems.
How
< If the change fails or causes problems, make certain you can recover to a before-the-
change condition.
< All changes must be regression tested to make sure that nothing else has been
impacted by the change. In other words, everything still works as it is supposed to.
Regression testing of R/3 involves the functional team and users.
< Stage the change and test it on the:
Test system (a Sandbox system)
Development system
Quality Assurance system
Production system
By the time you reach the production system, you should be comfortable that nothing
will break.
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
Relese 4.0B
114
Do Not Make 8ystem Changes During Critical Periods
What
A critical period is when system disruptions could cause severe operational problems.
Why
If a problem occurs during a critical period, there may be a severe impact to the business.
For example, a system administrator changes a printer in Shipping at the end of the month.
If R/3 cannot send output to the new printer, then the users cannot print shipping
documents and the company cannot ship their products.
End resultrevenue for the month is reduced.
When
A critical period is any time where the users and the company may be severely impacted
by a system problem. These periods differ depending on the particular industry or
company. What is a critical period for one company may not be critical for another
company.
The following are real examples of critical periods:
At end of the month, when Sales and Shipping are booking and shipping as much as
they can to maximize revenue for the month
At the beginning of the month, when Finance is closing the prior month
During the last month of the year, when Sales and Shipping are booking and
shipping as much as they can to maximize the revenue for the year
During the beginning of the year, when Finance is closing the books for the prior
year and getting ready for the financial audit
How
Always coordinate potentially disruptive system events with the users.
Different user groups in the company, such as Finance and Order Entry, will have
different quiet periods that will need to be coordinated.
Plan all potentially disruptive systems-related activities during quiet periods when a
problem will have minimal user impact.
Do Not Allow Direct Access to the Database
What
Direct access to the database is allowing a user to run a query/update directly against the
database without going through R/3.
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
System Administration Made Easy
115
Why
< By not going through R/3, there is the risk of corrupting the database.
< Directly updating the database could put the database out of sync with the R/3
buffers.
How
< When R/3 writes to the database, it could be writing to many different tables. If a
user writes directly to the tables, missing a single table may corrupt the database by
putting the tables out of sync with each other.
< With direct database access, a user could accidentally execute an update or delete,
rather than a read.
Keep all Non-8AP Activity Off the R/3 8ervers
What
< Do not allow users to directly access (telnet, remote access, etc.) the R/3 server(s).
< Do not use the R/3 server as a general file server.
< Do not run programs that are not directly related to R/3 on an R/3 server.
Why
< Security
Not allowing users to have access to the R/3 server reduces the chance of files being
accidentally deleted or changed.
< Performance
Using the production R/3 sever as a file server creates resource contention, where
performance is a primary concern. Programs running on the R/3 servers will contend
for the same resources that R/3 is using, which affects the performance of R/3.
How
Use other servers to perform functions not related to R/3.
Minimize 8ingle Points of Failure
What
A single-point failure is when the failure of a single component, task, or activity causes
the system to fail, or creates a critical event.
Why
Each single-point failure increases the chances of a system failure or other critical event or
condition. For example:
< If you have only one tape drive, and it fails,
then you cannot back up your database.
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
Relese 4.0B
116
< If you rely on utility line power, and do not have a UPS,
then the server will crash during a power failure, possibly corrupting the database.
< If you are the only one who can complete a task, and you go on vacation,
then the task will not be completed until you return or you will be on call while on
vacation.
To guard against single-point failure, consider the following options:
< Redundant equipment, such as dual power supplies
< On-hand spares
< Systems configured with a built-in backup, or a redundant process
< Sufficient personnel
< Cross-training
< On-call consultants
< Outsourcing
Network with Other Customers and Consultants
What
Get to know R/3 Basis and system administrators in other companies.
Why
< Other customers may be able to provide solutions to your problems.
< Customers who help each other reduce their consulting expenses.
< The more people you know, the better your chances of finding someone to help you
solve a problem.
When, Where, and How
When you have the opportunity, meet:
< Other SAP customers and consultants, especially those in your specialty area
< Others using your operating system or database
Where to network:
< Training classes
< SAP functions
Technical Education Conference (TechEd)
SAPPHIRE
< Participate in user groups:
Americas SAP Users Group (ASUG)
Regional SAP users groups
Database user groups, such as those for Oracle, Microsoft SQL Server, Informix, or
DB2
Operating system user groups, such as those for Unix (the various versions), NT, or
IBM (AIX, AS400 or OS390)
Chapter 1: Prerequisites and General Information
R/3 System Guidelines
System Administration Made Easy
117
< Participate in professional organizations.
Participation means getting involved in the organization. The more you participate, the
more people you meet and get to know.
Whenever you attend an event, carry a stack of business cards.
Set the goal of handing out and collecting at least ten business cards.
Do not forget to ask the old-timers. Decades ago, the mainframe community may have
solved many of the issues and problems you now face.
Corollaries to Murphys Law
Murphys Law states: Whatever can go wrong will go wrong.
The following are some corollaries to Murphys Law:
< Without telling you, someone will change something in the infrastructure and crash
the system.
< Upgrades to fix a problem will break something else.
< When the power fails, you find out that the battery in your UPS is dead.
< If you have only one tape drive, it will fail.
< The one thing that you did not test is where the problem is.
< Someone will need a network jumper cable, and will remove it from your server.
< When disaster strikes, you will be out of town or unavailable .
< Disaster will strike at the worst time.
< Problems always happen at 2:00 AM
< Problems come in clusters.
< The latest full backup tape will be bad.
< The one time you did not check the backup log will be the time when the backup
fails.
< You will need a tape from the backup that failed.
< The computer room will be destroyedalong with all your backup tapes.
< What you did not write down, and forgot, is what you need to know.
< User transparent, is not.
< The Peter Principle will strike. (Peter Principle states: In a hierarchy every employee
tends to rise to his level of incompetence.)
< A shortcut is the longest distance between two points.
< When you need to send an alpha page, a link in the e-mail system will fail.
< When a disaster strikes, and you need to be found, you will be out of the pager or
cell phone coverage area.
Chapter 1: Prerequisites and General Information
Types of Tasks
Relese 4.0B
118
< When a disaster strikes, and you need to be contacted, the battery in your pager will
be dead.
Types of Tasks
Regularly 8cheduled Tasks
Chapters 48
This section lists regularly scheduled tasks that the system administrator should complete:
< Daily
< Weekly
< Monthly
< Quarterly
< Annually
Depending on your company and your companys situation, some of these tasks may be
done more or less frequently than suggested. You and your Basis consultant should review
the schedule together to make the necessary adjustments, additions, and deletions for your
environment.
Those of you with Ready-to-Run-R/3 systems will find this section similar to your Online
System Administration Assistant, transaction SSAA (or Tools Administration, then Monitor
System Administration Assistant).
8ample Checklists
The checklists are organized in the following order:
< Critical tasks (daily only)
< R/3 tasks
< Database tasks
< Operating system tasks
< Other
For your convenience, we have provided these checklists in Microsoft Word 97 and Word
95 file formats on the CD inside the back cover of this guidebook. You should tailor these
checklists to your companys environment. Operating system and database-specific items
that do not apply should be removed where appropriate. For example, if you are running
Oracle on NT, you should remove entries that are specific to Oracle on UNIX and MS-SQL
Server. If you have other tasks that should be completed, modify the appropriate checklist
to include them.
< When you use a checklist, indicate the:
System (DEV, PRD, or QAS)
Date
Administrator who completed the checklist
Chapter 1: Prerequisites and General Information
Types of Tasks
System Administration Made Easy
119
< Each task should document:
Completion of the task
Entry of relevant or applicable data (for example, size, number, users, and so on)
A detailed description of any problems
The entire error message should be written down, because there can sometimes be
several similar messages.
< File the completed checklist in a binder, first by system (DEV, QAS, PRD), and then
by date.
Nonscheduled Tasks
Chapters 914
There are additional tasks that a system administrator must perform. These tasks are
completed on an as needed basis.
Nonscheduled tasks are divided into the following major categories:
< User administration
< System administration
< Special maintenance
< Task management
< Remote services
User Administration
The following is a list of nonscheduled tasks for user administration:
< New user setup
< Maintain a user
< Reset a password
< Lock or unlock a user
< Maintain a table of prohibited passwords
8ystem Administration
The following is a list of nonscheduled system administration tasks:
< Create a system message
< Start or stop the system
< Create and schedule a batch job
< Transport objects
Chapter 1: Prerequisites and General Information
Types of Tasks
Relese 4.0B
120
Maintenance
The following is a list of important nonscheduled maintenance tasks:
< Changing system profile parameters
< Applying hot packages or legal change patches
< Upgrading the kernel
< Production refresh strategies (refreshing system[s] from the production system)
< Client copy (create, copy, and delete)
Task Management
Task management is the tracking and management of:
< Online Service System notes that are applied to your system
< Transporting objects from system to system
Remote 8ervices
Remote services deals with utilizing SAP services remotely (Online Service System and
SAPSERV4) and the EarlyWatch system check function.