SAP Basis Basics

I. Welcome to SAP!

SAP was started by three IBM employees in 1972, and… blah, blah, blah… you can find this sort of information on the
internet, in books and other publications, in SAP published documentation, etc. This paper does not contain
information which can be easily harvested from the internet but information from over a dozen years of SAP
implementations. Nor does it contain information to the other SAP implementation team – the functional team. It is
their role to have meetings, ask questions, create spreadsheets, and all the other tripe that makes them look really
busy and valuable.

No, this paper is aimed at the technical side of the team – the Basis people – and takes a lighter view of things in the
hopes that your already frazzled mind can stop screaming “Panic! Panic! Panic!” for at least a few minutes. You are
on the fringe of joining the Brother-and-Sisterhood of SAP Basis Professionals. Of course, even that is now a
misnomer since Basis is no longer called Basis – you won’t even find it in the SAP Glossary at http://help.sap.com
anymore. But we still do the same things. So let’s start off by defining the Basis role: anything having to do with the
IT or technical part of SAP falls under the heading of Basis. There are sub-Basis roles that might require specialist like
Portals people, CRM middleware people, etc. but they still fall into the category of Basis.

There is a old story about a project manager addressing his Basis staff: “People – let’s solidify the role of the Basis
team. It goes like this: anything I don’t understand about SAP is Basis.” Sadly, on some projects, this is close to
being true.

What does Basis mean? I don’t know how the phrase was coined, but Basis functionality can be labeled the “non-
flavored” base of any SAP instance which we will talk about in a minute. Up until version 6.10, Basis was the only
term for the “whatever” that was this base. As of 6.10, Web Application Server – internet connectivity - was added to
this “whatever” layer, so now you will see a few people described as being WAS consultants but it is all Basis. If
someone asks you what is your SAP area of expertise, you say you are a Basis specialist. If you say you are a WAS
specialist, people might just think that English is your 4th or 5th language. And hardcore Basis people will point at you
and laugh.

Besides, wait around a month or two and SAP will call it something different.

While we are on the topic of what to call things, here are the primary rules for SAPese. If taken alone, SAP is not
called sap. It is always called S-A-P. But when joined with other terms, you can call it sap – like SAPGui is sap-
gooey, SAPScript is sap-script, SAPTech is sap-tech, etc. If you call the standalone term SAP sap in front of anyone
who works for SAP, you will get really nasty stares and possibly frantic little black notebook scribbling as your name
and other personal information are logged for future… er, hmmm… use.

II. What is IT’s role in a SAP implementation? What can Your Implementation Consultants do
for Your IT Group?

It often seems that the Basis group does little while the Functional group has all these meetings and has to update all
these spreadsheets and progress reports… but this is not true. The Basis group has limited options when it comes to
configuration – we pick the OS, platform, and database. Once that is decided, we purchase the hardware and install
the software. At least part of this, the install of the first DEV instances, must be done by IT while the Functional
group is still doing Blueprint so that they can use a SAP instance as a reference and demonstration resource.

And while there are some variables in picking the right OS, platform, and database, once it is done it is done and
there is rarely any changing it later. Some of those variables include which combinations have the largest SAP user
base, which get newly released software the soonest, which provide the highest and most stable, which receives the
larget share of SAP R&D resources, which seems to guarantee the longest useful life, which allows the strengths of our
existing staff to be put to the best use, which moves our company in the direction the entire enterprise needs to go?
So you do have to make some decisions.

The good news about this lack of choices on the part of IT is that we don’t have to produce nearly as much
documentation as the Functional group. This document is part of the Basis Information Kit. Our main document
produced using a SAP implmenetation is called the SAP Technical Infrastructure – STI Doc- document and it is a work
in progress all through the SAP implementation. Some parts of it, like the SAP instances to be installed, the clients to
be created, the TMS procedures, etc. can be entered from the start but these procedures may change based on what
works and what does not work for the Basis and Functional groups. Other parts of the document must be completed
later as they deal with server serial numbers, server DNS entries, SAP directory files, etc. Generally, your
implementation partner’s Basis lead will complete as much of the document as possible, and pass it on to the client so
that the addition of new information is a continuing process.

The client Basis group will also receive some SAP publications and other Hitachi produced documents. Besides the STI
Document, they will be provided with a Basis Operations document tailored to your specific OS and database. This
document details approximately 95% of what a Basis person needs to do in order to handle the day-to-day chores of
running a SAP instance. The Basis Operations document will be reviewed jointly by the consultant Basis lead and the
client Basis group. The document you are now reading, Basis Basics, will provide a list of all Basis topics to be
covered during Knowledge Transfer (KT) and daily, weekly, monthly, quarterly, bi-annual, and annual tasks your Basis
group to schedule as appropriate, and an appendix containing practice exercises for the Basis group to do to get a
hands on feel for the SAPGui interface. Some SAP Tutor files, SIMs, may also be provided for use in teaching SAPGui
navigation. Your implementation partner may provide other SIMs and tutorial files as they become available.

Installation guides for all SAP software can be found at http://service.sap.com/instguides. It is a good idea for the
client Basis group to download and distribute copies of the appropriate installation guides and scan through it if for no
other reason that to become familiar with the terms SAP uses to reference IT entities, its software, and the SAP
landscape.

Formal training by SAP is always encouraged, and it another good resource for an introduction on how SAP views the
IT world. The people you meet in these classes may be a valuable asset in the future if you run into problems with
after your implementation partner is no longer enagged. Having your company join ASUG – American SAP Users
Group – is another good people networking tool and can be done at http://www.asug.com.

III. What is a SAP Landscape? What is my role in a SAP implementation?

The SAP Landscape is like a layout of a complex garden – you have areas for roses, and areas for lilacs, and it is all
laid out in proper form. A SAP landscape can range from one SAP instance with one client and one user who does all
the input into the instance via keyboard to dozens of instances with hundreds of clients and thousands of users, with
keyboard input, RFC (Remote Function Calls) and ALE (Automatic Link Exchange) from other SAP instances, links to
external databases, EDI (Electronic Data Interchange) via flat file from banks, vendors, etc., and RF units in the
warehouse. In other words, a SAP landscape can be very simple, or very complex. A bed of petunias, or the Hanging
Gardens of Babylon.

A normal SAP landscape consists of a Development (DEV) instance, a Quality Assurance (QAS) or Test (TST) instance,
and a Production instance (PRD). Some very small implementations will have only a DEV and PRD instance, with the
DEV instance containing a QAS client for testing purposes.

A non-Production SAP server should have 2 (preferably more) processors, at least 4 gig of memory, and at least 100g
of disk space. A Production SAP server should have at least 4 processors, from 4 to 8 gig of memory, and at least
200g of disk space. A hefty server with 6 – 8 processors, 6 – 8 gig of memory, and at lease 200g of disk space can
host two SAP instances. This can be done for DEV and QAS but PRD should never share a server with any other SAP
instance.

The SAP instances form the core of a SAP landscape. The other installed SAP products are peripheral to the SAP
instances.

IV. What is a SAP Instance?

A SAP instance is all the components created by the SAPinst program who all share the same database. There are
three mandatory sub-instances; the Database Instance (DB), the Central Instance (CI), and the Dialog Instance (DI)
aka Application Server. This is the minimum configuration of any SAP instance. There can be multiple DIs but only
one DB and only one Active CI which means that a copy of the CI can exist for High Availability but only one of the CIs
can be active at any given time. You will hear about SAP being multi-tiered and that term is referancing these three
layers. Sometimes you might see “other SAP tiers” like ITS but that really isn’t a separate tier, it used to be an
additional piece of software working with IIS, and now ITS is part of Basis/WAS so it is part of the CI Tier. These
layers, plus other SAP written software, are also known as the SAP Business Framework.

You can probably guess at what the DB contains. There are any number of tables in a SAP instance, from 21,000 to
38,000. Many have four or five character names that are usually abbreviations of things like USR for user, MANDT for
client, etc. You could guess that USR is short for user. But MANDT? So, we add one more variable to the equation –
those four or five character names are abbreviations of German words. Needless to say, trying to look at SAP from a
typical DBA prospective is almost impossible. Fortunately, SAP supplies the tools for you to manage all these tables.
The Central Instance is a lump term for all the SAP executables, the installed OS file structure, and anything that is
placed on the OS to support and communicate with the SAP instance. It “talks” to the database, handles requests
made by the application server(s), and sends back the information. Other software products often call this the
middleware layer.

The Dialog Instance connects the users to the CI, passes the issued requests to the CI, and sends the returned results
to the user’s session. SAP uses a client piece called SAPGui which handles the user-to-DI communication on the
user’s workstation.

These are the three main pieces of a SAP instance installation. There are other parts that can be added for various
sub-access and external tasks. For a Development SAP instance or a Quality & Assurance or Test SAP instance, all
three layers are normally installed on the same server. For a Production SAP instance, the DB/CI are often installed
on one server and the DI on another server for load balancing purposes. It should be noted that the installation of a
CI instance automatically installs a DI which can be used by everyone if needed, be used only as needed by Basis
staff, or never be used.

Instance can be a difficult term to understand – almost every major database applies this term to the installation of
the database software. So if you see reference to an Oracle instance, this means the installation of the Oracle
software. An Oracle database is the creation of a new empty database within that Oracle instance.

Understanding the Startup and Shutdown prodedures may help solidify this layer concept.

The normal SAP instance start up consists of three parts: starting the SAP OS Collector, starting the Oracle Listener,
and starting the SAP instance. The process mainly goes like this: ora<sid> logs on and starts the Oracle Listener then
<sid>adm logs on and runs the startsap script.

What? You say we missed a step? What happened to the SAP OS Collector?

The startsap script takes care of the SAP OS Collector for us. When the SAP Instance starts up via the startsap script,
it checks to see if saposcol is up and running – whether from the root user starting it manually or from another SAP
Instance already starting it up, it doesn’t matter. If saposcol is up and running, the script simply moves on to the
next step. If it is not, the script starts saposcol as root and then proceeds. So the SAP OS Collector gets handled one
way or another.

However, you may need to bring up multiple Oracle Listeners depending on the database configuration. If the MCOD
installation option was used then only one Oracle Listener is used since both databases share one Oracle listening port
which is normally 1527. If, however, two Oracle instances were installed, and each database uses its own unique
Oracle listening port, then multiple listeners must be started. The startup procedure for each SAP Instance would be
exactly the same as if only one SAP Instance resided on the server.

The process to stop the SAP instance is close to being the reverse of the start procedure. <sid>adm stops the SAP
Instance, ora<sid> stops the Oracle Listener, and root stops the SAP OS Collector. The only real difference is that
saposcol is not automatically stopped by the stopsap script – there may be other SAP instances on the server which
means this software needs to stay up and running to gather OS information until that instance comes down.

One thing to note – the Oracle Listener does not start the database, it simply “watches” port 1527 for any database
related activity. The startsap and stopsap scripts handling the startup, mount, opening, and shutdown of the
database. None of this activity could occur if the listener was not “polling” port 1527, relaying the requested database
function, and returning the results through the same port.

The <sid>adm and ora<sid> users are assigned environment variables using the SAP installation run that identify
them as users of a specific Oracle database and SAP instance. So when oraabc starts the lsnrctl program with the
“lsnrctl start” command, oraabc’s environment variables tell the server which database for which the listener is to
“listen”.

V. What are the different kinds of SAP software? What kind of hardware will they need?

Although the most common flavor is SAP is called R/3. This is SAP’s main ERP product that handles Financials,
Controlling, Logistics, Sales, Human Resources, and lots and lots of other ERP stuff. All these modules – that is what
the functional people call them – live in and use common data in one SAP instance. All the modules are installed
during a SAP instance installation. Whether all the modules are implemented is up to the SAP customer.
Each SAP “flavor” must be installed in its own SAP instance. Products such as APO (Advanced Planning &
Optimization), BW (Business Warehouse), CRM (Customer Relationship Management), SRM (Supplier Relationship
Management), SolMan (Solution Manager), and SCM (Supply Chain Management) are all SAP “flavors” installed into
their own instances all of which are pretty much installed the same way – installed with a DB, CI and DI - and the
process is pretty much the same depending on the age of the product. Just like SAP’s product line, its installation
program SAPinst has changed over the years as well.

In addtion, there are add-ons supplied by SAP. Products such as plug-ins for communicating with other SAP
instances; the SAP Learning Solution, Sarbannes-Oxley, Best Practices, etc. can be added to an existing SAP instance.
These add-on products are what the name implies – they “add” more functions and data “on” to an regular SAP
instances.

Some SAP transactions communicate with external software but the functionality is either in the SAP instance or out
on your network or on the internet. SAP transactions like SCOT use built-in communication ports for the use of
sending email from SAP to a SMTP server. Transaction SICF activates business packages for access via the internet.

RFC – Remote Function Calls – can originate in the SAP instance and go out to “talk” to some other product that
knows what to do with the request passed, and information is send back into the SAP instance. And, of course, an
SAP instance can talk to another SAP instance using RFC – for example, this is how the Transpost Management
System moves changed from one instance to another. There are also products written by SAP partners which can be
accessed externally from a SAP instance: products like Vertex which is a Sales Tax database, and BSI which
calculates payroll taxes.

As for hardware, SAP has special “hardware sizing” software on which it trains it’s hardware partners like IBM, HP,
Dell, etc. They have worked together to create templates for very small, small, medium, large, and very large SAP
landscapes. Once you contact the hardware vendor of your choice, they will meet with you to calculate your SAPs – a
unit of measurement SAP uses to estimate workload – decide into which category your company fits. From there it is
pretty much a plug-in the company data and spit out a sizing reports.

Let’s get this out into the open early: a Basis consultant does not do hardware sizing. Normally, they will look at the
sizing report from your hardware vendor and tell you if they think it is too weak or too string. That is about all you
can expect of them – their career could be very short-lived if they say “Hey, they are just trying to get you to
purchase some really expensive boxes that you just don’t need!”. Remember, SAP created the sizing program and
trained this hardware vendor on it and that is what your quotes will be based. Anything critical said about the
proposal could get back to all sorts of people who could more or less hurt you in certain circles. I’m not talking about
punching you out or stalking you. More along the lines of every problem message you open with SAP gets its priority
bumped down to like a -5.

Also, we recommend that you get hardware estimates from more than one hardware vendor. Even if you mentally
are locked into an IBM box running AIX and Oracle, it doesn’t hurt to see what the other platforms are selling for.
And it doesn’t hurt if rumor gets back to IBM that you are talking to Dell. Playing hardware vendors against one
another can lead to some hefty discounts given by a vendor who doesn’t want to see a sale walk out the door.

You can get a head start on the hardware sizing process by reading the documents available at
http://service.sap.com/sizing. If nothing else, you can impress your hardware vendor by sprouting out all these SAP
terms like SAPs and High Availability and SANs.

Besides servers for your database and SAP instances, you might need other servers for your SAP landscape depending
on the complexity of your SAP implementation. At the very least, you will need an additional not-too-hefty server for
a Solution Manager instance which is what SAP is now requiring as the “tunnel” to get into your SAP landscape; you’ll
need a small server having a public IP address and located in your DMZ for your OSS connection. More about this
later.

And there may be a need for Portals servers, UME server, a SAPConsole server… the list goes on and on. As stated
earlier, a SAP landscape can be very simple or very complex.

Remote installation on your SAP servers can make the installation task simpler – it is always more comfortable to do
the work from your own workstation than having to sit in a cold, noisy computer room. The Basis group of Hitachi
recommends Terminal Services – aka Remote Desktop – for this work. PCAnywhere and products such as Tight VNC
do not possess the stability of Terminal Services.

VI. How does SAP get installed?

First, it must be noted that only the SAP company is allowed to KT (Knowledge Transfer) installation information.
Clients may watch all they wish during installation, and are encouraged to install and delete sandbox instances on a
spare server rather than let it gather dust. But installation is not part of your purchased Technical Knowledge
Transfer package.

Without getting into the little details, here is what gets done during the typical SAP install – the work that gets done
after the hardware has been installed into the network and DNS:

1. Make all server configuration adjustments as specified in the SAP installation guide.
2. Download and install JDK 1.4x – you can use JRE 1.4.x if you aren’t going to use the ABAP add-on.
3. Install the database software.
4. Patch the database software.
5. Run SAPinst to install the CI and default DI instances.
6. Run SAPinst to install the DB instance.
7. Run SAPinst to install any additional DI instances.
8. Download and install the most current SAP kernel.
9. Current the TMS for the SAP instance.
10. Download and apply all outstanding SAP patches.
11. Request and apply the permanent license key.
12. Do remaining post-installation work such as connecting SAP Online Help, creating clients, adding users,
etc.

Normally the post installation work takes 2 - 4x the amount of time of the actual installation. The installation itself
normally take a one eight hour working day and the post-installation work two eight-hour working days for a total of
three working days to install a SAP instance. This regardless if it is a DEV, QAS, or PRD instance.

VII. Do I have to install JDK 1.4x?

SAPinst – the SAP installation program – needs at least JRE 1.4x in order to run the SAPinst interface when you install
a new SAP instance. But if you intend to add the Java Add-on or Java components after the SAP instance is installed,
you need JDK in order to do so.

VIII. What is a SAP client?

OK, we have the concept of a SAP instance, and that instance has a database which contains thousands of tables
which contain a whole bunch of rows. After SAP is installed, these tables need to have some base data in order for
customization and configuration to begin. Like state abbreviations, country codes, HR titles, etc.

SAP provides a subset of this data so that the Basis team can get in the new instance, add themselves a user ID in
client 000 – “our” client - and start the real work. We don’t want to mess this subset of data up so we need to
populate it to a “work” place for the Functional Team to do their work. Or several work places.

The base SAP instance comes with two clients: 000 and 066. Forget client 066, it is used by SAP when you get close
to GoLive and you want an EarlyWatch report. This is optional and I believe a fee is involved for this service.

All the base or subset data is contained in client 000. Also, client 000 is where the Basis Team does a lot of its
maintenance like patching. The Basis Team people are the only implementation members who will ever have access
to client 000. You can think of client 000 as the owner of all the client independent data in the SAP instance.
Explanation in a minute.

So, in order to let the Functional Team do their own thing without screwing anything up, we create a new client for
them. Think of a client as a view of the database. If you log into client 000, you can see all client independent data –
like the ABAP programs – and all the data that is dependent on client 000 only. If you log into client 100, you see all
client independent data – like the ABAP programs – and all the data that is dependent on client 100. You can’t see
the data that is dependent on client 110 while you are logged on to client 100.

Thus the concept of client dependent and client independent data. All rows in some tables are accessible from any
client like T000, the Data Dictionary tables, tables that contain the ABAP programs, printers, etc. These are said to be
client independent. Data like users, companies, vendors, customers, etc. are client dependent. You have to go into a
specific client in order to see this data.
IX. How do I create a new client?

This is a pretty easy procedure. Basically, you add a new logical system in transaction SALE, create a new client in
transaction SCC4 using the logical system you created previously, create a RFC target destination using transaction
SM59 with the same name of the logical name, create a RFC source using transaction SM59 for the source or “from”
client, log on to the new client, and schedule a client copy from the source client to the destination or “to” client.
That’s all there is do it

When you bring up a new SAP instance, you add a client 100 and schedule a client copy from client 000 to client 100.
This is called a local client copy since the source or “from” client is contained within the same SAP instance as the
target or “to” client. When you add a new SAP instance to your landscape, like QAS, you might want to copy client
100 in the DEV instance to client 200 in the QAS instance. This would be a remote client copy.

A client copy is destructive – in other words, all the data in the target client is deleted during the client copy. So the
procedure is not just for creating new clients but refreshing existing data. The only exception to this rule is the using
the SAP_CUST profile to do the copy – it will leave all the data in the target client intact with the exception of the user
master data which will be deleted and replaced with the source client’s user master data. You can even mix and
match, the data from one client and the user data from another, and copying them both at the same time in the same
client copy run.

A client is created using transaction SCC4 and at the time of creation you must specify what type of client it will be.
Is it to be used to create configuration changes that are to be transported to QAS and PRD? Is it a reference client,
“frozen” so it can be used to refresh the data contained in test clients? Can both client-dependent and client-
independent data be changed in this client, or only client-dependent data, or no changes allowed at all? These
various types of client have their own labels to the SAP implementation team: golden client, unit test client,
configuration client, ABAP client, production client, etc. If someone references a client with which you are not
familiar, be sure to ask for clarification so that the wrong client does not end up being the source client for a client
copy!

X. What is this permanent key stuff?

When a SAP instance is first installed, it installs with a temporary license that expires in 4 weeks. You must request a
permanent license key via the SAP Marketplace. More about that later.

XI. How do the users communicate with the SAP instance?

Well, of course, you need to add them to the SAP instance. Then the user has to be able to connect to the application
layer in some from. Normally this is using the SAP supplied program SAPGui which is installed on a user’s
workstation, but here are other ways such as connecting to a Citrix server on which SAP is installed or connecting
from the internet using a SAP product via Portals, ITS, or some other product, or using one of the SAGUi alternatives
like SAPGui for Java.

SAP uses some common ports no matter where it has been installed. The first instance installed on a server is labeled
as System Number 00. It would use ports 3600 for the Dispatcher, 3300 for the Gateway, and 3600 for the Message
Server. If you had a second SAP instance installed on the same SAP server, it would normally use the next available
number in the port range. So SAP instance #2 would be System Number 01, use port 3601 for the Dispatcher, 3301
for the Gateway, and 3601 for the Message Server. As long as a user can access these ports from his workstation, he
can log on via the SAPGui installed on his workstation.

XII. How do I limit what my users can do when they log on to a SAP instance?

SAP user security is done via roles. A role is basically a group of transactions, authorizations, and authorization
objects bundled together for use by a group of users with common functional needs. This group definition is saved
and generates a profile which is attached to the SAP user who needs it.

People often get intimidated by SAP security – there are thousands of transactions, authorizations, and objects. It
helps to think of all this is simplistic terms.

Let’s say you have a user who needs access to one transaction in the SAP instance. All he needs to do it log on, go to
transaction SPAD, and print a list of available printers. That is his whole job, to create this printer list once a day. So
he needs the authorizations that allow him to log on to SAP, to go to the SPAD transaction, and to print the list to any
available printer. He has * to all printers. He basically needs a role containing the transaction he is allowed to do,
SPAD, and the authorization object S_SPO_DEV set to all because he can see and print to any printer.

Then let’s says a new check printer gets added to SAP, and we don’t want the user to be able to print his printer list to
the new check printer. So we change authorization object S_SPO_DEV to a list containing authorizations for the
printers to which he can print, excluding the check printer. His dropdown list for printers won’t even show the new
printer now. And he will be able to print to any printer in his printer authorizations list.

This is a simplistic example but you can see how it works. SAP security can be very tight or very loose. In general, it
is loose in DEV, using a modification of the SAP_ALL profile – sort of God-like powers and what the Basis people
normally use since it already exists and why make a role that does the very same thing? - to allow every DEV user to
do everything with the exception of Basis tasks. QAS may be a little tighter, or a combination, allowing the user
SAP_ALL during training but limiting the user to his/her PRD role in another client on the last day so he can test the
role he will really use out. In PRD, of course, users should only receive the rights to only what they absolutely need
to do.

XIII. How do I patch a SAP instance? How often should I do it?

There are three different types of a SAP patch: support packages, kernel replacements, and SAP Notes – aka OSS
Notes.

Support packages are used to make ABAP code and functionality changes. ABAP is the language in which SAP is
written and it is pronounced AAAA-bop and not AAAAA-bap. Support packages contain a group of ABAP “fixes” that
must be installed via transaction SPAM from within a SAP instance. You apply these “fixes” in a specific order: Basis,
ABA (Application Basis patches – the software that supports the interaction of SAPGui with the SAP instance), APPL
(application functional patches), and then plug-ins, etc. that also exist in the instance because add-ons and stuff have
to be patched too. After you apply support packages to a SAP instance, you need to regenerate all the ABAP loads so
that users don’t have to sit watching Compiling… messages the first time a changed ABAP program is called.

Kernel patches are simply a replacement of the SAP executables on the OS level. This is always done to a new SAP
instance and most likely done following a support package application run.

SAP Notes – or OSS Notes – contain a patch or two to solve an immediate problem. The Basis staff either manually
applies an ABAP code fix or uses the SNOTE transaction in the SAP instance to apply the fixes. There are times,
however, when the note contains instructions that must be done manually – in other words, things must be done that
SNOTE cannot do. Eventually, as the SAP Note corrections become more and more, SAP will group them together and
release a new support package so that they can be applied en masse and not one-by-one.

In order to download any of these patches, you must log in and download them from the SAP Marketplace at
http://service.sap.com/patches. And you must have a valid OSS ID – aka SAP Front-end User ID or “s” number –
with the rights to access the patches webpage.

Other products, such as J2EE, are patched via a combination of deployment of packages and replacement of OS
executables.

In general, you should schedule your support package maintenance often enough to prevent shell-shock to users due
to massive changes in the SAPGui screens, and rarely enough that you don’t spend all your time preparing for the
next support package application window. Often, patch application is driven by an identified problem that can be fixed
via a support package referenced by SAP.

Just make sure to get a list of all the packages that will be applied, and use the SAP Notes Side-Effects tool off the
SAP Support Packages in Detail site at http://service.sap.com/patches to get a list of everything that is changed
during patching for your Functional team leads.

XIV. What are all these numbers? “s” number, license number, etc.

When you become a new SAP customer, SAP assigns you a customer number. This number is like any other
customer number you assign your own customers, or that companies assign to you. It uniquely identifies your
company to SAP.

Once you sign your software license, each of the SAP components you purchase is assign an installation number.
So, you signed a mySAP.com Business Suite license? Then you will be assigned an installation number for R/3,
another installation number for BW, another installation number for CRM, etc. You also signed a license for KW? That
would be another installation number. SAP sometimes splits existing products out to other divisions, so you may even
be assigned a second customer number with new installation numbers assigned under that number. SAP did that
with Enterprise Portals. An installation number identifies a customer's SAP component. If you open a problem under
your R/3 installation number, SAP knows that the problem is going to deal with R/3 and not CRM, BW, etc.

A few weeks later, SAP shipped your installation kits and you installed R/3. Four weeks later your users get a
message saying that the license has expired. But you signed your license agreement! When an SAP instance is
installed, it gets assigned a temporary license key that is good for approximately four weeks. You need to request a
permanent license key as soon as you finish your installation of the SAP instance. How? First, you will need your
hardware key. This identifies your operating system information so SAP can generate a key that is not only good for
your SAP version but for your hardware as well. To see your hardware key, log on as <sid>adm and go to a
command prompt. Type "saplicense -get" and your hardware key will be displayed. Jot it down, you will need it later.
The hardware key for NT is different than, for example, the hardware key for AIX. So if you change your SAP license
from AIX to NT, you will need to make sure that your company is attached to the new hardware key or you won't be
able to request new permanent license keys.

To request your new permanent license key, go to http://service.sap.com/licensekey. Use this website to give SAP
information on which SAP flavor your have installed. You will have to provide your hardware key as well. SAP will
generate the new key and e-mail you a text file. Save the text file on your SAP server, log on as <sid>adm, and go
to a command prompt. Type "saplicense -install ifile=<path and name of txt file from SAP>". Your key should be
installed! In later versions of R/3, you can use the SLICENSE transaction as well.

Now your system is flying! But your ABAPers sign on for the first time, and they need to add a new program to
upload master data. When they enter se38 they get a message asking for their developer key. This key is
generated by SAP as well, and is used to register your super users who will be responsible for adding new code and
changing SAP-owned code. Go to http://service.sap.com/sscr to register your programmers. Once you have the
developer key, give it to your ABAPer and he can enter it into the system. He will only have to supply it once per SAP
instance.

Now your ABAPers are cranking out code, your system is humming, and then! Pow! The dreaded short dump hits you
when you aren't looking. You look up the error code and find a valid OSS note to fix the problem. You log on to apply
the advance correction, your give yourself a developer key, go to transaction se37, but a new popup won't go away, it
keeps asking for an access key for R3TR FUGR XXXXXXXXXXXXXXXXX. You must get an object key in order to
modify an SAP-owned object. Since SAP owns all the ABAP code that comes with the SAP instance, you have to get a
key in order to apply the advance correction. Again, you would use http://service.sap.com/sscr, this time to generate
an object key.

All this SAP website access also demands that you have an OSS User ID, or as it is now known, SAP Service
Marketplace User ID or “S” Number. The user ID to perform the tasks outlined in this message must have
administration rights. You should have received your primary OSS ID when you got your SAP license. If you have not
received a primary OSS ID, or your SAP reseller seems to have control of your primary OSS ID, contact SAP AG to
resolve the problem. Your OSS ID is connected to your SAP customer number, so if you have two customer
numbers, you will receive two OSS IDs. Make sure to limit the powers of any subsequent OSS ID’s generated by the
Basis group. More on this later.

SAP has recently complicated the license scenario by introducing user licenses. Do not confuse your software license
keys with SAP licensing of the usage of named users. These are two different things! Usage by users of an SAP
instance will be monitored by your auditing team, and normally the only function of the Basis group in this regard is
using su01 to register the "type" of each user.

Now there is only one other really important number you need to know: the phone number for your Basis technical
consultant!

XV. How do I add users? Do I have to add them all to each client one-by-one?

You use transaction SU01 to add and change users. If you want to copy the users from client 100 to the users in
client 110, you can do a special kind of client copy that is non-destructive. When the profile SAP_USER is used during
a client copy, just the user master data is copied from the source client over the target client, and the rest of the
database is left intact.

No matter how you manage your user security, there is no getting around the fact that you have to manually add
them all to at least client at some time or another. The best way is to add them all to client 100 in DEV since that is
the “Golden” client and should never be “refreshed” or written over by a client copy. Once you have them all in one
spot, you can use a client copy for just user master data and pop all the clients wherever you want them.

There is another way to add users to clients called Central User Administration (CUA). CUA allows you to designate
one client in the SAP landscape that is the parent of all or specified clients, both local and remote. When you add a
new user to the parent client, the child clients get populated with this data. Thus, one user add will trigger others
within the instance and to other SAP instances as well. This technique should only be used on clients that are not to
be refreshed in the future.

XVI. Do I have to add printers to each client too?

No, printers are client independent data. Once you add a printer using the SPAD transaction in an instance, it is
available to all clients in that instance.

XVII. So what does the Functional Team do in their own little client(s)?

They do configuration and customization. Think of configuration equal to you going into Outlook on your workstation
and changing things in your Tools -> Options. You change your Calendar Default Reminder to 5 minutes instead of
the default 15 minutes. Now, multiple that by about 1000x and you have an idea of what configuration entails. This
configuration covers tax rules, country codes, company codes, sales regions, sales areas, sales pipeline, all that stuff
technical people really don’t want to know.

Customization is changes made to SAP-owned objects when configuration does not have an option for what you need
to do. For example, SAP comes with several canned Sales Invoice documents. If none of them contain a format you
can use, your Functional Team will work with an ABAP consultant to create a new Sales Invoice document that better
suits your company’s needs.

Depending on the configuration and customization changes made, the SAP instance may force you to register these
changes in the form of transport. The implementation will try to group all these changes into transports that contain
all the work done for a project or a unit of work so that they can be moved to QAS and later PRD easily.

The TMS (Transport Management System) is used to move these transports between SAP instances. Movement of
these changes between clients in the DEV instance can be done by the functional people using SCC1. What goes on in
the DEV instance mostly never is important to Basis. Once the changes need to go to QAS, the Basis team takes over
and uses TMS to move them for the functional team.

TMS movement can be very loose or very tight. Some shops simply release a transport and then send email to the
Basis group asking them to move the transport into QAS, and later into PRD during off hours. This is called manual
TMS control.

Some companies schedule jobs to move any transport found in the QAS queue to QAS at a set time once or twice a
day. The transport is also moved into the PRD queue where is stays awaiting approval. Once the transport has been
tested in QAS and is ready for PRD, the project supervisor and/or system administrator uses a transaction to OK the
change import into PRD which releases the transport in the PRD queue which gets imported into PRD during the next
scheduled PRD TMS job run. The method is automatic and requires little intervention by the Basis Team.

Most companies use some combination of these methods. There are several variations such as moving changes to
client groups in DEV the same time the change is imported into QAS, and importing the change into multiple clients
across the landscape.

The TMS tool is used by the SPAM and SAINT transactions in order to manage the support packages waiting to be
applied which is why it is one of the first post-installation steps that must be done in a new installation. All the SAP
instances of a particular flavor share a transport directory which is normally owned by the DEV instance since it is the
first instance installed. Different SAP flavors need their own SAP transport directory, meaning all CRM instances share
a TMS, all BW instances share a TMS, etc. Very few transports can safely be cross-instance applied since not only the
SAP flavor should be the same but the Basis version as well.

ABAP programmers are “special”. No only do they create new ABAP programs, they sometimes have to change
existing ABAP program. These programs are SAP-owned so things can get a little sticky. Whether adding a new
program or changing an old one, every programmer need a developer’s key that we previously discussed. This will be
fine for new programs, programs that should either begin with “Y” or “Z”. So if you hear someone reference Z
programs, you know what they are talking about, it is a general term to refer to all “home-grown” SAP programs and
include not only the programs whose names begin with the letter “Z” but the ones that being with “Y” as well.

SAP doesn’t like programmers just going in and changing ABAP code that it “owns”. And remember, ABAP programs
are client independent, so if a bug gets into a program from a change made by a programmer in client 120, it affects
client 000, 100, 110, etc., all clients share one version of the ABAP programmer. As a form of security and to allow
better tracking of SAP-owned objects, a key must be generated at http://service.sap.com/sscr - SAP Software Change
Registration – that is unique to the object about to be changed. Only the Basis group can do this, programmers
cannot request SSCR key on their own, or that is the way your Basis group should make it work. Basis has control
over the other “S” numbers generated against your SAP license, and you have to have a “S” number with
administration rights in order to generate a Developer’s Key or an Object Key. So, genereally, when adding a new “S”
number for a non-Basis group person, allow note searching and any message to SAP options “on”, and everything else
“off”.

XVIII. What factors affect SAP Performance?

Like every other complex piece of software, performance in a SAP instance depends on many factors. So you often
have to play detective to find the core of your problem.

The most common complaint is when a SAP instance is cycled – meaning stopped and restarted. As we touched on
earlier, a SAP instance is comprised of millions of lines of ABAP code which are generated into load objects. When a
SAP instance is stopped and restarted, all data and program information is flushed from SAP’s internal buffers. So
every time a new SAP program needs to run after being cycled, the needed program has to be read and then placed in
the program buffers for use. Not only that, if the ABAP code for that program has been changed or the load object
invalidated in any way – like a kernel replacement that added new functionality, etc - the program must FIRST be
recompiled and then loaded into the buffer. The next time the program is called, it will execute faster since its load
object is already out there in the buffer. The most commonly used programs in a SAP instance number in the
thousands, so as the day goes by, SAP response time goes faster since getting a “hit” in the buffer for a certain
program happens more and more often. But there might come a time when some of these “fast” program have to be
switched out of the buffer because their date/timestamp is the oldest of all the programs in the buffer, and the buffer
is full. Buffer swapping can slow a SAP instance down.

Another factor that often causes a slow down or even a hanging SAP instance is failure to “dump” the database log.
This occurs more often in Oracle instances since a MS SQL Server database will just keep growing until there is no
more room on the hard drive, which is something rather easy to spot. Many people fail to process the ReDo files
created by an Oracle database by backing them up to tape and informing BRBACKUP that they have been processed,
and they just keep accumulating until there is no place else to put them. This can cause the database to hang which
causes the SAP instance to hang. For a DEV or QAS instance, most DBAs turn “off” log archiving. On PRD instances
where a backup should occur nightly, a task can be scheduled to delete all ReDo files older than 2 or 3 days as long as
the archive files are backed up when the rest of the SAP instance is backed up. Another common problem with Oracle
is if the logging and automatic archiving are turned “off”. Both should be never both be off to prevent the archiver
from getting “stuck”.

It is possible for someone or something to get into an infinite loop and just keep eating up your CPU. Transaction
SM50 shows you what is running at any given moment. Almost every process shown in SM50 has a corresponding
process on the server side. You can use the process ID in SM50 to investigate the corresponding tasks on the server.
You can normally use SM50 to cancel any “hung” processes but sometimes you have to go to the OS level and cancel
the process there.

Server space is not just critical on the hard disk where the logs are created. Any shortage of hard disk space on a
SAP server should be corrected at once. SAP is like any other software; it uses TEMP space, and generates other type
logs, like job logs and print logs. You want to make sure there is plenty of space available on all your SAP server
drives.

Index rebuilds and statistics jobs should be scheduled on all your SAP instances on a monthly basis. This will keep
your database tuned and efficient. Any time you do a mass program regen using transaction SGEN, you should
schedule a statistics run on the database as well.

Every SAP instance contains three profiles that let us tune and adjust various parameters such as buffer size, default
client, number of processes, etc. Rarely will you touch two of these, the DEFAULT.PFL and
START_DVEBMGS00_<server>. The third, <SID>_DVEBMGS00_<server>, you will probably spend the rest of your
SAP career changing. Erroneously changing one of these profiles is common reason why a SAP instance that was
working perfectly in the past won’t come up now. That is why even though you make your changes to the profile
using transaction RZ10, once you activate it, it gets written as a flat file out on your instance server. So if a
parameter change causes your SAP to fail during startup, you can undo the changes with VI on UNIX or notepad on
Windows.

XIX. What the heck is all that DVEBMGS00 crap?

Up to now, we have discussed that a SAP instance contains three components; the DB, CI, and DI instances. But
what do I SEE on the OS level when my SAP instance is up and running? The answer to this is complex, and you
aren’t even close to being able to understand it all, so we will just present the big picture for now.

Besides having your database software running, and any shadow processes it might spawn, your SAP instance creates
many processes when it successfully comes up. It may be configured to start at least one of every type of process
SAP uses during the average day, or it may be a more specialized SAP instance that just handles user communication,
leaving the more muscular work for the CI elsewhere. But every SAP instance will have at least 1 work process kicked
off when it starts.

The types of work processes are as follows:

Type Description Process Instance Parameter

Dialog Process user requests in foreground dw.sap<SID>_<DVEBM> rdisp/wp_no_dia

Update Server uses to process mission critical updates also dw.sap<SID>_<DVEBM> rdisp/wp_no_vb
Update2 Server uses to process less critical updates also dw.sap<SID>_<DVEBM> rdisp/wp_no_vb2
Enqueue Used for lock management also dw.sap<SID>_<DVEBM> rdisp/wp_no_enq
Batch Process jobs in the background also dw.sap<SID>_<DVEBM> rdisp/wp_no_btc
Message Message server ms.sap<SID>_<DVEBM> N/A
Gateway Gateway server gwrd N/A
Spool Used for spool management also dw.sap<SID>_<DVEBM> rdisp/wp_no_spo

So, given that the German word for update starts with a V, the standard SAP instance that is the first instance on a
server – i.e. System Number 00 – you get DVEBMGS00. So I can tell just by looking at the
\usr\sap\<SID>\DVEBMGS00 directory on the OS level that this is a full SAP instance – it has all the parts. A SAP
instance can only have 1 message server, so we know this is the main directory for the instance. When a DI is
optionally installed, the name is normally in the form of D<System Number> since it is subservient to the main SAP
instance.

Just looking at the processes running on a server, you can pretty much tell if your SAP instance came up sucessfully
or not. First, the message server comes up, and then the gateway/dispatcher starts and connects to the message
server. And finally, the disp+work work threads for the dialogs, batch, and update processes start, the enqueue and
spooling specific ones first. One depends on the other, the dw’s can’t start unless the gateway/dispatcher is up which
can’t start unless the message server has come up successfully. The reverse is true during instance shutdown, first
the dw’s go then the gateway/dispatcher, and finally the message server shutdown will always be the last thing in
your log when you stop your SAP instance, it isn’t down until that messsage shows in the log.

XX. And this <SID> thing?

SID stands for System Identifier or something pretty similar. Each SAP instance must have a three
character code that is unique on any given server, and should be unique within any given SAP landscape.
That is where DEV, QAS, TST, and PRD came from. Anytime you see a reference to <SID>, it takes the
place of the SAP instance’s system identifier in upper case, <sid> is the same in lower case.

DEV, QAS, TST, and PRD used to be good enough to handle your entire landscape. But with new SAP
flavors and their instances came the need to modify this slightly. Different implementations do things
differently but they should implement a plan that can grow as their landscape grows. Generally, we use
the first 2 characters to designate the SAP flavor, and the last the part of SAP instance. So the R/3
instances would be R3D, R3Q, R3T, R3P, and maybe even a R3S installed at some point or another as a
Sandbox. The same for CRM – CRD, CRQ, CRT, and CRP. I think you probably get it now.

When a SAP instance is installed, its directory structure will look like this:

usr ->
 sap ->
<SID> ->
DVEBMGS00 ->
data
exe
igs * IGS executables
log * Audit and Trace logs
sec * Used with SSO
work * Logs instance operational files
SYS ->
exe ->
run * SAP Instance Executables
gen
global
profile * SAP Instance Profiles
sec
trans ->
EPS ->
in * Storage for support packages
out
bin * Store common TMS configuration
buffer * Stores the instance TMS queues
cofiles * Header files for transports
data * Data files for transports
etc
log * Logs TMS operational files
sapnames * User names of users using TMS
tmp * TMS Temporary storage

So from this chart, we can see that the TMS files are stored in /usr/sap/trans, the instance profiles in
/usr/sap/<SID>/SYS/profile, our instance logs and work file in /usr/sap/<SID>/DVEBMGS00/work, and our SAP
executables in \usr\sap\<SID>\SYS\exe\run. If we had a DI instance attached to this instance, there would be a
/usr/sap/<SID>/D01 directory as well. DEV’s profile directory would be called /usr/sap/DEV/SYS/profile… and on and
on and on. This is universal regardless of the operating system used – the “/” just become “\”.

When a SAP installation runs successfully, two aliases are created – sapmnt and sapalloc. They are both point to the
same thing - \usr\sap. So you could also access the trans directory by using /sapmnt/trans.

It is important to remember that SID and System Number are two different things. One is the System Identifier – the
three character label for the instance – and one is the System Number – more or less the instances order of
installation on the server. Most instance System Numbers will be 00 but more and more products are coming out to
interfere with this numbering scheme. For example, if during post-installation work you install the Java Add-on, this
will create an instance 01 (or whatever the highest system number is + 1) although it is not a ABAP SAP instance, it is
a Java SAP instance. If you go to install a second SAP instance of this same server, the System Number for this new
instance would default to 02. You can manually override this if you wish, and can use any system number up to 98 as
long as it is not already in use. Don’t use 99 either since SAP uses that one for OSS connection.

XXI. Where on the OS level can I look for help with SAP related problems?

Your /usr/sap/<SID>/DVEBMGS00/work directory can sometimes be your best friend. If anything bad happens when
you start your SAP instance, it will be recorded here, usually in the dev_rfcx, dev_ms, dev_wx, and stderrx files.
Those x’s stand for numbers because several of them can be created at any given time. Anything with the word
*old* in it is from the previous Sap startup and you can ignore those files.

If a SAP instance does not come up, go to the work directory, sort the files descending by date/timestamp with “ls -
ltr” for descending or “ls –lt” for ascending, and start opening files to searching for problems. 99 times out of 100 you
will find more information regarding the problem

XXII. And if I don’t find my problem in the work directory or don’t understand what the error
message is telling me?

SAP supplies tools to help you help yourself. Write down or cut-and-paste (if your message is from a SAPGui screen,
using CTRL+Y and CTRL+C can do this) any error messages, and then go to http://service.sap.com/notes. You have
to use that “S” number we talked about earlier to log on here. Once you are in, you will see SAP Notes – aka OSS
Notes - search screen that allows you to paste or key search criteria. Start broad and narrow your search scope until
you think you might have an idea as to your problem. But make sure that the SAP release for the note matches your
SAP release or the note is probably worthless to you.

Can’t find anything in SAP Notes to help you? You can go to http://service.sap.com/message and open a problem
directly with SAP. A few warnings about doing this – don’t set the priority of your message to Highest unless this is a
PRD instance that is down. SAP gets cranky about that – I would leave the priority at Medium unless you are dealing
with a real show stopper. Also, expect to wait a day or two for a non-PRD problem. And make sure that you have a
working OSS connection so that SAP can log into your SAP landscape – more about this in the next section. Be sure
to provide other information like OS vendor, release and SP level, database vendor, release and SP, kernel patch
level, support package levels, etc. so that SAP doesn’t have to ask or dig the information out.

You might get faster results by tapping the knowledge of your fellow SAPer’s on one of the more popular SAP
websites. SAP Fans, SAP Genie, and SAP Super Users have forums where you can post your problem, and SAP Super
Users contains Knowledge Repositories where you can pilfer hints, tricks, and techniques without going through the
pain of figuring something complex out yourself. And turnaround can be within minutes if you get lucky and someone
out there is really bored or an insomiac.

XXIII. A working OSS whatie?

As you have probably figured out by now, the technical part of the SAP company was once called OSS or SAPNet.
Then it was changed to SAP Frontend Support. And now all this is folded into the SAP Marketplace. Here is where
you can download software and patches, add new “S” numbers, get your permanent license keys, register ABAP
developers, send messages to SAP, and just about anything SAP related you will ever need to do. The old way of
communication to SAP was using transaction OSS1 which went out, knocked on SAP’s door, and allowed you in with
the proper user ID and password. This was called an OSS – stands for Online SAP Support or something close. OSS1
will no longer be in use as of April, 2006, and all its functionality has been replaced by the SAP Marketplace at
http://service.sap.com. But you still see tons of OSS references within SAP Notes so just get use to dealing with
multiple terms for the same thing which is a norm for SAP.

In the past, a new SAP client was looking at installing a X.25 or Frame Relay connection in order to have a direct
connect to the SAP servers, and you normally had to go through a 3rd party to get this work and its configuration
done. Now, it is a simple matter of obtaining a public IP address, setting up a server in your DMZ, installing a SAP
product called saprouter, and setting the permissions table. However, this seems to be one of the implementation
tasks that every client keeps putting off until there is a major problem on some sort, and SAP needs to get into your
landscape, and you have no OSS connection up and running. So the importance of getting your Remote Connection
Data Sheet completed and FAXed to SAP cannot be over stated. It really isn’t hard to fill out, and it should only take
about half an hour at most. In return, SAP will FAX you the information you need to complete your setup to one of
the SAP servers – there are different ones supporting different OSS configurations and different parts of the world.

Get it done early and keep a monkey the size of King Kong off your back when you hit a problem.

XXIV. Why do we need a Solution Manager instance? What does it do?

Once you get your OSS link to SAP up and running, SAP support can be used via transaction OSS1 until
April 2006. At that point, all SAP support activates must be done either via the SAP Marketplace or via
new functionality of your Solution Manager instance.

Think of a Solution Manager as the hub of your SAP landscape. It contains information about your SAP
instances – called satellite systems. This information includes the instance patch levels, clients, add-ons,
etc. It does this via Remote Function Calls (RFC) we talked about earlier from the Solution Manager
instance to the satellite instances. And SolMan gathers this information on a scheduled basis to keep it
fresh.

As of April when SAP needs to get into one of your instances, you will open a connection for them in the
SolMan instance, and they will use SolMan to connect to the instance with the problem. Instead of having
to write down all the pertinent information about the instance having problems, all the information SAP
needs like patch level, kernel version, etc. will be easily displayed by SAP by the SolMan instance. Your
OSS connection will be added and configured via SolMan.
Opening a service connection will use a different procedure than the previous method as well. First, the
LOP program needs to be run on the box hosting saprouter, and a Service Connector Setup Program
needs to be run on a workstation holding a SAPGui so that OSS1 can sorta still work the way it used to,
and a whole lot of other things we haven’t done yet and have to research in order to explain it to you.
Just keep in mind, the whole process is going through a major change and when we understand, we will
pass the knowledge on.

Solution Manager does a whole slew of other functions as well including customer service and help desk
tasks. Since you have to have it by April 2006, you may as well include it as part of your SAP landscape
now.

XXV. Basis Knowledge Transfer

Hitachi will teach you as much as possible about Basis but stops short of breaking a SAP instance to show
you how to fix it. If something occurs that was not presented in your KT, your Basis group should have
been given the necessary tools to find a solution on their own. Taking responsibility for ownership for
your new the SAP instances is a hard step to take but the most valuable KT Hitachi provides is to show
you where to look when you don’t know the asnwers.

Besides using the provided documentation, opening messages to SAP, and posting your situation on a SAP
website, you have full access to the SAP Online Documentation library at http://help.sap.com. This site
contains online documentation for all of SAP products and can be a valuable information resource.

The following is a list of topics your Hitachi Basis consultant will cover during KT:

ABAP Workbench:
□ how to add/change/delete/run a program
□ how to add/change/delete/run a function
□ how to create/change/delete/use a variant
□ how to make changes to a table structure
□ how to browse the data in a table

Client Administration:
□ how to add/copy/delete a client
□ how to “lock” and “unlock” a client

Connectivity:
□ how to add/change/delete RFC destinations
□ how to add/change/delete Logon Groups

Instance Monitoring:
□ how to what work processes are in use
□ how to perform a Tuning Summary (ST02) session
□ how to monitor all table and update locks
□ how to change the number of work processes available
□ how to increase the number of batch processes after hours
□ how to troubleshoot performance
□ how to view application log data
□ how to view all errors occurring in a specific work process number
□ how to monitor Internet Communication
Jobs:
□ how to create a new background job
□ how to see the status of a background job

Maintenance:
□ how to apply support packages
□ how to apply kernel replacements
□ how to schedule database maintenance jobs
□ how to apply a SAP note using SNOTE
□ how to add/change/delete system parameters using RZ10
□ how to mass regenerate all or selected SAP ABAP loads
□ how to add/change/delete Logical System Names

Miscellaneous:
□ how to send a system-wide message
□ how to lock a transaction
□ how to change the time zone
□ how to change the SAP logo on the main screen
□ how to configure SAP Online Documentation
□ how to add/change/delete a message on the logon screen
□ how to track the problem causing a short dump
□ how to stop a run-away process
□ how to configure/monitor email going out of SAP
□ how to view the SAP file structure on the OS from SAP

Non-Instance Software
□ how to start, test, and stop saprouter
□ how to log on and off the J2EE Visual Administrator
□ how to confirm that J2EE is up and running on a server
□ how to start, test, and stop the IGS instance
□ how to start, test, and stop the J2EE instance

SAP Marketplace Functions:

□ how to apply for and install a permanent license key
□ how to generate a developer’s key
□ how to generate a SAP System Change Registration key
□ how to open the SAP landscape for access by SAP
□ how to download patches from SAP Marketplace
□ how to download new software CD images from SAP Marketplace

Security:
□ how add/change/delete a role
□ how to add/change/delete/display a user audit trail
□ how to view a user’s security errors

Spool related:
□ how to add/change/delete a printer
□ how to reset the cache for a printer
□ how to reprint and reroute print
 □ how to reorganize and reclaim TemSe objects
□ how to keep the job log clean

Start up and shutdown:

□ how to start and stop a SAP instance
□ how to start and stop a SAP-related database
□ how to know a SAP instance is up and running
□ troubleshooting SAP instance start up and shut down
□ how to start, test, and stop HTTP communication

TMS:
□ how to add/change/delete a TMS setup
□ how to release/transport a transport request
□ how to lock a transport queue

Troubleshooting:
□ how to view errors in the system log
□ how to search SAP notes for issues
□ how to open/check/close a problem message with SAP

User related:
□ how to add/change/delete a user
□ how to do mass user changes
□ how to see open user sessions
□ how to add/change/delete a SAP Marketplace user ID and password

XXVI. Basis tasks to be done on a regular schedule

Daily Tasks:

□ Check that the SAP System(s) is up

□ Check that daily backups executed without errors
□ Check that all application servers are up
□ Check the CCMS alert monitor (if applicable) (RZ20)
□ Check work processes (SM50)
□ Look for any failed updates (update terminates) (SM13)
□ Check System Log (SM50)
□ Review for cancelled and critical jobs (SM37)
□ Check for “old” locks (SM12)
□ Check users on system (SM04)
□ Check for spool problems (SP01)
□ Check job log (SM35)
□ Review and resolve dumps (ST22)
□ Review workload statistics (ST03)
□ Review buffer statistics (ST02)
□ Review error log for problems (AL02 & ST04)
□ Review UNIX system logs for problems (AL16)
□ Review Windows system logs for problems (OS06)
□ Check the uninterruptible power supply (UPS)

Weekly Tasks:
 □ Check database for free space (DB02)
□ Monitor database growth (DB02)
□ Check spool for problems and that spool is properly cleared (SP01)
□ Verify all properly approved transports imported into PRD (STMS)
□ For Oracle, run a check database and a update statistics job (DB13)
□ For MSSQL, run a check database integrity mainenance job and a update statistics
maintenance
□ Check file system for adequate space (RZ20 - Technical Operations Templates ->
Space Management)
□ Review space usage and that sufficient free space exists in the file systems
□ Check system monitoring systems for update
□ System monitor Review for any events that should be added or deleted
□ Check system monitor alert mechanisms
□ System monitor Test e-mail
□ Test paging
□ Clean tape drive. Tape drive Clean using cleaning cartridge

Monthly:
□ Defragment the server memory by cycling the SAP instance and rebooting the server.
□ Record database growth usage for plotting growth.
□ Record disk space growth usage for plotting growth.
□ Perform a full server backup.
□ Review disk storage usage on server.
□ Do any server "housecleaning" - old /tmp files, etc.
□ Check consumable resources - tapes, check, data cartridges, preprinted forms, paper, etc.

Quarterly Tasks:

□ Perform quarter-end backups and send tapes to long-term offsite storage.

□ Review user IDs via SUIM for terminates users that should be locked or
delete.
□ Review list of "prohibited" passwords in table USR40.
□ Review system profile parameters for password standards.
□ Review all scheduled jobs via SM37 to determine if they are still appropriate.
□ Test database recvoery Restore database to a test server/
□ Archive all transport files older than 6 months from the /usr/sap/trans
directory.
□ Cleaup all SAPDBA/BRTOOLS files and logs.

XXVII. Can Hitachi recommend any good books to help new Basis people?

Yes, SAP has a branch called SAP Labs which produces a series of books called Made Easy guides. The
SAP Authorizations Made Easy and SAP System Administration Made Easy guides are geared toward the
Basis team members, and can be purchased from Amazon.com. These guides are not released new for
every version of SAP so just order the most current you can find. You can download older, free versions
at SAP Super Users.

The SAP R/3 System Administration for Dummies is a good high-level resource for becoming familiar with
SAP components and terminology but it is hard to find since it is no longer in print. Sometimes a used
copy turns up on Amazon.com if you are lucky.

SAP R/3 Administrator’s Handbook is written by known, reliable author and is the only other book we
purchase whenever a new version is published.

XXVIII. Can Hitachi recommend any SAP courses for new Basis people?
Recommended Basis aka WAS courses are:

ADM100 - SAP Web AS Administration I

ADM102 - SAP Web AS Administration II
ADM505 - Oracle Database Administration I
ADM940 - SAP R/3 Authorization Concept

You might want to throw in one of the introduction courses if you want to start with a high-level view of
SAP.

The availability of these and other courses can be reviewed at http://service.sap.com/trainingcatalog.

 Appendix A
Commonly Used SAP Basis Transactions

AL02 Database Alert

AL11 View the SAP File Structure on the server
AL16 Local Alert Monitor for Operating System
BD64 Maintenance of Distribution Model
DB02 Database Monitor
DB13 DBA Planning Calendar
DB20 Refresh Database Statistic by Table
OS06 Local Operating System Activity
OSS1 SAPNet Support – OSS Link
PFCG Security Role Maintenance
RZ10 System and Tuning Parameters
RZ11 Profile Parameter Maintenance
SAINT Add-On Installation
SALE Display ALE Customizing
SCC1 Client Copy - Special Selections
SCC3 Client Copy Log
SCC4 Client Administration
SCC5 Delete Client
SCC7 Post-Client Import Methods
SCC8 Client Export
SCC9 Remote Client Copy
SCCL Local Client Copy
SCOT SAPconnect Administration
SCUA Central User Administration
SCUL Central User Administration Log
SCUM Central User Administration
SE03 Tool Transport Organizer Tools
SE06 Set Up Transport Organizer
SE10 Transport and Change Organizer
SE11 Maintain Objects in the SAP Data Dictionary
SE13 Maintain Technical Settings (Tables)
SE14 Utilities for Dictionary Tables
SE16 Data Browser - Browse a Database Table
SE16N Browse a Database Table in Spreadsheet Form
SE30 Transaction Run-Time Analysis
SE37 ABAP Function Editor
SE38 ABAP Program Editor
SE61 R/3 Documentation
SE93 Transaction Authorization Objects
SICF HTTP Service Hierarchy Maintenance
SICK Installation Check
SGEN SAP Load Generator
SLG0 Application Log: Object Maintenance
SLG1 Application Log: Display Logs
SLG2 Application Log: Delete logs
SM01 Lock Transactions
SM02 System Messages
SM04 User Sessions
SM12 Table Locks
SM13 Update Locks
SM19 User Security Audit Maintenance
SM20 Audit Logs
SM21 System Logs
SM30 Call View Maintenance
SM35 Batch Input Monitoring
SM36 Create a Background Job
SM37 Job Maintenance
SM49 Execute external OS commands
SM50 Work Process Overview
SM51 List of SAP Systems
SM59 RFC Maintenance
SM69 Maintain External OS Commands
SMICM Internet Communication Monitor (ICM)
SMLG Maintain Assignment Logon Group to Instance
SMW0 SAP Web Repository
SNOTE SAP Note Assistant
SP01 Spool Output
SP12 Spool Administration
SPAD Output Device Maintenance
SPAM Support Package Application Manager
SR13 Profile Parameter Maintenance
SSAA System Administration Assistant
ST02 Tuning Summary
ST03 Workload Analysis
ST03N Workload Analysis (Graphic)
ST04 DB/2 Performance Monitor
ST05 Trace Requests
ST06 Operating System Monitor
ST22 Short Dump Analysis
STMS Transport Management System
STZAC Global Time Zone Maintenance
SU01 User Maintenance
SU02 Profile Maintenance
SU10 Mass User Change
SU25 Upgrade Tool for Profile Generator
SU3 Maintain User Profile
SU53 Missing User Authorizations
 Appendix B
Available Internet Resources

SAP Marketplace:

Connectors – SAP Connectivity connector information and software downloads.

License Key – Apply for permanent license key for a new SAP instance.
Message – Maintain a SAP message from you to SAP – normally problem reporting.
Product Availability Matrix – SAP Product Availibility Matrix – when products available and out
of maintenance.
Patches – Download SAP software fixes and patches.
Platforms – Platform and Technology Information Center.
Quick Links – A list of SAP Marketplace links.
Remote Connectivity – Information on the connection to the SAP OSS servers.
SAP Notes – Search SAP Notes – OSS Notes – for problem resolution and information.
SAP Online Knowledge Products – SAP Online training materials.
SAP Software Change Registration – SSCR - Generate SAP Software Change Registration keys
– ABAP developer and object keys.
Service Connection for SAP - Open Service Connection so SAP can access your SAP Landscape.
Software Distribution Center – Download license SAP software.
User Administration – Add new SAP Marketplace user IDs aka “S” numbers.

Other SAP-owned websites:

SAP Help Portal – All SAP Online Documentation is located here.

SDN – SAP Developer Network.

Websites:

SAP Database – SAP Database of freely Available Information

SAP Forums – Forums, Documentation, Q & A & Troubleshooting.
SAP Super Users – Forums, documentation, SIMs, and training materials – constantly adding new
materials.
SAP Genie – Forums, papers, webcasts, and resumes – a lot of material but not too organized.
SAP Fans – Forums – fast response for problem postings.
 Appendix C
Practice Exercises

This section is to allow you to get a little feel for what you are going to be doing with the rest of your life.
User accounts have been created for in one of our internal SAP ECC 5.0 instances just in case you don’t
have a DEV instance up at your company yet. It may not be the same SAP flavor or version you will be
using at your site but these exercises are Basis oriented and so pertain to every SAP instance.

Installing the SAPGui 6.40 Program on Your Workstation

If you already have a SAPGui 6.40 installed on your workstation, you can skip to You should. You will
need a SAPGui installation on your computer. If you do not have access to this software, please download
the SAPGui-6.40-Comp-3.zip and gui640_13-10001615.exe files from ftp://65.124.71.74/. The first file
installs the SAPGui and the second file patches it. If you are asked for a user ID and password, use
george for both. Since both of these files are rather large, we recommend the use of a FTP client such as
WS_FTP or CuteFTP be used since you can resume a download if your connection is interrupted. And
make sure to use the download FTP client properly. If your download appears to "hang", let the tool error
you out, don't just manually stop and restart the download - your buffers won't be flushed and this can
create a error in your download file.

Unzip the zipped file and install the SAGui on your computer by executing
\GUI\WINDOWS\WIN32\setup.exe. It does not hurt if you select all the available SAP options during this
install, otherwise let everything default during the installation. Once you have installed the SAPGui,
reboot your workstation if the install does not ask you to do so. Then use the second file, the exe file, to
patch your SAPGui to level 15. There should be nothing to select or decide during the patch installation.
After the patch is successfully applied, it is best if you reboot your workstation one more time.

Configurating SAPGui 6.40 for SAP Access

You should have a SAPGui Logon Pad icon on your desktop. Open this icon, click the Systems tab, and
click on the User-Defined button. Enter the following information and click Add...
After you have successfully configured your SAPGui, use notepad to cut-and-paste these three lines to the
bottom of your \Windows\system32\drivers\etc\services file:

sapdp00 3200/tcp
sapmsERI 3600/tcp
#

The last step is to make sure any firewall software that may intercept your SAP connection is “off”. Now
you should be able to access the SAP instance. Your company has been granted a range of temporary
user IDs in the format of OPUB-TRAIN01 – OPUB-TRAIN05 with a password of init in client 999. Be sure
that your Insert key is set so that you can type your password in properly – you can delete whatever is in
the password field in order to enter your password. These user IDs will be deleted shortly after your
GoLive date but not before just in case you need a reference resource.

Something you should note - this server is not pingable. Only the 3200, 3300, and 3600 ports are open.
So if you are having problems connecting to the SAP instance, open a DOS-window and type:

telnet 63.148.190.26 3600

And press ENTER. If the whole screen goes black and all letters on it disappear, you are reaching the
server. If you get a "Connecting To 63.148.190.26..." message that just sits there, you aren't reaching
the server.

The Exercises

1. Log on to client 999 of the HC ERI instance. You will be asked to change your password the first time
you log on.

2. You are going to add a new user.

a. Go to transaction SU01.
b. Fill in the User as the first five letters of your trainee user ID + NEW + the last letter of
your trainee user ID. Click the Create Icon.
c. On the Address tab just make up name stuff.
d. On the Logon data tab, click the Password Wizard to generate a password.
e. On the Defaults tab, use the dropdown to select English for the Language, set the
OutputDevice as LP01, set the Decimal Notation as 1,234,567.89, the Personal Time
Zone to CST, and the Date Format as MM/DD/YYYY.
f. On the Roles tab, add the role ZBC_NON_BASIS_TEAM. Make sure to press ENTER after
you add the role in order to get the Role Description to pop into the Name field.
g. Click the Save icon.

3. Add a new user group.

a. Go to transaction SUGR.
b. Fill in the User group name as first five letters of your trainee user ID + GROUP + the
last letter of your trainee user ID. Click the Create Icon.
c. On the Maintain User Groups screen, fill in the Text field with a description of the user
group.
d. Enter the User Names for all your fellow trainees, the new user you just created, and
your own user ID. Press ENTER to make the actual user names appear in the User
Assignment section, and then click the Save icon.