Embed Size (px)
Citation preview
IBM
Tivoli
Service
Level
Advisor
Troubleshooting
Version
2.1
SC32-1249-00
���
First
Edition
(September
2004)
This
edition
applies
to
Version
2.1
of
IBM
Tivoli
Service
Level
Advisor
(program
number
5724–C40)
and
to
all
subsequent
releases
and
modifications
until
otherwise
indicated
in
new
editions.
©
Copyright
International
Business
Machines
Corporation
2002,
2004.
All
rights
reserved.
US
Government
Users
Restricted
Rights
–
Use,
duplication
or
disclosure
restricted
by
GSA
ADP
Schedule
Contract
with
IBM
Corp.
Contents
Preface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. v
Who
should
read
this
guide
.
.
.
.
.
.
.
.
. v
Publications
.
.
.
.
.
.
.
.
.
.
.
.
.
. v
IBM
Tivoli
Service
Level
Advisor
library
.
.
.
. v
IBM
DB2
Universal
Database
Enterprise
Edition
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
Tivoli
Data
Warehouse
library
.
.
.
.
.
.
. vii
Warehouse
Enablement
Packs
.
.
.
.
.
.
. vii
IBM
WebSphere
Application
Server
library
.
.
. vii
SLM
Administrative
Console
Information
.
.
. vii
Related
publications
.
.
.
.
.
.
.
.
.
. viii
Accessing
Publications
Online
.
.
.
.
.
.
.
. viii
Ordering
publications
.
.
.
.
.
.
.
.
.
. viii
Accessibility
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Tivoli
technical
training
.
.
.
.
.
.
.
.
.
. ix
Contacting
IBM
Software
Support
.
.
.
.
.
.
. ix
Determine
the
business
impact
of
your
problem
ix
Describe
your
problem
and
gather
background
information
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Submit
your
problem
to
IBM
Software
Support
.
. x
Searching
knowledge
bases
.
.
.
.
.
.
.
. x
Obtaining
fixes
.
.
.
.
.
.
.
.
.
.
.
. xi
Updating
support
information
.
.
.
.
.
.
. xii
Participating
in
newsgroups
.
.
.
.
.
.
.
.
. xii
Conventions
used
in
this
guide
.
.
.
.
.
.
. xiii
Typeface
conventions
.
.
.
.
.
.
.
.
.
. xiii
Operating
system-dependent
variables
and
paths
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Chapter
1.
Message
and
Trace
Logging
1
Handlers
and
Filters
.
.
.
.
.
.
.
.
.
.
.
. 2
Accessing
Log
Files
.
.
.
.
.
.
.
.
.
.
.
. 2
Configuring
Log
Files
.
.
.
.
.
.
.
.
.
.
. 3
Configuring
Log
Files
for
the
SLM
Server
.
.
. 3
Configuring
Log
Files
for
SLM
Reports
and
the
SLM
Administration
Server
.
.
.
.
.
.
.
. 4
Locating
Trace
and
Message
Log
Files
.
.
.
.
.
. 5
Removing
Aged
ffdc
Log
Files
.
.
.
.
.
.
. 7
Relocating
the
Tivoli
Common
Directory
.
.
.
. 7
Log
File
Names
.
.
.
.
.
.
.
.
.
.
.
. 8
Additional
Log
Files
for
SLM
Administration
Server
and
SLM
Reports
.
.
.
.
.
.
.
.
. 10
Viewing
Product
Logs
.
.
.
.
.
.
.
.
.
.
. 10
Message
Logging
.
.
.
.
.
.
.
.
.
.
.
. 10
The
Message
Log
Format
.
.
.
.
.
.
.
.
. 11
Viewing
Product
Messages
.
.
.
.
.
.
.
. 11
Understanding
the
Message
Format
.
.
.
.
. 12
Trace
Logging
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Setting
Tracing
Levels
in
the
SLM
Server
Environment
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Setting
Tracing
Levels
in
SLM
Reports
and
SLM
Administration
Server
Environments
.
.
.
.
. 15
Understanding
the
Trace
Log
Format
.
.
.
.
. 15
Configuring
Filtering
Masks
.
.
.
.
.
.
.
. 16
Audit
Logging
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
.
.
.
.
. 19
Installing
DB2
Universal
Database
.
.
.
.
.
.
. 19
Instance
Creation
Failed
During
DB2
Universal
Database
Installation
on
UNIX
Systems
.
.
.
. 19
Updating
the
JDBC
Level
.
.
.
.
.
.
.
.
.
. 20
Installing
and
Configuring
WebSphere
Application
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 20
Installing
on
Linux
Systems
.
.
.
.
.
.
.
. 20
WebSphere
Administration
Console
Unavailable
after
Installing
on
AIX
Systems
.
.
.
.
.
.
. 20
Errors
while
Enabling
WebSphere
Security
.
.
. 20
Creating
SLM
Databases
.
.
.
.
.
.
.
.
.
. 21
Database
Creation
Fails
.
.
.
.
.
.
.
.
. 21
Recovering
from
Cataloging
a
Local
Database
as
Remote
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 23
Installing
IBM
Tivoli
Service
Level
Advisor
.
.
.
. 23
Blank
Install
Window
or
Incomplete
Text
.
.
. 23
Install
Screen
Fonts
Not
Readable
.
.
.
.
.
. 23
Cleaning
up
Temporary
ISMP
Directories
.
.
. 24
Receive
DYKIN0005E
or
DYKIN0088E
Errors
Connecting
to
SLM
Databases
.
.
.
.
.
.
. 24
Installing
SLM
Reports
or
SLM
Administration
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 24
Installing
with
the
IIS
Service
.
.
.
.
.
.
. 24
Installation
Fails
because
the
Directory
Service
is
not
Started
.
.
.
.
.
.
.
.
.
.
.
.
. 25
Configuring
ODBC
Data
Sources
.
.
.
.
.
.
. 25
Verifying
Successful
ODBC
Data
Source
Creation
25
Installing
and
Configuring
the
Registration
and
Process
ETLs
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Logging
in
to
the
Data
Warehouse
Center
.
.
. 26
Incorrect
level
of
db2java.zip
.
.
.
.
.
.
. 26
Could
not
execute/locate
DB2
command
.
.
. 26
System
Startup
.
.
.
.
.
.
.
.
.
.
.
.
. 27
Server
Hostname
is
Not
Fully
Qualified
.
.
.
. 27
SLM
Server
Startup
Cannot
Connect
to
SLM
Databases
.
.
.
.
.
.
.
.
.
.
.
.
.
. 27
Accessing
SLM
Reports
.
.
.
.
.
.
.
.
.
. 28
HTTP
500
Internal
Server
Error
or
DYKAL3003E
Error
Message
.
.
.
.
.
.
.
.
.
.
.
. 29
Uninstalling
IBM
Tivoli
Service
Level
Advisor
.
.
. 30
Uninstallation
Fails
because
the
Directory
Service
is
Not
Started
.
.
.
.
.
.
.
.
.
.
.
.
. 30
Uninstalling
SLM
Install
Options
.
.
.
.
.
. 30
Manually
Uninstalling
IBM
Tivoli
Service
Level
Advisor
.
.
.
.
.
.
.
.
.
.
.
.
.
. 30
Upgrading
IBM
Tivoli
Service
Level
Advisor
.
.
. 31
Upgrade
of
the
SLM
Server
Fails
.
.
.
.
.
. 31
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
.
.
.
.
.
.
.
. 33
CLI
Service
Commands
.
.
.
.
.
.
.
.
.
. 33
CLI
Client
Interface
Cannot
Establish
a
Connection
to
the
CLI
Service
.
.
.
.
.
.
. 33
©
Copyright
IBM
Corp.
2002,
2004
iii
Server
Hostname
is
Not
Fully-Qualified
.
.
.
. 35
Issuing
scmd
list
Reports
only
rcc,
log,
and
slm
Bundles
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Failure
Attempting
to
Disable
Source
Applications
.
.
.
.
.
.
.
.
.
.
.
.
. 36
Problems
Related
to
SLM
Databases
(Distributed
Platforms)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
Exceeding
Maximum
Application
Connections
.
. 37
Reconnecting
to
the
Tivoli
Data
Warehouse
Database
After
Changing
Logfile
Size
.
.
.
.
. 37
SLM
Administrative
Console
or
SLM
Reports
User
Interface
Unresponsive
.
.
.
.
.
.
.
. 37
Receiving
SQL0289N
While
Executing
a
Database
Operation
.
.
.
.
.
.
.
.
.
.
.
.
.
. 38
Receiving
SQL1224N
When
Attempting
to
Connect
to
SLM
Databases
.
.
.
.
.
.
.
. 39
Receiving
SQL30081N
When
Attempting
to
Connect
to
SLM
Databases
Remotely
.
.
.
.
. 39
Unable
to
Publish
Service
Monitor
Results
.
.
. 41
Optimizing
Performance
on
Data
Collection
.
. 41
Problems
Related
to
Databases
on
z/OS
Systems
.
. 43
Error
SQL0969N
Received:
There
is
no
message
text
corresponding
to
SQL
error
-873
.
.
.
.
. 43
Encoding
Issues
and
Limitations
with
the
DY1
Source
Warehouse
Pack
.
.
.
.
.
.
.
.
. 43
Incorrect
Port
Number
Specified
during
Database
Creation
.
.
.
.
.
.
.
.
.
.
.
.
.
. 43
Error
SQL0913N
Received:
Unsuccessful
execution
caused
by
deadlock
or
timeout
.
.
. 44
Problems
Related
to
the
DB2
Data
Warehouse
Center
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 44
Log
in
Fails:
Unexpected
Communication
Error
44
Login
Fails:
Unable
to
Retrieve
DB2
User
.
.
. 45
Login
Fails:
Database
Specified
Does
Not
Match
45
Warehouse
Services
Missing
from
Control
Server
46
Problems
Related
to
Data
Retrieval
.
.
.
.
.
. 46
Evaluating
Partial
or
Missing
Data
.
.
.
.
. 46
No
Data
in
SLM
Reports
for
a
Specific
SLA
.
. 47
Data
Extracted
From
Warehouse
Late
.
.
.
.
. 52
Updating
an
Evaluation
Based
on
the
Arrival
of
Late
Data
.
.
.
.
.
.
.
.
.
.
.
.
.
. 53
Receiving
Too
Many
DYKME9094
Messages
.
. 53
Problems
Related
to
ETLs
.
.
.
.
.
.
.
.
. 54
SLM
ETL
Step
Failed
.
.
.
.
.
.
.
.
.
. 54
Schedules
Changing
in
Work
In
Progress
Display
54
Recovering
From
SLM
ETL
Failure
.
.
.
.
. 55
Problems
Related
to
the
SLM
Administrative
Console
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 56
User
Sign-On
Fails
.
.
.
.
.
.
.
.
.
.
. 56
Tasks
not
Displayed
in
Portfolio
.
.
.
.
.
. 56
Tivoli
Common
Directory
Logs
Not
Accessible
. 56
Resource
Name
Incorrectly
Specified
When
Renaming
a
Resource
.
.
.
.
.
.
.
.
.
. 57
Object
Description
not
Fully
Displayed
.
.
.
. 57
Display
of
Time
Zone
Offset
is
Incorrect
.
.
.
. 57
Problems
Related
to
the
SLM
Server
.
.
.
.
.
. 57
Out
of
Java
Memory
.
.
.
.
.
.
.
.
.
. 57
Windows
Error
1053
Encountered
During
Start-up
.
.
.
.
.
.
.
.
.
.
.
.
.
. 58
Trend
Tracking
Information
Cleared
when
SLM
Server
is
Stopped
.
.
.
.
.
.
.
.
.
.
. 58
SLM
Server
Appears
Hung
During
Historical
Evaluations
.
.
.
.
.
.
.
.
.
.
.
.
. 59
Problems
Related
to
Creating
Offerings
and
SLAs
59
Evaluation
Frequency
Selection
List
Does
Not
Include
Hourly
Intervals
.
.
.
.
.
.
.
.
. 59
No
Selectable
Resources
in
Create
Offering
Window
.
.
.
.
.
.
.
.
.
.
.
.
.
. 59
No
Measurement
Sources
Available
for
the
Component
Type
.
.
.
.
.
.
.
.
.
.
. 60
Internal
Error
While
Creating
Offering,
SLA,
Customer,
or
Realm
.
.
.
.
.
.
.
.
.
. 61
Error
Message
SQL0911N
Received,
Current
transaction
rolled
back
because
of
deadlock
or
timeout
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 62
Unable
to
Submit
an
SLA
.
.
.
.
.
.
.
.
. 62
Problems
Related
to
Event
Escalation
.
.
.
.
.
. 63
Message
Logged:
DYKME9071I:
Violation
Detected
but
not
Published
.
.
.
.
.
.
.
. 64
Problems
with
Message
Content
.
.
.
. 64
Corrupted
Characters
in
Received
.
.
. 66
Tivoli
Enterprise
Console
Event
Server
Communication
Problems
.
.
.
.
.
.
.
. 66
Error
While
Forwarding
Tivoli
Enterprise
Console
Event
.
.
.
.
.
.
.
.
.
.
.
. 66
Resolving
Additional
Tivoli
Enterprise
Console
Event
Forwarding
Problems
in
Non-English
Locales
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
SNMP
Trap
Notification
Problems
.
.
.
.
.
. 67
Information
in
the
SNMP
Event
is
not
Translated
68
SNMP
Traps
Not
Sent
from
Linux
SLM
Server
. 68
Problems
Related
to
SLM
Reports
.
.
.
.
.
.
. 68
Sign-in
to
SLM
Reports
Unsuccessful
.
.
.
.
. 68
Error
Message
DYKRP0070E,
Page
Not
Found
.
. 69
Understanding
Trend
Lines
on
Graphs
.
.
.
. 69
Graph
Not
Displayed
on
UNIX
.
.
.
.
.
.
. 70
Fonts
on
Graphs
Not
Properly
Displayed
.
.
. 71
No
Results
in
Reports
when
Performing
Hourly
Evaluations
.
.
.
.
.
.
.
.
.
.
.
.
. 71
Handling
Data
Points
That
Are
Not
Valid
.
.
. 71
SLM
Reports
Not
Displayed
in
the
Correct
Time
Zone
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 71
Problems
Related
to
Backup
and
Restore
.
.
.
. 72
No
Backup
in
UNIX
Destination
Directory
.
.
. 72
Receiving
SQL1116N
When
Attempting
to
Connect
to
SLM
Databases
.
.
.
.
.
.
.
. 72
Receiving
SQL1117N
When
Attempting
to
Connect
to
SLM
Databases
.
.
.
.
.
.
.
. 72
Configuring
the
CLI
Service
and
Utilities
.
.
.
. 73
Resetting
the
CLI
Service
Password
.
.
.
.
. 73
Modifying
the
CLI
Port
.
.
.
.
.
.
.
.
. 73
Updating
the
Communication
Port
.
.
.
.
. 74
Problems
Related
to
Commands
and
Utilities
.
.
. 74
SBCS
Characters
Get
Corrupted
in
Command
Line
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 74
Appendix.
Notices
.
.
.
.
.
.
.
.
.
. 77
Trademarks
.
.
.
.
.
.
.
.
.
.
.
.
.
. 79
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 81
iv
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Preface
IBM®
Tivoli®
Service
Level
Advisor
:
Troubleshooting
provides
information
to
help
you
identify
and
resolve
problems
that
might
occur
during
product
installation
and
configuration,
as
well
as
problems
that
might
occur
during
normal
use
of
the
product.
Message
and
trace
logging
functions
are
also
described,
to
assist
you
in
identifying
the
root
causes
of
problems
and
resolving
them
quickly.
Who
should
read
this
guide
This
document
is
written
for
systems
administrators
and
Tivoli
Professional
Services
personnel
who
install,
configure,
and
integrate
IBM
Tivoli
Service
Level
Advisor
and
its
supporting
applications
in
the
enterprise
environment,
and
use
IBM
Tivoli
Service
Level
Advisor
for
creating
and
managing
service
level
agreements.
You
should
be
familiar
with
planning,
installing,
and
configuring
distributed
systems
management
software,
and
be
somewhat
familiar
with
the
business
objectives
associated
with
the
IBM
service
level
management
solution.
You
should
also
have
a
working
knowledge
of
IBM
DB2®
Universal
Database™
Enterprise
Edition,
in
the
areas
of
installing
and
configuring
DB2
servers
and
clients,
creating
multiple
instances
of
DB2
Universal
Database,
cataloging
databases,
and
performing
backup
and
restore
operations
to
protect
your
database
resources.
You
should
also
be
familiar
with
the
following
information:
v
HTML
concepts
for
customizing
Java™
Server
Pages
(JSP
files)
to
generate
Web-based
reports
v
Supported
Tivoli
applications
that
are
enabled
for
putting
data
into
the
Tivoli
Data
Warehouse
(see
the
IBM
Tivoli
Service
Level
Advisor
Release
Notes
for
information
on
supported
Tivoli
applications)
v
Data
warehouse
information
and
design,
extract,
transform,
and
load
(ETL)
processes
v
IBM
WebSphere®
Application
Server,
in
the
areas
of
installing,
configuring,
and
starting
the
Application
Server
and
WebSphere
Administrative
Console
v
The
z/OS®
environment,
if
you
plan
to
create
and
maintain
SLM
databases
on
a
z/OS
system
Publications
This
section
lists
publications
in
the
IBM
Tivoli
Service
Level
Advisor
library
and
other
related
documents.
It
also
describes
how
to
access
Tivoli
publications
online,
and
how
to
order
Tivoli
publications.
IBM
Tivoli
Service
Level
Advisor
library
Product
information
for
using
IBM
Tivoli
Service
Level
Advisor
is
found
in
the
/tsladocs
directory
on
the
IBM
Tivoli
Service
Level
Advisor
Documentation
CD,
in
and
HTML
formats.
Inserting
the
Documentation
CD
into
a
machine
using
the
Windows®
operating
system
automatically
launches
the
Tivoli
Software
Information
Center,
from
which
you
can
access
any
of
the
available
documentation
in
softcopy
form.
©
Copyright
IBM
Corp.
2002,
2004
v
The
following
documents
are
available
in
the
IBM
Tivoli
Service
Level
Advisor
library:
v
A
″Read
Me
First″
document
that
provides
a
starting
point
to
help
you
become
oriented
with
the
set
of
IBM
products
that
support
the
overall
SLM
solution,
and
some
quick
instructions
on
what
documentation
to
refer
to
as
you
begin
your
installation
of
IBM
Tivoli
Service
Level
Advisor
and
its
supporting
applications.
v
Release
Notes,
SC09-7777
This
document
provides
late-breaking
information,
such
as
problems
and
workarounds,
and
patch
availability.
v
Getting
Started,
SC32-0834
This
document
introduces
you
to
IBM
Tivoli
Service
Level
Advisor
and
provides
information
about
planning,
installing,
and
configuring
IBM
Tivoli
Service
Level
Advisor
to
run
in
your
Tivoli
enterprise
environment.
v
Managing
Service
Level
Agreements,
SC32-1247
This
document
provides
information
about
creating
and
managing
schedules,
offerings,
customers,
and
realms,
and
associating
these
elements
with
selected
resources
in
your
enterprise
environment
to
develop
service
level
agreements
(SLAs)
between
your
organization
and
customers
who
depend
on
your
enterprise
for
agreed
upon
levels
of
service.
This
document
is
designed
to
be
used
by
administrators,
service
offering
specialists,
and
service
level
agreement
specialists
who
are
responsible
for
creating
and
managing
SLAs.
v
SLM
Reports,
SC32-1248
This
document
provides
information
about
generating
and
viewing
Web-based
SLM
reports
for
IBM
Tivoli
Service
Level
Advisor,
based
on
the
evaluation
and
trend
analysis
results
of
the
data
that
is
extracted
from
the
Tivoli
Data
Warehouse
database.
Additional
information
is
provided
so
that
you
or
your
customer
can
integrate
SLM
reports
into
the
customer
Web
site,
including
examples
of
how
you
can
customize
various
display
features.
v
Administrator’s
Guide,
SC32-0835
This
document
provides
information
about
the
administrative
tasks
you
can
perform
using
IBM
Tivoli
Service
Level
Advisor
to
configure
your
SLM
environment,
and
perform
various
administrative
functions
that
support
IBM
Tivoli
Service
Level
Advisor,
such
as
backup
and
restoration
operations,
and
user
definition
and
authorization.
v
Command
Reference,
SC32-0833
This
document
provides
information
on
command
line
interface
(CLI)
commands
available
for
displaying
certain
conditions
and
states
inside
IBM
Tivoli
Service
Level
Advisor,
and
for
performing
various
configuration
tasks
using
the
scmd
command.
Additional
utilities
that
provide
other
specific
functions
are
also
described.
v
Messages,
SC32-1250
This
document
provides
information
on
messages
that
might
be
displayed
while
using
the
IBM
Tivoli
Service
Level
Advisor
product.
It
provides
additional
explanations
for
messages
and
instructions
on
what
to
do
to
recover
from
errors.
v
Troubleshooting,
SC32-1249
This
document
provides
information
on
resolving
problems
that
you
might
encounter
during
installation
and
configuration,
as
well
as
resolving
administrative
problems
that
might
arise
during
typical
operation
of
the
product.
Information
about
message
and
trace
logging
is
also
provided.
v
Online
user
assistance
for
IBM
Tivoli
Service
Level
Advisor
vi
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
The
online
user
assistance
provides
integrated
online
help
topics
for
all
IBM
Tivoli
Service
Level
Advisor
administrative
tasks
that
are
performed
using
the
SLM
Administrative
Console.
Online
user
assistance
is
displayed
in
the
Task
Assistant
portion
of
the
SLM
Administrative
Console.
Specific
information
about
performing
IBM
Tivoli
Service
Level
Advisor
tasks
is
documented
only
in
this
online
user
assistance.
When
new
products
are
installed
that
run
in
the
SLM
Administrative
Console,
corresponding
online
help
topics
are
also
installed
and
integrated
into
the
existing
information
base.
In
addition,
refer
to
the
following
IBM
Tivoli
Service
Level
Advisor
Web
site
for
support
information
and
software
updates
on
IBM
Tivoli
Service
Level
Advisor
and
supported
warehouse
packs
and
downloadable
interim
fix
software:
www.ibm.com/software/sysmgmt/products/support/IBMTivoliServiceLevelAdvisor.html
IBM
DB2
Universal
Database
Enterprise
Edition
library
The
publications
required
to
support
IBM
DB2
Universal
Database
Enterprise
Edition
are
available
on
the
IBM
DB2
Universal
Database
Enterprise
Edition
CD,
or
from
this
IBM
Web
site:
http://www.ibm.com/software/data/db2/udb
Tivoli
Data
Warehouse
library
IBM
Tivoli
Service
Level
Advisor
requires
Tivoli
Data
Warehouse
to
be
installed
in
your
enterprise,
to
serve
as
the
data
repository
for
Tivoli
performance
and
availability
monitoring
applications
that
provide
data
for
service
level
management.
See
the
following
documentation
on
the
Tivoli
Data
Warehouse
Documentation
CD
included
with
IBM
Tivoli
Service
Level
Advisor:
v
Installing
and
Configuring
Tivoli
Data
Warehouse
v
Enabling
an
Application
for
Tivoli
Data
Warehouse
v
Tivoli
Data
Warehouse
Release
Notes
Warehouse
Enablement
Packs
Warehouse
enablement
packs
(also
referred
to
as
warehouse
packs)
are
the
interfaces
that
load
and
transform
data
collected
by
source
applications
into
Tivoli
Data
Warehouse,
and
from
Tivoli
Data
Warehouse
to
other
target
applications
that
use
the
data
to
generate
reports
and
perform
analyses.
Refer
to
the
Release
Notes
for
IBM
Tivoli
Service
Level
Advisor
for
the
online
location
of
the
latest
warehouse
pack
information.
IBM
WebSphere
Application
Server
library
IBM
Tivoli
Service
Level
Advisor
uses
IBM
WebSphere
Application
Server
as
the
basis
for
the
SLM
Administration
Server
and
SLM
Reports
functions.
Getting
Started
provides
introductory
information
on
installing
IBM
WebSphere
Application
Server
and
integrating
it
with
IBM
Tivoli
Service
Level
Advisor.
See
the
official
documentation
provided
on
the
IBM
WebSphere
Application
Server
product
media
included
with
IBM
Tivoli
Service
Level
Advisor
for
additional
information,
and
also
refer
to
the
latest
IBM
WebSphere
Application
Server
product
information
online
at
the
following
Web
site:
http://www.ibm.com/software/webservers/appserv/was/library
SLM
Administrative
Console
Information
IBM
Tivoli
Service
Level
Advisor
provides
the
SLM
Administrative
Console,
a
Web-based
Administration
Server
graphical
user
interface
(GUI)
that
runs
in
the
Preface
vii
IBM
WebSphere
environment,
from
which
you
can
create
and
manage
schedules,
offerings,
customers,
realms,
and
SLAs.
Information
on
the
use
of
the
SLM
Administrative
Console
and
tasks
related
to
creating
and
managing
SLAs
are
described
in
detail
in
Managing
Service
Level
Agreements.
User
assistance
for
the
SLM
Administrative
Console
is
available
in
the
Task
Assistant
online
help
function.
Related
publications
The
following
documents
also
provide
useful
information:
The
Tivoli
Software
Glossary
includes
definitions
for
many
of
the
technical
terms
related
to
Tivoli
software.
The
Tivoli
Software
Glossary
is
available,
in
English
only,
at
the
following
Web
site:
http://publib.boulder.ibm.com/tividd/glossary/termsmst04.htm
Access
the
glossary
by
clicking
the
Glossary
link
on
the
left
pane
of
the
Tivoli
software
library
window.
Accessing
Publications
Online
In
addition
to
the
Documentation
CD
that
is
shipped
with
IBM
Tivoli
Service
Level
Advisor,
you
can
also
access
these
publications
online.
IBM
posts
publications
for
this
and
all
other
Tivoli
products,
as
they
become
available
and
whenever
they
are
updated,
to
the
Tivoli
software
information
center
Web
site.
Access
the
Tivoli
software
information
center
by
first
going
to
the
Tivoli
software
library
at
the
following
Web
address:
http://www.ibm.com/software/tivoli/library
Scroll
down
and
click
the
Product
manuals
link.
In
the
Tivoli
Technical
Product
Documents
Alphabetical
Listing
window,
click
the
IBM
Tivoli
Service
Level
Advisor
link
to
access
the
product
library
at
the
Tivoli
software
information
center.
Note:
If
you
documents
on
other
than
letter-sized
paper,
set
the
option
in
the
File
–>
window
that
allows
Adobe
Reader
to
letter-sized
pages
on
your
local
paper.
Ordering
publications
You
can
order
many
Tivoli
publications
online
at
the
following
Web
site:
www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi
You
can
also
order
by
telephone
by
calling
one
of
these
numbers:
v
In
the
United
States:
800-879-2755
v
In
Canada:
800-426-4968
In
other
countries,
see
the
following
Web
site
for
a
list
of
telephone
numbers:
http://www.ibm.com/software/tivoli/order-lit/
Accessibility
Accessibility
features
help
users
with
a
physical
disability,
such
as
restricted
mobility
or
limited
vision,
to
use
software
products
successfully.
With
this
product,
you
can
use
assistive
technologies
to
hear
and
navigate
the
interface.You
can
also
use
the
keyboard
instead
of
the
mouse
to
operate
all
features
of
the
graphical
user
interface.
viii
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Tivoli
technical
training
For
Tivoli
technical
training
information,
refer
to
the
following
IBM
Tivoli
Education
Web
site:
www.ibm.com/software/tivoli/education
Contacting
IBM
Software
Support
IBM
Software
Support
provides
assistance
with
product
defects.
Before
contacting
IBM
Software
Support,
your
company
must
have
an
active
IBM
software
maintenance
contract,
and
you
must
be
authorized
to
submit
problems
to
IBM.
The
type
of
software
maintenance
contract
that
you
need
depends
on
the
type
of
product
you
have:
v
For
IBM
distributed
software
products
(including,
but
not
limited
to,
Tivoli,
Lotus®,
and
Rational®
products,
as
well
as
DB2
Universal
Database
and
WebSphere
products
that
run
on
Windows
or
UNIX®
operating
systems),
enroll
in
Passport
Advantage®
in
one
of
the
following
ways:
–
Online:
Go
to
the
following
Passport
Advantage
Web
page
and
click
How
to
Enroll:
www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home
–
By
phone:
For
the
phone
number
to
call
in
your
country,
go
to
the
following
IBM
Software
Support
Web
site
and
click
the
name
of
your
geographic
region:
techsupport.services.ibm.com/guides/contacts.html
v
For
IBM
eServer™
software
products
(including,
but
not
limited
to,
DB2
Universal
Database
and
WebSphere
products
that
run
in
zSeries®,
pSeries®,
and
iSeries™
environments),
you
can
purchase
a
software
maintenance
agreement
by
working
directly
with
an
IBM
sales
representative
or
an
IBM
Business
Partner.
For
more
information
about
support
for
eServer
software
products,
go
to
the
IBM
Technical
Support
Advantage
Web
page:
www.ibm.com/servers/eserver/techsupport.html
If
you
are
not
sure
what
type
of
software
maintenance
contract
you
need,
call
1-800-IBMSERV
(1-800-426-7378)
in
the
United
States
or,
from
other
countries,
go
to
the
contacts
page
of
the
following
IBM
Software
Support
Handbook
on
the
Web
and
click
the
name
of
your
geographic
region
for
phone
numbers
of
people
who
provide
support
for
your
location:
techsupport.services.ibm.com/guides/contacts.html
Follow
the
steps
in
this
topic
to
contact
IBM
Software
Support:
1.
Determine
the
business
impact
of
your
problem.
2.
Describe
your
problem
and
gather
background
information.
3.
Submit
your
problem
to
IBM
Software
Support.
Determine
the
business
impact
of
your
problem
When
you
report
a
problem
to
IBM,
you
are
asked
to
supply
a
severity
level.
Therefore,
you
need
to
understand
and
assess
the
business
impact
of
the
problem
you
are
reporting.
Use
the
following
criteria
to
decide
on
an
appropriate
severity
level
for
your
problem:
Severity
1
Critical
business
impact:
You
are
unable
to
use
the
program,
resulting
in
a
critical
impact
on
operations.
This
condition
requires
an
immediate
solution.
Preface
ix
Severity
2
Significant
business
impact:
The
program
is
usable
but
is
severely
limited.
Severity
3
Some
business
impact:
The
program
is
usable
with
less
significant
features
(not
critical
to
operations)
unavailable.
Severity
4
Minimal
business
impact:
The
problem
causes
little
impact
on
operations,
or
a
reasonable
circumvention
to
the
problem
has
been
implemented.
Describe
your
problem
and
gather
background
information
When
explaining
a
problem
to
IBM,
be
as
specific
as
possible.
Include
all
relevant
background
information
so
that
IBM
Software
Support
specialists
can
help
you
solve
the
problem
efficiently.
To
save
time,
know
the
answers
to
these
questions:
v
What
software
versions
were
you
running
when
the
problem
occurred?
v
Do
you
have
logs,
traces,
and
messages
that
are
related
to
the
problem
symptoms?
IBM
Software
Support
is
likely
to
ask
for
this
information.
v
Can
the
problem
be
recreated?
If
so,
what
steps
led
to
the
failure?
v
Have
any
changes
been
made
to
the
system?
(For
example,
hardware,
operating
system,
networking
software,
and
so
on.)
v
Are
you
currently
using
a
workaround
for
this
problem?
If
so,
please
be
prepared
to
explain
it
when
you
report
the
problem.
Submit
your
problem
to
IBM
Software
Support
You
can
submit
your
problem
in
one
of
two
ways:
v
Online:
Go
to
the
″Submit
and
track
problems″
page
on
the
IBM
Software
Support
site:
http://www.ibm.com/software/support/probsub.html
Enter
your
information
into
the
appropriate
problem
submission
tool.
v
Do
you
have
logs,
traces,
and
messages
that
are
related
to
the
problem
symptoms?
IBM
Software
Support
is
likely
to
ask
for
this
information.
v
Can
the
problem
be
recreated?
If
so,
what
steps
led
to
the
failure?
v
Have
any
changes
been
made
to
the
system?
(For
example,
hardware,
operating
system,
networking
software,
and
so
on.)
v
Are
you
currently
using
a
workaround
for
this
problem?
If
so,
please
be
prepared
to
explain
it
when
you
report
the
problem.
If
the
problem
you
submit
is
for
a
software
defect
or
for
missing
or
inaccurate
documentation,
IBM
Software
Support
creates
an
Authorized
Program
Analysis
Report
(APAR).
The
APAR
describes
the
problem
in
detail.
Whenever
possible,
IBM
Software
Support
provides
a
workaround
for
you
to
implement
until
the
APAR
is
resolved
and
a
fix
is
delivered.
IBM
publishes
resolved
APARs
on
the
IBM
product
support
Web
pages
daily,
so
that
other
users
who
experience
the
same
problem
can
benefit
from
the
same
resolutions.
For
more
information
about
problem
resolution,
see
“Searching
knowledge
bases”
and
“Obtaining
fixes”
on
page
xi.
Searching
knowledge
bases
If
you
have
a
problem
with
your
IBM
software,
you
want
it
resolved
quickly.
Begin
by
searching
the
available
knowledge
bases
to
determine
whether
the
resolution
to
your
problem
is
already
documented.
x
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Search
the
information
center
on
your
local
system
or
network
IBM
provides
extensive
documentation
that
can
be
installed
on
your
local
machine
or
on
an
intranet
server.
You
can
use
the
search
function
of
this
information
center
to
query
conceptual
information,
instructions
for
completing
tasks,
reference
information,
and
support
documents.
Tip:
Update
your
information
center
with
the
latest
support
information.
Search
the
Internet
If
you
cannot
find
an
answer
to
your
question
in
the
information
center,
search
the
Internet
for
the
latest,
most
complete
information
that
might
help
you
resolve
your
problem.
To
search
multiple
Internet
resources
for
your
product,
expand
the
product
folder
in
the
navigation
frame
to
the
left
and
select
Support
on
the
Web.
From
this
topic,
you
can
search
a
variety
of
resources
including:
v
IBM
technotes
v
IBM
downloads
v
IBM
Redbooks®
v
IBM
DeveloperWorks
v
Forums
and
newsgroups
v
Obtaining
fixes
A
product
fix
might
be
available
to
resolve
your
problem.
You
can
determine
what
fixes
are
available
for
your
IBM
software
product
by
checking
the
product
support
Web
site:
1.
Go
to
the
IBM
Software
Support
Web
site
(http://www.ibm.com/software/support).
2.
Under
Products
A
-
Z,
select
your
product
name.
This
opens
a
product-specific
support
site.
3.
Under
Self
help,
follow
the
link
to
All
Updates,
where
you
find
a
list
of
fixes,
fix
packs,
and
other
service
updates
for
your
product.
For
tips
on
refining
your
search,
click
Search
tips.
4.
Click
the
name
of
a
fix
to
read
the
description
and
optionally
download
the
fix.
To
receive
weekly
notifications
about
fixes
and
other
news
about
IBM
products,
follow
these
steps:
1.
From
the
support
page
for
any
IBM
product,
click
My
support
in
the
upper-right
corner
of
the
page.
2.
If
you
have
already
registered,
skip
to
the
next
step.
If
you
have
not
registered,
click
register
in
the
upper-right
corner
of
the
support
page
to
establish
your
user
ID
and
password.
3.
Sign
in
to
My
support.
4.
On
the
My
support
page,
click
Edit
profiles
in
the
left
navigation
pane,
and
scroll
to
Select
Preferences.
Select
a
product
family
and
select
the
appropriate
boxes
for
the
type
of
information
you
want.
5.
Click
Submit.
6.
For
notification
for
other
products,
repeat
Steps
4
and
5.
For
more
information
about
types
of
fixes,
see
the
Software
Support
Handbook
(http://techsupport.services.ibm.com/guides/handbook.html).
Preface
xi
Updating
support
information
Information
centers
typically
include
one
or
more
support
information
plug-ins.
These
plug-ins
add
IBM
technotes
and
other
support
documents
to
the
information
center.
The
following
steps
describe
how
to
update
your
support
information
plug-ins:
1.
Go
to
the
IBM
Software
Support
Web
site
(http://www.ibm.com/software/support).
2.
Under
Products
A
-
Z,
select
your
product
name.
This
opens
a
product-specific
support
site.
3.
Under
Search
support
for
this
product,
type
the
keyword
phrase:
com.ibm.support.
Select
the
Download
check
box,
and
click
Submit.
4.
Check
the
search
results
for
updates
to
support
information
plug-ins.
All
support
information
plug-ins
follow
the
naming
convention,
″com.ibm.support.product.doc.″
If
an
update
is
available,
select
it
from
the
list
and
view
the
download
instructions.
5.
Save
the
attached
zip
file
to
a
temporary
location
on
your
hard
drive.
6.
Unzip
the
downloaded
file,
making
sure
that
you
retain
the
subfolders.
7.
From
the
location
where
you
unzipped
the
file,
copy
the
support
information
plug-in
folder
to
your
Eclipse
plug-ins
folder.
For
example,
if
your
IBM
software
product
is
installed
at
c:\IBM\WebSphere\,
copy
the
updated
plug-in
folder
(com.ibm.support.product.doc)
to
c:\IBM\WebSphere\eclipse\plugins.
8.
To
see
the
updated
support
information,
start
the
information
center
(or
shut
it
down
and
restart
it),
and
expand
the
Support
information
node
in
the
navigation
tree.
Participating
in
newsgroups
User
groups
provide
software
professionals
with
a
forum
for
communicating
ideas,
technical
expertise,
and
experiences
related
to
the
product.
They
are
located
on
the
Internet,
and
are
available
using
standard
news
reader
programs.
These
groups
are
primarily
intended
for
user-to-user
communication,
and
are
not
a
replacement
for
formal
support.
If
you
use
Mozilla
as
your
browser,
complete
the
following
instructions
to
access
a
newsgroup:
1.
Open
a
Mozilla
browser
window.
2.
From
the
Edit
menu,
click
Preferences.
The
Preferences
window
is
displayed.
3.
In
the
Category
view,
click
&
Newsgroups
to
display
the
&
Newsgroups
settings.
4.
Select
the
Use
Mozilla
as
the
default
application
check
box.
5.
Click
OK.
6.
Close
your
Mozilla
browser
and
then
open
it
again.
7.
Cut
and
paste
the
newsgroup
address
of
a
product
into
the
browser
Address
field,
and
press
Enter
to
open
the
newsgroup.
If
you
use
Microsoft®
Internet
Explorer
as
your
browser,
complete
the
following
instructions
to
access
a
newsgroup:
1.
Open
an
Internet
Explorer
browser.
2.
From
the
Tools
menu,
click
Internet
Options.
3.
On
the
Internet
Options
window,
click
the
Programs
tab.
4.
In
the
Newsgroups
list,
click
the
Down
Arrow
and
then
click
Outlook
Express.
xii
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
5.
Click
OK.
6.
Close
your
Internet
Explorer
browser
and
then
open
it
again.
7.
Cut
and
paste
the
newsgroup
address
of
a
product
into
the
browser
Address
field,
and
press
Enter
to
open
the
newsgroup.
You
can
find
information
on
Tivoli
Data
Warehouse
by
accessing
the
following
newsgroup:
news://news.software.ibm.com/ibm.software.tivoli.enterprise-data-warehouse
You
can
find
information
on
IBM
Tivoli
Service
Level
Advisor
by
accessing
the
following
newsgroup:
news://news.software.ibm.com/ibm.software.tivoli.service-level-advisor
You
can
find
information
on
DB2
Universal
Database
by
accessing
the
following
newsgroup:
news://news.software.ibm.com/ibm.software.db2
You
can
find
information
on
IBM
WebSphere
Application
Server
by
accessing
the
following
newsgroup:
news://news.software.ibm.com/ibm.software.websphere.application-server
Conventions
used
in
this
guide
This
guide
uses
several
conventions
for
special
terms
and
actions,
operating
system-dependent
commands
and
paths,
and
margin
graphics.
Typeface
conventions
This
guide
uses
the
following
typeface
conventions:
Bold
v
Lowercase
commands
and
mixed
case
commands
that
are
otherwise
difficult
to
distinguish
from
surrounding
text
v
Interface
controls
(check
boxes,
push
buttons,
radio
buttons,
spin
buttons,
fields,
folders,
icons,
list
boxes,
items
inside
list
boxes,
multicolumn
lists,
containers,
menu
choices,
menu
names,
tabs,
property
sheets),
labels
(such
as
Tip:,
and
Operating
system
considerations:)
v
Keywords
and
parameters
in
text
Italic
v
Citations
(titles
of
books,
diskettes,
and
CDs)
v
Words
defined
in
text
v
Emphasis
of
words
(words
as
words)
v
New
terms
in
text
(except
in
a
definition
list)
v
Variables
and
values
you
must
provide
Monospace
v
Examples
and
code
examples
v
File
names,
programming
keywords,
and
other
elements
that
are
difficult
to
distinguish
from
surrounding
text
v
Message
text
and
prompts
addressed
to
the
user
v
Text
that
the
user
must
type
v
Values
for
arguments
or
command
options
Preface
xiii
Operating
system-dependent
variables
and
paths
This
guide
uses
the
UNIX
convention
for
specifying
environment
variables
and
for
directory
notation.
When
using
the
Windows
command
line,
replace
$variable
with
%
variable%
for
environment
variables
and
replace
each
forward
slash
(/)
with
a
backslash
(
\)
in
directory
paths.
The
names
of
environment
variables
are
not
always
the
same
in
Windows
and
UNIX.
For
example,
%TEMP%
in
Windows
is
equivalent
to
$tmp
in
UNIX.
Note:
If
you
are
using
the
bash
shell
on
a
Windows
system,
you
can
use
the
UNIX
conventions.
xiv
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Chapter
1.
Message
and
Trace
Logging
Logging
refers
to
the
collecting
of
text
messages
and
trace
data
created
by
IBM
Tivoli
Service
Level
Advisor
components
and
applications.
These
messages
and
data
are
written
to
log
files
for
later
viewing
and
possible
action.
Logging
records
these
events
that
occur
while
an
application
is
operating
through
software
objects
called
loggers.
There
are
two
types
of
logging:
message
logging
and
trace
logging.
Message
logging
records
text
messages
to
relay
information
on
how
the
system
or
application
is
performing.
Messages
are
also
used
to
alert
the
system
administrator
to
exception
conditions
when
they
occur.
Messages
are
translated
into
multiple
languages
and
are
displayed
based
on
the
locale
of
the
server
on
which
the
message
was
generated.
By
default,
message
logging
is
enabled
for
IBM
Tivoli
Service
Level
Advisor.
A
related
set
of
message
logs
provides
additional
detail
on
certain
messages
when
they
occur.
These
message
detail
logs
cross
reference
messages
that
are
written
to
the
regular
message
logs,
and
provide
additional
information
that
you
can
use
to
assist
in
problem
determination
and
resolution.
Trace
logging
is
used
to
capture
transient
information
about
the
current
operating
environment
when
a
component
or
application
fails
to
operate
as
intended.
IBM
Customer
Support
personnel
use
the
captured
trace
information
to
determine
the
source
of
an
error
or
unexpected
condition,
and
to
diagnose
the
problem.
When
the
component
is
operating
normally,
tracing
is
usually
turned
on
at
a
level
1
filter
to
optimize
performance.
Tracing
is
enabled
by
default
for
IBM
Tivoli
Service
Level
Advisor
and
can
be
filtered
based
on
several
different
criteria.
Trace
log
data
is
only
available
in
the
English
language.
When
a
message
or
trace
event
occurs
within
IBM
Tivoli
Service
Level
Advisor,
the
information
about
the
event
is
captured
in
a
log
record
and
written
to
one
of
the
IBM
Tivoli
Service
Level
Advisor
log
files.
Log
records
encapsulate
the
generated
message
and
trace
data.
The
contents
of
the
log
record
depend
on
the
type
of
logger
and
the
information
supplied
when
the
logged
event
occurs.
In
addition
to
message
and
trace
logging,
IBM
Tivoli
Service
Level
Advisor
contains
a
third
type
of
logging
called
first
failure
data
capture
(FFDC).
FFDC
captures
additional
information
that
would
not
normally
be
found
in
the
message
logs
when
an
error
occurs.
FFDC
is
similar
to
tracing
in
that
it
is
intended
for
use
by
IBM
Customer
Support.
Similar
information
might
be
contained
in
the
trace
logs,
but
the
advantage
of
FFDC
is
in
catching
specific
error
information
not
normally
caught
when
tracing
is
disabled.
Like
trace
logging,
FFDC
should
only
be
configured
with
the
advice
of
IBM
Customer
Support.
IBM
Tivoli
Service
Level
Advisor
also
supports
audit
logging.
This
type
of
logging
records
information
about
creations,
deletions,
and
changes
to
schedules,
published
offerings,
realms,
customers,
SLAs,
and
schedule
customizations.
This
logging
information
also
includes
changes
resulting
from
re-evaluations
and
adjudication
information
related
to
excluding
or
reinstating
violations
using
the
SLM
Administrative
Console.
This
is
a
form
of
message
logging
and
is
configured
and
viewed
in
the
same
manner.
See
“Audit
Logging”
on
page
17
for
further
information.
©
Copyright
IBM
Corp.
2002,
2004
1
Handlers
and
Filters
Handlers
are
software
objects
that
direct
log
records
captured
by
a
logger
to
a
destination.
In
IBM
Tivoli
Service
Level
Advisor,
log
records
are
directed
to
a
multifile
handler
(a
rotating
set
of
log
files),
an
XML
multifile
handler,
and
a
console
handler.
IBM
Tivoli
Service
Level
Advisor
audit
logging
uses
specific
audit
multiple
file
and
audit
XML
multiple
file
handlers.
Handlers
are
associated
with
message
and
trace
loggers
by
configuration
settings.
Filters
can
be
applied
to
loggers,
to
handlers,
or
to
both
loggers
and
handlers.
When
applied
to
a
logger,
the
filters
determine
which
type
of
message
and
trace
records
the
logger
will
process.
When
applied
to
a
handler,
the
filters
determine
which
type
of
message
and
trace
records
the
handler
will
send
to
the
destination.
Accessing
Log
Files
Log
files
are
stored
in
the
Tivoli
Common
Directory,
a
common
repository
for
all
Tivoli
applications
to
store
log
and
trace
message
files.
The
location
of
this
directory
is
set
when
the
first
Tivoli
application
is
installed
on
the
machine.
If
IBM
Tivoli
Service
Level
Advisor
is
the
first
application
to
be
installed
on
the
machine,
the
installation
procedure
creates
the
Tivoli
Common
Directory
in
the
default
path
<Program_Files>\ibm\tivoi\common,
or
in
another
location
specified
by
the
user
at
installation
time.
The
<Program_Files>
parameter
is
found
on
your
system
by
examining
the
registry:
1.
Start
regedt32
(click
Start
–>
Run,
then
enter
regedt32).
2.
Expand
the
tree
under
HKEY_LOCAL_MACHINE
and
navigate
to
SOFTWARE\Microsoft\Windows\CurrentVersion.
3.
Find
the
ProgramFilesDir
parameter.
The
value
of
this
parameter
should
be
similar
to
C:\Program
Files.
You
can
find
where
the
Tivoli
Common
Directory
is
created
by
looking
in
the
following
file:
v
For
Windows
systems:
<Program_Files>\ibm\tivoli\common\cfg\log.properties
v
For
UNIX
systems:
/etc/ibm/tivoli/common/cfg/log.properties
The
log
files
stored
in
the
Tivoli
Common
Directory
are
accessible
to
users
defined
as
follows:
v
On
Windows
systems,
your
Windows
NT®
user
name
must
either
have
Administrator
access
or
belong
to
the
tivoli
user
group.
You
can
add
new
users
to
the
tivoli
group
by
doing
the
following:
1.
Navigate
to
the
Tivoli
Common
Directory
(the
default
is
<Program_Files>\ibm\tivoli\common)
and
right-click
on
the
folder,
then
click
Properties,
and
then
Security,
and
add
the
tivoli
group
to
the
authorized
access
list.
2.
If
the
Tivoli
Common
Directory
is
not
located
in
the
default
location,
the
log.properties
file
is
still
initially
created
at
<Program_Files>\ibm\tivoli\common\cfg.
Add
the
tivoli
group
to
this
file
also,
by
navigating
to
the
file,
right-clicking
on
the
file
icon,
then
clicking
Properties,
and
then
Security,
and
add
the
tivoli
group
to
the
authorized
access
list.
2
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
3.
Click
Start
–>
Settings
–>
Control
Panel
–>
Users
and
Passwords.
4.
Select
the
Advanced
tab
and
then
click
the
Advanced
button
under
Advanced
User
Management.
5.
Open
the
groups
folder
and
display
the
users
that
are
already
members
of
the
tivoli
group.
Repeat
this
process
to
add
other
users
to
the
group.v
On
UNIX
systems,
the
specific
procedure
might
vary
depending
on
the
system
platform.
Consult
your
UNIX
administrator
for
assistance
in
adding
a
new
user
to
the
tivoli
group
for
access
to
these
files.
Configuring
Log
Files
IBM
Tivoli
Service
Level
Advisor
logs
using
the
multiple
file
handler
are
configured
to
adjust
the
number
of
message
and
trace
log
files
and
the
size
of
each
of
these
files.
By
default,
the
multiple
file
handler
specifies
that
log
files
are
created
in
a
rotating
set
of
3
files
of
size
512
KB.
This
includes
the
multiple
file
handler
for
audit
logging.
Trace
logging
has
been
configured
to
a
default
file
size
of
5
MB.
The
following
files
do
not
use
the
multiple
file
handler
and
cannot
be
configured
in
this
manner:
v
IBM
Tivoli
Service
Level
Advisor
files
tslmerr.log
and
tslmout.log
on
the
SLM
Server
v
The
file
named
msgTSLALogging.log
on
all
three
components
v
All
Installation
log
files
The
SLM
Server,
SLM
Reports,
and
SLM
Administration
Server
components
of
IBM
Tivoli
Service
Level
Advisor
have
specific
commands
to
modify
their
logging
structure.
If
these
three
components
are
installed
together
on
the
same
machine
in
the
same
directory,
changes
to
the
logging
infrastructure
are
applied
to
all
three
components.
Configuring
Log
Files
for
the
SLM
Server
Configure
the
number
of
message
and
trace
files
and
the
size
of
the
files
by
using
the
scmd
log
handler
command,
as
described
in
the
Command
Reference.
Configure
message
and
trace
files
by
specifying
the
handler
object
names
msgFile.slm,
msgFile.xml,
trcFile.slm,
and
trcFile.xml,
respectively,
in
the
scmd
log
handler
command.
To
modify
the
number
of
log
files
or
their
size,
complete
the
following
steps:
1.
At
a
command
prompt,
navigate
to
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed,
and
run
the
following
command
to
setup
the
SLM
environment:
v
For
Windows
systems:
slmenv.bat
v
For
UNIX
systems:
.
./slmenv.sh
2.
To
change
the
maximum
size
of
message
and
trace
files,
use
the
maxFileSize
key,
where
the
value
of
maxFileSize
is
the
file
size
in
KB.
For
example,
to
change
the
size
of
the
ASCII
message
files
to
1024
KB,
issue
the
command:
scmd
log
handler
msgFile.slm
-set
maxFileSize=1024
To
change
the
size
of
ASCII
trace
files
to
2048
KB,
issue
the
command:
scmd
log
handler
trcFile.slm
-set
maxFileSize=2048
Chapter
1.
Message
and
Trace
Logging
3
Note:
the
key
names
maxFileSize
and
maxFiles
are
case
sensitive.
Be
sure
to
specify
them
as
shown.
3.
To
change
the
number
of
message
or
trace
files
that
can
be
created,
use
the
maxFiles
key,
where
the
value
of
maxFiles
is
an
integer
specifying
the
maximum
number
of
files
that
can
be
created.
For
example,
to
set
the
maximum
number
of
ASCII
message
log
files
that
can
be
created
to
9,
issue
the
command:
scmd
log
handler
msgFile.slm
-set
maxFiles=9
To
set
the
maximum
number
of
trace
log
files
that
can
be
created
to
6,
issue
the
command:
scmd
log
handler
trcFile.slm
-set
maxFiles=6
To
change
the
configuration
on
the
XML
files,
replace
the
specified
handlers
with
the
XML
handlers.
For
example,
replace
msgFile.slm
with
msgFile.xml.
You
can
specify
both
maxFiles
and
maxFileSize
in
a
single
command.
The
key
names
maxFileSize
and
maxFiles
are
case
sensitive.
Be
sure
to
specify
them
as
shown.
Configuring
Log
Files
for
SLM
Reports
and
the
SLM
Administration
Server
Configure
the
number
of
message
and
trace
files
and
the
size
of
the
files
by
using
the
logutil
handler
command,
as
described
in
the
Command
Reference.
Configure
message
and
trace
files
by
specifying
the
handler
object
names
msgFile.slm,
msgFile.xml,
trcFile.slm,
and
trcFile.xml,
respectively,
in
the
logutil
handler
command.
To
modify
the
number
of
log
files
or
their
size,
complete
the
following
steps:
1.
At
a
command
prompt,
navigate
to
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed,
and
run
the
following
command
to
setup
the
SLM
environment:
v
For
Windows:
slmenv.bat
v
For
UNIX:
.
./slmenv.sh
2.
To
change
the
maximum
size
of
message
and
trace
files,
use
the
maxFileSize
key,
where
the
value
of
maxFileSize
is
the
file
size
in
KB.
For
example,
to
change
the
size
of
ASCII
message
files
to
1024
KB,
issue
the
command:
logutil
handler
msgFile.slm
-set
maxFileSize=1024
To
change
the
size
of
ASCII
trace
files
to
2048
KB,
issue
the
command:
logutil
handler
trcFile.slm
-set
maxFileSize=2048
3.
To
change
the
number
of
message
or
trace
files
that
can
be
created,
use
the
maxFiles
key,
where
the
value
of
maxFiles
is
an
integer
specifying
the
maximum
number
of
files
that
can
be
created.
For
example,
to
set
the
maximum
number
of
ASCII
message
log
files
that
can
be
created
to
9,
issue
the
command:
logutil
handler
msgFile.slm
-set
maxFiles=9
To
set
the
maximum
number
of
ASCII
trace
log
files
that
can
be
created
to
6,
issue
the
command:
logutil
handler
trcFile.slm
-set
maxFiles=6
To
change
the
configuration
on
the
XML
files,
replace
the
specified
handlers
with
the
XML
handlers
(for
example,
replace
trcFile.slm
with
trcFile.xml).
4
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
You
can
specify
both
maxFiles
and
maxFileSize
in
a
single
command.
The
key
names
maxFileSize
and
maxFiles
are
case
sensitive.
Be
sure
to
specify
them
as
shown.
Locating
Trace
and
Message
Log
Files
Message,
message
details,
trace,
and
first
failure
data
capture
logs
for
Tivoli
products
are
located
under
a
common
parent
directory
called
the
Tivoli
Common
Directory.
The
location
of
the
Tivoli
Common
Directory
is
specified
during
each
product
installation.
Because
the
directory
is
shared
by
all
products,
if
one
product
modifies
the
location
of
the
Tivoli
Common
Directory,
all
products
begin
logging
to
that
directory.
During
the
installation
of
IBM
Tivoli
Service
Level
Advisor,
if
the
Tivoli
Common
Directory
was
defined
by
another
product,
the
existing
location
is
used.
If
the
Tivoli
Common
Directory
is
not
defined,
the
IBM
Tivoli
Service
Level
Advisor
installation
procedure
includes
defining
this
location.
Specify
a
location
for
the
Tivoli
Common
Directory
or
accept
the
default
location
presented:
v
For
UNIX
systems,
the
default
location
is
/usr/ibm/tivoli/common.
v
For
Windows
systems,
the
default
location
is
%Program
Files%\ibm\tivoli\common.
The
%Program
Files%
parameter
is
found
on
your
system
by
examining
the
registry:
1.
Start
regedt32
(click
Start
–>
Run,
then
enter
regedt32).
2.
Expand
the
tree
under
HKEY_LOCAL_MACHINE
and
navigate
to
SOFTWARE\Microsoft\Windows\CurrentVersion.
3.
Find
the
ProgramFilesDir
parameter.
The
default
value
of
this
parameter
should
be
similar
to
C:\Program
Files.
For
a
custom
installation
of
Windows
or
other
locales,
this
value
might
differ.
You
can
find
where
the
Tivoli
Common
Directory
is
located
on
your
local
machine
by
looking
in
the
following
file:
v
For
Windows
systems:
%Program
Files%\ibm\tivoli\common\cfg\log.properties
v
For
UNIX
systems:
/etc/ibm/tivoli/common/cfg/log.properties
This
file
is
used
by
other
Tivoli
applications
to
determine
the
location
of
the
Tivoli
Common
Directory.
It
should
not
be
modified,
renamed,
deleted,
or
saved
in
a
different
format.
Log
files
specific
to
each
product
are
contained
in
a
subdirectory
denoted
by
the
three
letter
product
identifier.
The
product
identifier
for
IBM
Tivoli
Service
Level
Advisor
is
DYK.
All
IBM
Tivoli
Service
Level
Advisor
specific
log
information
is
contained
in
the
<Tivoli
Common
Directory>/DYK
directory.
This
directory
is
referred
to
as
the
IBM
Tivoli
Service
Level
Advisor
Common
Directory.
Additional
directories,
/logs
and
/ffdc,
for
log
and
first
failure
data
capture
information,
respectively,
are
contained
within
each
product
directory.
Some
products
might
have
additional
subdirectories.
A
complete
list
of
subdirectories
for
the
Tivoli
Common
Directory
specific
to
IBM
Tivoli
Service
Level
Advisor,
and
the
terms
used
to
reference
each
directory,
are
listed
in
Table
3
on
page
6.
Within
the
<Tivoli
Common
Directory>/DYK/logs/
directory
are
additional
directories
containing
the
log
files
for
each
of
the
components
of
IBM
Tivoli
Service
Level
Advisor,
as
shown
in
Table
1
on
page
6:
Chapter
1.
Message
and
Trace
Logging
5
Table
1.
Directories
of
log
files
for
IBM
Tivoli
Service
Level
Advisor
components
Component
Log
file
directory
SLM
Server
<Tivoli
Common
Directory>/DYK/logs/SLMServer
SLM
Reports
<Tivoli
Common
Directory>/DYK/logs/SLMReport
SLM
Administration
Server
<Tivoli
Common
Directory>/DYK/logs/SLMAdmin
SLM
Installation
<Tivoli
Common
Directory>/DYK/logs/install
Because
the
location
of
the
Tivoli
Common
Directory
might
be
modified
by
other
applications,
the
location
must
be
determined
each
time
the
product
starts
up.
If
an
error
occurs
while
determining
the
location
of
the
Tivoli
Common
Directory,
default
log
locations
specific
to
each
component
of
IBM
Tivoli
Service
Level
Advisor
are
used
as
shown
in
Table
2:
Table
2.
Default
directories
of
log
files
for
IBM
Tivoli
Service
Level
Advisor
components
Component
Log
file
directory
SLM
Server
<SLM
Install
Directory>/log/DYK/logs/SLMServer
SLM
Reports
<SLM
Install
Directory>/log/DYK/logs/SLMReport
SLM
Administration
Server
<SLM
Install
Directory>/log/DYK/logs/SLMAdmin
Similar
to
the
/logs
directory
structure,
IBM
Tivoli
Service
Level
Advisor
might
also
contain
a
<Tivoli
Common
Directory>/DYK/ffdc
directory
with
the
same
subdirectories
for
each
component
of
IBM
Tivoli
Service
Level
Advisor.
This
FFDC
directory
contains
the
FFDC
trace
files
intended
for
use
by
IBM
Customer
Support.
It
appears
only
in
the
event
that
an
error
occurs
that
writes
to
an
FFDC
log.
If
no
errors
occur
the
/ffdc
directory
is
not
present.
When
an
error
occurs,
the
/ffdc
directory
is
created,
followed
by
a
directory
specifying
the
year,
month
and
day
in
which
the
error
occurred,
the
directory
for
the
IBM
Tivoli
Service
Level
Advisor
component
in
which
the
error
occurred,
and
one
or
more
files
following
the
FFDC
naming
format.
See
Table
3
for
details
on
the
directory
structure
and
terms
specific
to
IBM
Tivoli
Service
Level
Advisor
for
the
Tivoli
Common
Directory.
Table
3.
Contents
and
terms
for
the
Tivoli
Common
Directory
Directory
Applicable
terms
<Tivoli
Common
Directory>
Tivoli
Common
Directory
<Tivoli
Common
Directory>\DYK
IBM
Tivoli
Service
Level
Advisor
Common
Directory
<Tivoli
Common
Directory>\DYK\logs
IBM
Tivoli
Service
Level
Advisor
Common
Log
Directory
<Tivoli
Common
Directory>\DYK\logs\SLMServer
IBM
Tivoli
Service
Level
Advisor
Common
Log
Directory
for
SLM
Server
<Tivoli
Common
Directory>\DYK\logs\SLMReport
IBM
Tivoli
Service
Level
Advisor
Common
Log
Directory
for
SLM
Reports
<Tivoli
Common
Directory>\DYK\logs\SLMAdmin
IBM
Tivoli
Service
Level
Advisor
Common
Log
Directory
for
SLM
Administration
Server
<Tivoli
Common
Directory>\DYK\logs\install
IBM
Tivoli
Service
Level
Advisor
Common
Log
Directory
for
Installation
6
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Table
3.
Contents
and
terms
for
the
Tivoli
Common
Directory
(continued)
Directory
Applicable
terms
<Tivoli
Common
Directory>\DYK\ffdc1
IBM
Tivoli
Service
Level
Advisor
Common
FFDC
Directory
<Tivoli
Common
Directory>\DYK\ffdc\<yyyymmdd>
IBM
Tivoli
Service
Level
Advisor
Common
FFDC
Directory
written
on
yyyymmdd
<Tivoli
Common
Directory>\DYK\ffdc\<yyyymmdd>\SLMServer
IBM
Tivoli
Service
Level
Advisor
Common
FFDC
Directory
written
on
yyyymmdd
for
SLM
Server
<Tivoli
Common
Directory>\DYK\ffdc\<yyyymmdd>\SLMReport
IBM
Tivoli
Service
Level
Advisor
Common
FFDC
Directory
written
on
yyyymmdd
for
SLM
Reports
<Tivoli
Common
Directory>\DYK\ffdc\<yyyymmdd>\SLMAdmin
IBM
Tivoli
Service
Level
Advisor
Common
FFDC
Directory
written
on
yyyymmdd
for
SLM
Administration
Server
1
The
IBM
Tivoli
Service
Level
Advisor
Common
FFDC
Directory
exists
only
when
an
FFDC
event
is
logged.
Removing
Aged
ffdc
Log
Files
Removing
aged
ffdc
log
files:
While
the
logs
follow
the
rotating
file
structure,
a
new
set
of
logs
is
created
for
each
new
date,
which
could
result
in
a
build
up
of
log
files
over
time.
Periodically
remove
these
older
log
files
manually
or
by
enabling
an
automated
purging
process.
To
enable
the
automatic
daily
purging
of
aged
ffdc
log
files,
issue
the
following
CLI
command
on
the
machine
where
the
SLM
Server
is
located:
scmd
log
trace
ffdc
-set
PurgeInterval=<n>
In
this
command,
the
value
for
<n>
indicates
the
number
of
days
of
ffdc
log
data
that
can
reside
in
the
oldest
ffdc
log
before
the
log
file
is
purged.
For
example,
to
specify
a
limit
on
the
oldest
ffdc
log
to
20
days,
use
PurgeInterval=20.
For
distributed
environments,
issue
a
similar
command
for
the
SLM
Administration
Server
and
SLM
Reports
options
on
their
respective
machines:
logutil
trace
ffdc
-set
PurgeInterval=<n>
To
disable
the
automatic
purging
of
ffdc
log
information,
set
the
value
for
PurgeInterval
to
0,
by
issuing
the
following
command:
scmd
log
trace
ffdc
-set
PurgeInterval=0
Relocating
the
Tivoli
Common
Directory
If
IBM
Tivoli
Service
Level
Advisor
detects
that
a
change
occurred
in
the
location
of
the
Tivoli
Common
Directory,
the
/DYK
directory
structure
is
moved
to
the
new
logging
location.
The
change
in
logging
location
and
any
errors
are
written
to
a
set
of
log
files
created
for
each
component
of
IBM
Tivoli
Service
Level
Advisor
(SLM
Server,
SLM
Administration
Server,
or
SLM
Reports)
that
detected
the
error
or
event.
Each
of
these
message
files
contains
the
same
messages,
but
serves
different
purposes.
Chapter
1.
Message
and
Trace
Logging
7
The
first
log
file
provides
a
known
location
in
which
the
messages
can
be
found,
and
points
to
the
new
Common
Log
Directory
if
a
change
in
its
location
occurred.
For
the
SLM
Server,
SLM
Administration
Server,
and
SLM
Reports,
this
file
is
located
at<SLM
Install
Dir>/log/msgTSLALogging.log.
The
second
log
file
is
located
in
the
IBM
Tivoli
Service
Level
Advisor
Common
Log
Directory
for
the
component
that
detected
the
change.
This
log
file
is
a
copy
of
the
first
log
file,
and
is
placed
in
the
Common
Log
Directory
for
the
component,
to
maintain
the
concept
of
a
central
location
of
log
files:
v
For
the
SLM
Server
component,
this
file
is
located
at<Tivoli
Common
Directory>/DYK/logs/SLMServer/msgTSLALogging.log.
v
For
the
SLM
Administration
Server
component,
this
file
is
located
at<Tivoli
Common
Directory>/DYK/logs/SLMAdmin/msgTSLALogging.log.
v
For
the
SLM
Reports
component,
this
file
is
located
at
<Tivoli
Common
Directory>/DYK/logs/SLMReports/msgTSLALogging.log.
After
the
IBM
Tivoli
Service
Level
Advisor
Common
Directory
is
moved
to
the
new
or
default
logging
location,
redirection
of
all
standard
output
logging
then
continues
normally.
If
the
/DYK
structure
exists
in
the
new
location,
all
existing
duplicate
files
are
renamed
with
a
timestamp
of
the
year,
month,
and
day
in
which
the
directory
location
changed.
Logging
continues
on
the
moved
files
from
the
previous
directory.
Log
File
Names
Message
and
trace
logger
output
is
placed
into
one
or
more
message
files
with
names
in
the
format
of
msgTSLAxn.log,
msgdetailsTSLAxn.log
or
traceTSLAxn.log.
In
these
name
formats,
the
following
variables
are
specified:
v
The
prefix
msg
or
trace
denotes
whether
the
log
file
is
a
message
or
trace
log.
v
n
specifies
a
number
differentiating
the
file
from
the
others
in
the
set.
v
x
specifies
the
format
of
the
file.
For
example,
the
first
message
log
file
created
is
named
msgTSLA1.log
by
default.
When
this
file
reaches
its
maximum
default
size,
it
is
renamed
to
msgTSLA2.log,
and
a
new
msgTSLA1.log
file
is
created.
This
ensures
that
the
latest
system
information
is
contained
in
msgTSLA1.log.
When
no
value
is
supplied
for
x,
the
standard
ASCII
format
is
used
(for
example,
msgTSLA1.log
and
traceTSLA1.log).
Specifying
XML
in
the
place
of
x
denotes
use
of
the
XML
format.
By
default,
these
message
files
can
grow
to
512
KB
in
size,
trace
files
can
grow
to
5
MB
in
size,
and
there
can
be
three
separate
files.
The
FFDC
files,
noted
earlier,
follow
the
same
configuration
and
naming
convention
as
the
trace
logs.
Each
FFDC
file
name
is
in
the
format
ffdcTSLAn.log.
These
files
are
intended
for
use
by
IBM
customer
support.
IBM
Tivoli
Service
Level
Advisor
audit
logging
follows
the
same
principles
as
for
message
logging.
Audit
log
files
are
prefixed
with
audit
to
denote
that
they
are
audit
specific
message
logs
containing
the
subset
of
the
message
log
files
pertaining
to
audit
logging.
See
“Audit
Logging”
on
page
17
for
details.
Audit
logs
are
viewed
and
configured
the
same
way
as
message
and
trace
log
files.
Table
4
on
page
9
and
Table
5
on
page
9
identify
the
log
files
available
with
IBM
Tivoli
Service
Level
Advisor,
where
<y>
is
an
incrementing
integer
from
1
to
3,
based
on
the
number
of
files
specified
by
the
multiple
file
handler.
Log
files
are
first
created
with
<y>
set
to
1,
and
incremented
when
the
maximum
file
size
is
reached.
Files
with
<y>
set
to
1
always
contain
the
most
recent
log
information.
8
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Table
4.
Available
log
files
Log
file
names
Description
tslmout.log
The
standard
output
of
the
IBM
Tivoli
Service
Level
Advisor
process.
This
output
matches
the
output
in
the
msgTSLAn.log
with
the
addition
of
lines
produced
from
within
the
code
and
messages
from
the
Tivoli
Common
Directory.
tslmerr.log
The
standard
error
output
of
the
IBM
Tivoli
Service
Level
Advisor
process.
This
output
contains
any
messages
written
as
system
errors
defined
within
the
code.
msgTSLAn.log
IBM
Tivoli
Service
Level
Advisor
messages
in
ASCII
format.
msgdetailTSLAn.log
IBM
Tivoli
Service
Level
Advisor
message
details
in
ASCII
format.
msgTSLAXMLn.log
IBM
Tivoli
Service
Level
Advisor
XML
formatted
message
log
file.
Use
the
XML
Viewer
to
configure
ASCII
and
HTML
logs
from
this
file.
msgTSLALogging.log
IBM
Tivoli
Service
Level
Advisor
messages
concerning
errors
or
changes
in
the
Tivoli
Common
Directory.
This
file
is
created
only
when
an
error
or
change
is
detected.
traceTSLAn.log
IBM
Tivoli
Service
Level
Advisor
trace
messages
in
ASCII
format.
These
files
appear
only
after
tracing
is
enabled.
traceTSLAXMLn.log
IBM
Tivoli
Service
Level
Advisor
XML
formatted
trace
log
file.
Use
the
XML
Viewer
to
configure
ASCII
and
HTML
logs
from
this
file.
These
files
appear
only
after
tracing
is
enabled.
Table
5.
IBM
Tivoli
Service
Level
Advisor
Installation
log
files
Log
file
names
Description
traceTSLA21install.log
IBM
Tivoli
Service
Level
Advisor
install
log
containing
the
output
from
the
installation
process.
traceTSLA21Uninstall.log
IBM
Tivoli
Service
Level
Advisor
uninstall
log
containing
the
output
from
the
uninstallation
process.
traceUserMig<x>.log
msgUserMig<x>.log
These
logs
are
generated
in
the
\install
subdirectory
during
the
upgrade
process
and
when
user
migration
is
executed.
The
log
file
names
use
the
same
naming
conventions
as
the
regular
logs,
where
<x>
is
an
integer.
The
files
auditTSLAn>.log,
auditTSLAXMLn.log,
auditTSLADetailn.log,
and
auditTSLADetailXMLn.log
are
also
present
in
the
same
directory
as
the
files
in
Table
4
and
Table
5
for
the
SLM
Administration
Server.
These
log
files
pertain
to
IBM
Tivoli
Service
Level
Advisor
auditing
functions.
See
“Audit
Logging”
on
page
17.
for
more
information
on
auditing
functions.
Chapter
1.
Message
and
Trace
Logging
9
Log
file
names
and
locations
are
the
same
for
the
SLM
Administration
Server,
SLM
Reports
and
the
SLM
Server
(see
Table
4
on
page
9),
except
for
tslmout.log
and
tslmerr.log,
which
are
only
available
for
the
SLM
Server
environment.
Additional
Log
Files
for
SLM
Administration
Server
and
SLM
Reports
Additional
log
files
are
created
by
IBM
WebSphere
Application
Server
for
the
SLM
Administration
Server
and
SLM
Reports.
These
log
files
contain
information
specific
to
IBM
Tivoli
Service
Level
Advisor
running
within
each
application.
Log
files
specific
to
IBM
WebSphere
Application
Server
are
available
in
the
<WebSphere_Dir>/AppServer/logs/<server>
directory,
where
<WebSphere_Dir>
is
the
directory
where
IBM
WebSphere
Application
Server
is
installed,
and
<server>
is
the
name
of
the
application
server
to
which
the
SLM
Administration
Server
or
the
SLM
Server
has
been
deployed:
v
The
standard
output
log
is
SystemOut.log.
v
The
standard
error
log
is
SystemErr.log.
Viewing
Product
Logs
The
IBM
Tivoli
Service
Level
Advisor
message
logs
can
be
viewed
in
two
ways:
v
Use
the
standard
text
file
viewer
for
your
operating
system.
Message
and
trace
logs
in
the
default
IBM
Tivoli
Service
Level
Advisor
ASCII
output,
in
the
ASCII
output
generated
from
the
XML
Log
Viewer,
and
the
XML
and
HTML
formatted
logs
can
be
viewed
using
a
text
viewer:
–
For
UNIX
systems,
use
the
tail
–f
<filename>
command.
–
For
Windows
systems,
use
your
preferred
text
editor,
such
as
Notepad.v
Use
the
standard
HTML
browser
for
your
operating
system.
Use
the
XML
Log
Viewer
to
generate
HTML
log
files
and
view
them
using
a
standard
Web
browser.
Tivoli
applications
support
a
common
XML
format
in
which
message
and
trace
records
are
written.
The
XML
Log
Viewer
shipped
with
IBM
Tivoli
Service
Level
Advisor
processes
logs
in
this
format
and
converts
the
log
records
into
ASCII
or
HTML
for
presentation.
Message
and
trace
records
produced
by
several
products
can
be
correlated
and
filtered
according
to
a
time
window,
severity
or
trace
level,
thread
ID,
component,
and
various
other
fields.
It
is
important
to
note
that
the
XML
log
viewer
requires
the
specific
XML
format
of
the
Tivoli
logs.
XML
files
that
are
not
in
the
Tivoli
standard
format
cannot
be
processed
by
the
XML
log
viewer.
Use
the
XML
viewer
the
same
way
as
other
IBM
Tivoli
Service
Level
Advisor
commands
and
utilities.
See
the
Command
Reference
for
details
on
using
this
viewer
utility.
Message
Logging
This
section
describes
the
message
log
format
and
how
to
view
message
information.
10
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
The
Message
Log
Format
Each
message
log
contains
a
list
of
messages
reported
in
the
same
format.
The
format
of
the
message
log
varies
depending
on
the
specific
message
file.
For
IBM
Tivoli
Service
Level
Advisor,
three
general
formats
exist:
v
Default
ASCII
logs
v
ASCII
logs
generated
from
the
XML
Log
Viewer
v
HTML
logs
generated
from
the
XML
Log
Viewer
The
XML
formatted
for
log
files
is
a
fourth
format
but
is
intended
for
use
with
the
XML
Log
Viewer,
not
as
a
viewable
log
file.
When
viewing
the
default
message
logs
msgTSLAn.log
in
a
text
format,
the
output
contains
the
following
components,
as
listed
in
Table
6:
Table
6.
Components
of
the
message
log
format
Field
Description
Example
Date
The
year,
month,
and
day
that
the
message
was
generated.
2004-02-20
Time
Stamp
The
time
of
day
that
the
message
was
generated
13:56:59:321
Server
The
machine
that
is
running
the
IBM
Tivoli
Service
Level
Advisor
component
that
generated
the
message
yourComputer.hostname.com
Message
ID
The
code
that
uniquely
identifies
the
message
DYKAL3000I
Message
text
Textual
information
regarding
the
message
Creating
Datasource
for
sdc.
This
format
is
static
based
on
the
IBM
Tivoli
Service
Level
Advisor
installed
logging
configurations.
When
viewing
the
ASCII
or
HTML
logs
generated
by
the
XML
Log
Viewer,
the
format
of
the
logs
varies
depending
on
the
column
fields
specified
in
the
query
string.
See
the
description
of
the
viewer
utility
in
the
Command
Reference
for
the
description
of
each
field
for
log
files
generated
through
the
XML
Log
Viewer.
In
both
formats
the
fields
displayed
are
in
the
order
in
which
they
were
specified
within
the
query
string.
For
HTML
output
each
column
field
contains
a
column
header
indicating
the
field
name.
Viewing
Product
Messages
From
the
Message
ID
that
you
obtain
by
viewing
the
message
logs,
you
can
retrieve
additional
information
about
each
message,
either
by
referring
to
the
Messages
document,
or
by
viewing
messages
as
part
of
the
online
user
assistance.
Using
the
Online
Task
Assistant
When
in
the
Task
Assistant,
all
IBM
Tivoli
Service
Level
Advisor
messages
can
be
viewed
by
clicking
on
the
Message
Index
icon
and
opening
the
DYK
section.
Click
on
the
specific
message
ID
for
information
on
that
message.
Chapter
1.
Message
and
Trace
Logging
11
Understanding
the
Message
Format
The
Tivoli
Message
Standard
specifies
the
unique
message
identification
numbers
and
message
help
content
fields
for
messages
issued
from
a
Tivoli
component
or
application.
It
provides
a
consistent
and
meaningful
way
for
identifying
messages
across
all
Tivoli
products.
All
messages
following
this
standard
have
the
following
elements:
v
A
message
ID
v
Message
text
The
Message
ID
All
messages
must
have
message
IDs.
These
IDs
are
used
to
uniquely
identify
messages
for
service
and
reference
purposes.
The
Tivoli
Message
ID
format
is
XXXYY####Z,
and
includes
the
following
components:
XXX
The
required
product
component
prefix.
For
IBM
Tivoli
Service
Level
Advisor,
the
prefix
is
DYK.
YY
The
optional
subsystem
code.
This
subsystem
code
can
contain
only
alphabetic
characters.
It
can
be
from
0
to
2
characters.
Each
functional
component
of
IBM
Tivoli
Service
Level
Advisor
has
an
assigned
subsystem
code
that
can
assist
IBM
Customer
Support
in
isolating
the
source
of
a
reported
problem.
####
The
required
message
number.
This
number
is
unique
within
each
component
and
subsystem
(XXXYY).
It
contains
only
numeric
characters.
The
message
number
is
4
digits
in
length,
for
example:
0009,
0053,
2001.
Z
The
required
severity
code
indicator.
The
Tivoli
Message
Standard
supports
the
following
severity
codes:
v
I
(informational):
Informational
messages
provide
users
with
information
or
feedback
about
normal
events
that
occurred
or
are
occurring,
or
request
information
from
users
in
cases
where
the
outcome
is
not
negative,
regardless
of
the
response.
Examples:
"The
status
request
is
processing."
"The
files
were
successfully
transferred."
"Do
you
want
to
save
your
output
in
file
a
or
in
file
b?"
v
W
(warning):
Warning
messages
indicate
that
potentially
undesirable
conditions
occurred
or
might
occur,
but
the
program
can
continue.
Warning
messages
often
ask
users
to
make
decisions
before
processing
continues.
Examples:
"A
requested
resource
is
missing.
Processing
will
continue."
"A
file
already
exists
with
the
same
name.
Do
you
want
to
overwrite
this
file?"
v
E
(error):
Error
messages
indicate
problems
that
require
intervention
or
correction
before
the
program
can
continue.
Examples:
"The
specified
file
could
not
be
found."
"You
are
out
of
space
on
the
x
drive.
The
file
cannot
be
saved
to
this
drive."
12
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
The
Message
Text
All
messages
contain
message
text,
one
or
more
sentences
that
explain
the
reason
for
the
message,
possible
causes,
and
recommended
user
actions.
The
message
might
include
unique
actions
for
operators,
administrators,
or
IBM
customer
support.
For
example,
the
following
shows
the
message
ID,
the
message
text,
and
appropriate
response
information:
DYKSD2008E:
An
error
occurred
while
attempting
to
delete
a
database
record
that
has
one
or
more
dependents.
Explanation:
An
attempt
was
made
to
delete
a
database
record
containing
data
required
by
other
database
records.
Database
records
that
contain
data
required
by
other
database
records
cannot
be
deleted.
System
Action:
Operator
Response:
Report
this
problem
to
customer
support.
Administrator
Response:
Programmer
Response:
Level
3
Support:
The
user
attempted
to
delete
a
row
for
which
there
are
associated
rows
in
other
tables.
Trace
Logging
This
section
provides
more
details
on
trace
logging,
including
available
trace
loggers,
enabling
tracing
for
groups
and
subcomponents,
enabling
tracing
for
SLM
Server,
SLM
Administrative
Console,
and
SLM
Reports
environments,
and
configuring
tracing
levels.
Note:
Trace
logging
is
typically
used
for
detailed
problem
determination,
and
by
default
is
enabled
at
level
1.
Additional
tracing
should
be
enabled
only
at
the
request
of
IBM
customer
support.
Setting
Tracing
Levels
in
the
SLM
Server
Environment
By
default,
tracing
is
enabled
and
set
to
trace
at
level
1,
which
covers
basic
code
flow.
Adjust
the
level
of
logging
in
the
SLM
Server
environment
by
doing
the
following
steps:
1.
At
a
command
prompt,
navigate
to
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed,
and
run
the
following
command
to
setup
the
SLM
environment:
v
For
Windows
systems:
slmenv.bat
v
For
UNIX
systems:
.
./slmenv.sh
2.
Issue
the
following
command
to
view
the
list
of
available
trace
loggers
and
any
associated
groups
of
loggers:
scmd
log
trace
-list
Use
the
component
logger
names
in
this
list
as
logger
names
for
the
trace
commands.
3.
From
the
list
of
logger
names,
issue
the
following
command
to
set
tracing
for
each
individual
logger
or
group
of
loggers
(see
Table
7
on
page
14
for
examples
of
enabling
each
logger):
scmd
log
trace
-g
[<group>/<subcomponent>]
-set
isLogging=true
Chapter
1.
Message
and
Trace
Logging
13
Turning
off
Tracing
To
turn
off
tracing,
specify
the
isLogging
parameter
with
a
value
of
false.
For
example:
scmd
log
trace
-g
[<group>/<subcomponent>]
-set
isLogging=false
Available
Trace
Loggers
Table
7
identifies
the
loggers
that
are
available
for
IBM
Tivoli
Service
Level
Advisor.
Table
7.
Trace
loggers
for
IBM
Tivoli
Service
Level
Advisor
Group
name
Subcomponent
Valid
for
the
following
servers:
dykal
adapter
ds
cli
cm
cfg
log
SLM
Server
SLM
Admininstration
Server
SLM
Reports
Server
dylws
SLM
Server
dyket
SLM
Server
SLM
Administration
Server
dykgu
SLM
Administration
Server
SLM
Reports
Server
dykitk
SLM
Server
SLM
Administration
Server
dykme
common
mem
scheduler
SLM
Server
SLM
Administration
Server
dykom
SLM
Server
dykrp
SLM
Reports
Server
dyksd
sdml
SLM
Server
SLM
Administration
Server
dyksl
SLM
Server
dykut
SLM
Server
SLM
Administration
Server
dykau
SLM
Server
SLM
Administration
Server
For
any
of
the
above
loggers
(except
for
dykgu),
to
enable
tracing
for
the
entire
group,
issue
the
following
command,
where
<logger>
is
the
logger
name:
scmd
log
trace
-g
<logger>
-set
isLogging=true
For
the
dykgu
and
dykrp
loggers,
see
“Setting
Tracing
Levels
in
SLM
Reports
and
SLM
Administration
Server
Environments”
on
page
15.
14
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Setting
Tracing
Levels
in
SLM
Reports
and
SLM
Administration
Server
Environments
To
control
logging
and
tracing
in
the
SLM
Reports
or
SLM
Administration
Server
environment,
use
the
logutil
utility.
This
utility
has
the
same
set
of
functions
as
the
scmd
log
commands.
Enabling
the
trace
might
not
occur
immediately,
but
occurs
after
the
configuration
service
notices
the
update.
Restarting
the
SLMAdmin
or
SLMReport
applications
from
the
WebSphere
Administrative
Console
or
restarting
the
respective
WebSphere
Application
Server
immediately
effects
the
change.
If
SLM
Reports
or
the
SLM
Administration
Server
is
running
on
the
same
machine
and
in
the
same
directory
as
the
SLM
Server,
tracing
is
enabled
for
all
environments.
See
Table
7
on
page
14
for
the
list
of
available
loggers.
By
default,
tracing
is
enabled
and
set
to
trace
at
level
1
(basic
code
flow).
Adjust
tracing
in
the
SLM
Reports
environment
by
doing
the
following
steps:
1.
At
a
command
prompt,
navigate
to
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed,
and
run
the
following
command
to
setup
the
SLM
environment:
v
For
Windows
systems:
slmenv.bat
v
For
UNIX
systems:
./slmenv.sh
2.
Use
the
logutil
command
to
set
tracing
for
each
individual
logger
or
group
of
loggers:
logutil
trace
-g
[<group>/<subcomponent>]
-set
isLogging=true
3.
Restart
the
WebSphere
Application
Server.
Turning
off
Tracing
To
turn
off
tracing,
specify
the
isLogging
parameter
with
the
value
false.
For
example:
logutil
trace
-g
[<group>/<subcomponent>]
-set
isLogging=false
Understanding
the
Trace
Log
Format
The
trace
log
contains
information
that
helps
you
trace
the
flow
of
execution
to
diagnose
problems.
Trace
log
information
includes
information
from
several
fields,
a
defined
in
Table
8:
Table
8.
Information
contained
in
the
trace
log
Field
Description
Example
Log
date
The
year,
month,
and
day
that
the
trace
entry
was
generated
2002-02-20
Log
timestamp
The
time
of
day
that
the
trace
entry
was
generated
13:56:59:321
Log
class
The
IBM
Tivoli
Service
Level
Advisor
class
generated
by
the
trace
entry
com.tivoli.managed.
spi.SLMServerAdapter
Log
method
The
class
method
in
which
the
trace
entry
was
generated
setName
Chapter
1.
Message
and
Trace
Logging
15
Table
8.
Information
contained
in
the
trace
log
(continued)
Field
Description
Example
Log
thread
The
Java
execution
thread
that
executed
the
method
Thread-0
Log
Server
The
machine
that
is
running
the
IBM
Tivoli
Service
Level
Advisor
component
that
generated
the
trace
entry
yourcomputer.hostname.com
Log
information
Text
information
regarding
the
trace
entry
Using
JVM
version
1.4.2.
Configuring
Filtering
Masks
Trace
information
is
classified
into
three
levels
of
information:
TYPE_LEVEL1
Exception
details,
any
unexpected
internal
errors,
or
important
state
information,
and
code
flow
TYPE_LEVEL2
Same
as
TYPE_LEVEL1,
plus
method
entry
and
exit
traces
and
certain
parameters
TYPE_LEVEL3
Same
as
TYPE_LEVEL2,
plus
lower
level
tracing
of
data
and
other
intermediate
tracing
points
The
following
trace
filters
are
defined
to
view
these
different
levels:
v
trcFilter.slm
is
used
to
view
all
three
levels
of
trace
messages.
This
is
set
to
TYPE_LEVEL1
and
is
assigned
to
all
trace
loggers
by
default.
v
trcFilter.slmlevel1,
the
default,
is
used
to
view
only
TYPE_LEVEL1
trace
messages.
v
trcFilter.slmlevel2
is
used
to
view
only
TYPE_LEVEL1
and
TYPE_LEVEL2
trace
messages.
v
trcFilter.slmlevel3
is
used
to
view
all
three
levels
of
trace
messages.
By
default,
all
components
of
IBM
Tivoli
Service
Level
Advisor
are
set
to
use
the
trcFilter.slm
filter.
To
change
the
filtering
for
all
SLM
components,
you
can
change
this
filter.
You
can
also
change
the
trace
level
on
individual
components
by
assigning
one
of
the
more
granular
filters
to
a
particular
trace
logger
(for
example,
trcFilter.slmlevel3).
For
example,
to
trace
level
1
and
level
2
messages
for
all
components,
change
the
mask
on
trcFilter.slm
by
issuing
the
following
command:
scmd
log
filter
trcFilter.slm
-set
"mask=TYPE_LEVEL1
TYPE_LEVEL2"
To
trace
only
level
2
messages
for
the
spi
component,
issue
the
following
command:
scmd
log
trace
-g
spi
-set
filterNames=trcFilter.slmlevel2
Note:
For
SLM
Reports
and
SLM
Administration
Server,
substitute
logUtil
for
scmd
log.
Note:
When
SLM
Reports,
the
SLM
Administration
Server,
and
the
SLM
Server
are
installed
together
on
the
same
machine,
they
share
configuration
data.
Any
logging
changes
are
seen
by
all
components.
16
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Audit
Logging
IBM
Tivoli
Service
Level
Advisor
provides
audit
capabilities
to
record
when
objects
are
created,
changed,
or
deleted.
These
actions
are
logged
for
customers,
realms,
schedules,
published
offerings,
schedule
customizations,
and
SLAs.
Information
about
re-evaluations,
adjudicating
violations,
component
expiration,
and
purging
of
intermediate
results
is
also
recorded
in
the
audit
logs.
When
a
change
to
one
of
these
objects
is
logged,
a
message
is
generated
that
includes
the
following
information:
v
The
type
of
operation
(create,
change,
or
delete)
v
The
identity
of
one
or
more
objects
that
are
involved
in
the
operation
v
The
identity
of
the
user
that
initiated
the
operation
v
The
date
that
the
operation
was
performed
When
an
action
is
logged
for
audit
purposes,
a
message
is
logged
to
several
places:
v
The
IBM
Tivoli
Service
Level
Advisor
message
log
v
An
audit
log
v
A
detailed
audit
log
that
includes
additional
information
about
the
affected
object
or
objects
By
storing
all
relevant
information,
you
have
the
flexibility
to
choose
the
level
of
detail
by
examining
the
proper
log.
View
these
logs
as
you
view
other
logs,
in
either
ASCII
or
XML
format.
The
audit
logs
are
kept
as
a
set
of
three
rotating
logs,
with
the
oldest
log
rotated
to
new
status
and
overwritten
when
filled.
The
following
log
files
are
used
for
auditing
in
addition
to
the
default
IBM
Tivoli
Service
Level
Advisor
message
log,
and
are
written
to
the
Tivoli
Common
Directory
along
with
other
product
logs:
v
auditTSLAy.log
and
auditTSLAXMLy.log,
which
contain
the
default
audit
information
(non-detailed)
v
auditDetailTSLAy.log
and
auditDetailTSLAXMLy.log,
which
contain
the
detailed
audit
information.
The
y
in
these
log
file
names
is
an
integer
denoting
one
of
the
three
rotating
log
files.
These
log
files
are
located
in
the
Tivoli
Common
Directory
for
the
SLM
Server
and
SLM
Administration
Server
as
follows:
v
On
the
SLM
Server
machine,
in
folder
/DYK/SLMServer
v
On
the
SLM
Administration
Server
machine,
in
folder
/DYK/SLMAdmin
Chapter
1.
Message
and
Trace
Logging
17
18
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
This
chapter
provides
some
hints
and
tips
on
troubleshooting
problems
that
you
might
encounter
during
installation
and
configuration
of
IBM
Tivoli
Service
Level
Advisor.
The
following
key
troubleshooting
areas
are
addressed:
v
“Installing
DB2
Universal
Database”
v
“Updating
the
JDBC
Level”
on
page
20
v
“Creating
SLM
Databases”
on
page
21
v
“Configuring
ODBC
Data
Sources”
on
page
25
v
“Installing
IBM
Tivoli
Service
Level
Advisor”
on
page
23
v
“Installing
SLM
Reports
or
SLM
Administration
Server”
on
page
24
v
“Installing
and
Configuring
the
Registration
and
Process
ETLs”
on
page
26
v
“Installing
and
Configuring
WebSphere
Application
Server”
on
page
20
v
“System
Startup”
on
page
27
v
“Accessing
SLM
Reports”
on
page
28
v
“Uninstalling
IBM
Tivoli
Service
Level
Advisor”
on
page
30
Installing
DB2
Universal
Database
This
section
includes
troubleshooting
problems
that
you
might
encounter
related
to
installing
and
configuring
IBM
DB2
Universal
Database
Enterprise
Edition
on
the
machine
where
you
locate
the
Tivoli
Data
Warehouse
database,
or
related
to
installing
and
configuring
DB2
Universal
Database
on
one
or
more
machines
containing
components
of
IBM
Tivoli
Service
Level
Advisor
(SLM
Server,
SLM
Administration
Server,
SLM
Reports,
the
SLM
Database,
or
the
SLM
Measurement
Data
Mart).
For
more
detailed
troubleshooting
information
related
to
installing
DB2
Universal
Database,
refer
to
IBM
DB2
Universal
Database
Message
Reference,
Volume
1,
Chapter
6,
″DBI
Messages.″
Instance
Creation
Failed
During
DB2
Universal
Database
Installation
on
UNIX
Systems
If
you
receive
the
message
that
the
DB2
instance
creation
failed
during
installation,
create
the
instance
manually
after
the
installation
completes.
To
create
an
instance
manually,
do
the
following
steps:
1.
Ensure
that
the
database
administrator
account
was
created
and
that
it
belongs
to
the
proper
group.
2.
Navigate
to
the
following
directory,
depending
on
your
operating
system
platform:
v
For
AIX
systems,
/usr/lpp/db2_07_01/instance
v
For
Solaris
systems:
/opt/IBMdb2/V7.1/instance
v
For
Linux
systems:
/usr/IBMdb2/V7.1/instance
v
For
HP
systems:
/opt/IBMdb2/V7.1/instance
3.
Run
the
following
command,
where
<db2admin_name>
is
the
name
of
the
database
administrator
account,
and
<new_instance_name>
is
the
name
of
the
new
instance,
which
should
be
identical
to
the
<db2admin_name>
parameter:
db2icrt
-a
{SERVER
|
CLIENT}
-u
<db2admin_name>
<new_instance_name>
©
Copyright
IBM
Corp.
2002,
2004
19
For
further
information,
see
the
IBM
DB2
Universal
Database
Command
Reference,
Version
7.
Updating
the
JDBC
Level
During
installation
of
IBM
Tivoli
Service
Level
Advisor,
the
JDBC
level
is
automatically
upgraded
to
the
required
2.0
level.
You
might
need
to
verify
the
current
level
of
JDBC
to
ensure
that
you
are
running
with
JDBC
level
2.0,
and
if
not
set,
you
need
to
upgrade
this
manually.
See
Getting
Started
for
information
on
updating
the
JDBC
level
for
DB2
Universal
Database.
Installing
and
Configuring
WebSphere
Application
Server
This
section
includes
troubleshooting
problems
that
you
might
encounter
while
installing
and
configuring
WebSphere
Application
Server.
Installing
on
Linux
Systems
When
installing
IBM
WebSphere
Application
Server
on
a
Linux
system,
if
the
/etc/issue
file
is
modified
(for
example,
to
conform
with
corporate
security
guidelines)
prior
to
installing
IBM
WebSphere
Application
Server,
you
might
encounter
the
following
(or
similar)
error
message:
Operating
System
Level
Check
A
supported
operating
system
was
not
detected.
Installation
may
not
be
successful.
Ignore
this
message
and
continue
with
the
installation.
To
avoid
this
message,
do
not
modify
the
/etc/issue
file
before
installing
IBM
WebSphere
Application
Server.
WebSphere
Administration
Console
Unavailable
after
Installing
on
AIX
Systems
If,
after
installing
IBM
WebSphere
Application
Server
on
an
AIX
machine,
you
are
unable
to
access
the
WebSphere
Administrative
Console,
it
is
possible
that
there
was
an
error
during
its
installation.
Check
the
installAdminConsole.log
file
in
the
/logs
directory
where
you
installed
IBM
WebSphere
Application
Server
for
errors.
You
might
receive
this
error
if
you
did
not
have
enough
temporary
space
available
in
the
/tmp
directory
before
installing.
Refer
to
the
WebSphere
Application
Server
Release
Notes
for
details,
but
you
might
need
between
35MB
and
100MB
of
temporary
space
available
to
install
successfully.
If
you
plan
to
upgrade
applications
from
an
earlier
version
of
IBM
WebSphere
Application
Server,
ensure
that
there
is
enough
space
for
application
objects.
As
a
rough
guideline,
plan
for
space
equal
to
110%
of
the
size
of
the
following
application
objects:
v
For
Version
3.5:
The
size
of
application
JAR,
WAR,
and
servlet
files
v
For
Version
4.0:
The
size
of
enterprise
application
EAR
files
After
ensuring
adequate
temporary
space,
manually
install
the
WebSphere
Administrative
Console
using
the
wsAdmin
script
in
the
/bin
directory.
Errors
while
Enabling
WebSphere
Security
When
using
the
local
operating
system
user
registry
for
authentication
in
WebSphere
Application
Server,
you
must
select
a
user
ID
(that
WebSphere
refers
to
20
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
as
the
server
ID)
that
is
used
to
authenticate
users.
This
server
ID
must
have
Administrator
privileges
and
cannot
be
the
same
as
the
machine
hostname.
If
this
user
ID
matches
the
machine
name,
you
receive
errors
when
you
attempt
to
enable
security.
Having
a
server
ID
means
that
a
user
has
special
privileges
when
calling
protected
internal
methods.
Usually
this
server
ID
and
password
are
used
to
log
into
the
WebSphere
Administrative
Console
after
security
is
turned
on.
You
can
use
other
user
names
to
log
in
if
those
names
have
been
given
Administrator
level
authority.
When
security
is
enabled
in
the
product,
this
server
ID
and
password
are
authenticated
with
the
registry
during
product
startup.
If
authentication
fails,
then
the
WebSphere
Application
Server
does
not
come
up.
So
it
is
important
to
choose
a
server
ID
and
password
that
do
not
expire
or
change
often.
If
the
product
server
user
ID
or
password
need
to
be
changed
in
the
registry,
ensure
that
the
changes
are
performed
when
all
of
the
product
servers
are
up
and
running.
After
the
changes
are
completed
in
the
registry,
you
can
then
change
the
user
ID
and
password
information.
Save
your
changes,
then
stop
and
restart
all
of
the
servers
so
that
the
product
can
use
the
new
user
ID
or
password.
If
there
are
problems
starting
the
product
because
of
authentication
problems
(that
cannot
be
fixed),
disable
security
before
starting
the
server.
To
avoid
this
step,
make
sure
that
your
changes
are
validated
in
the
Global
Security
panel.
Once
the
server
is
up,
change
the
server
ID
and
password
information
and
enable
WebSphere
security.
See
the
details
for
enabling
support
for
WebSphere
security
in
Chapter
5
of
Getting
Started,
as
well
as
your
WebSphere
Application
Server
documentation.
Creating
SLM
Databases
This
section
includes
troubleshooting
problems
that
you
might
encounter
while
creating
the
SLM
Database
and
the
SLM
Measurement
Data
Mart
for
use
with
IBM
Tivoli
Service
Level
Advisor.
If
the
creation
of
the
SLM
Database
or
the
SLM
Measurement
Data
Mart
fails,
check
the
log
files
that
are
generated
during
the
database
installation
(refer
to
information
on
checking
database
creation
logs
and
tables
in
Getting
Started).
These
logs
contain
specific
DB2
Universal
Database
messages
that
indicate
the
exact
nature
of
the
database
creation
error.
Note:
The
database
creation
logs
write
over
any
existing
log
information
rather
than
append
to
existing
log
information.
Database
Creation
Fails
If
the
creation
of
the
SLM
databases
fails
to
complete
successfully
(either
by
using
the
Create
Databases
wizard
in
the
LaunchPad
or
by
manually
running
the
database
creation
scripts
(dyk_cat_dbinst
or
dyk_dm_dbinst),
the
database
creation
log
files
dyk_cat_dbinst_err.log
or
dyk_dm_dbinst_err.log
might
contain
errors
indicating
that
the
database
cannot
be
created.
These
log
files
are
located
in
ther
temporary
directory
for
your
machine
(the
%TEMP%
environment
variable
on
Windows
systems,
or
the
/tmp
directory
on
UNIX
systems).
The
following
errors
can
occur
during
database
creation:
v
If
you
are
attempting
to
create
SLM
databases
on
a
remote
OS/390
machine
by
running
the
installation
program
from
a
UNIX
machine,
the
UNIX
machine
where
you
run
the
installation
program
must
have
the
Server
version
of
DB2
Universal
Enterprise
Edition
installed.
You
cannot
run
the
installation
program
in
this
case
on
a
machine
that
only
has
a
DB2
Universal
Database
client
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
21
installed,
because
certain
files
are
needed
in
the
DB2
Server
installation
for
remote
database
creation
in
the
OS/390
environment.
You
should
verify
that
the
UNIX
machine
where
you
are
running
the
installation
program
has
DB2
Server
installed
before
continuing
to
diagnose
a
database
creation
failure.
v
SQL1005N:
The
database
alias
<dbname>
already
exists
in
either
the
local
database
directory
or
the
system
database
directory.
Before
you
attempt
to
create
the
database
again,
do
the
following:
1.
Initiate
a
DB2
command
session
and
run
the
following
command
to
view
all
cataloged
databases:
db2
list
db
directory
2.
Verify
that
DYK_CAT
and
DYK_DM
are
included
in
the
listing.
For
each
database
that
does
not
appear
in
the
listing,
do
the
following
steps:
Note:
The
above
statement
assumes
that
the
database
scripts
were
not
modified
and
that
the
default
database
names
are
used.
a.
Run
the
following
command,
where
<missing_db>
is
the
missing
database
name
and
<any_db>
is
a
dummy
catalog
entry:
db2
catalog
db
<missing_db>
as
<any_db>
b.
Run
the
following
command
to
see
your
new
catalog
entry
<any_db>:
db2
list
db
directory
c.
Run
the
following
command
to
drop
the
database:
db2
drop
db
<any_db>
d.
If
the
DB2
DROP
command
fails,
then
run
the
following
commands:
db2
uncatalog
db
<any_db>
db2
terminate
3.
Attempt
to
recreate
the
SLM
databases
by
either
running
the
Create
Databases
wizard
in
the
LaunchPad,
or
manually
run
the
database
creation
scripts.v
SQL1032N:
No
start
database
manager
command
was
issued.
SQLSTATE=57019
This
error
usually
indicates
that
the
database
manager
is
currently
stopped.
Start
a
DB2
command
prompt
and
issue
the
following
command:
db2start
Note:
If
the
database
creation
script
failed
and
the
creation
log
contains
the
above
message,
you
must
allow
the
database
creation
script
to
drop
the
database
before
recreating
it
again.
v
SQL1403N:
The
user
name
or
password
supplied
is
incorrect.
SQLSTATE=08004
This
error
indicates
that
either
the
user
name
or
the
password
used
in
the
database
creation
is
incorrect,
or
the
user
name
is
not
an
authorized
user
on
this
system.
Check
with
your
database
administrator
for
the
proper
authorization
and
group
membership.
v
SQL1198N:
This
command
is
not
supported
in
the
current
downlevel
client-server
configuration.
This
error
might
occur
if
you
are
attempting
to
create
DB2
databases
on
a
DB2
Universal
Database
version
8
server
from
a
DB2
Universal
Database
version
7
client.
This
configuration
is
not
supported.
In
this
scenario
the
DB2
client
must
also
be
at
version
8.
The
following
statement
is
from
the
Release
Notes
for
IBM
DB2
Universal
Database
Enterprise
Edition:
There
is
no
Version
7
client
support
in
a
Version
8
partitioned
database
environment
for
the
SET
CLIENT
CONNECT_NODE
or
ATTACH_NODE
options
or
for
a
utility
flow
22
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
that
requires
an
ATTACH
command.
If
you
want
to
work
with
clients
using
either
of
these
partitioned
database
options
or
a
utility
flow
requiring
an
ATTACH
command,
you
must
use
a
DB2
Universal
Database
Version
8
client.
If
you
have
multiple
logical
nodes
in
a
partitioned
database
environment,
you
must
use
a
Version
8
client.
Upgrade
your
DB2
client
to
version
8
to
create
these
databases.
Recovering
from
Cataloging
a
Local
Database
as
Remote
While
installing
IBM
Tivoli
Service
Level
Advisor,
the
wizard
prompts
you
for
information
about
the
SLM
Database
and
the
SLM
Measurement
Data
Mart,
and
the
wizard
then
attempts
to
access
the
database
to
verify
the
connection.
If
you
specify
the
database
as
remote
when
it
is
actually
local,
the
IBM
Tivoli
Service
Level
Advisor
install
program
will
recatalog
the
local
database
as
a
remote
database,
and
the
connection
attempt
will
fail.
If
you
restart
the
install
wizard
before
manually
recataloging
the
database,
you
will
continue
to
fail
the
database
connection.
Before
restarting
the
install
program,
correct
this
problem
by
doing
the
following
steps:
1.
Start
up
a
DB2
command
prompt.
2.
Issue
the
following
command
to
manually
uncatalog
the
database,
where
<database_name>
is
the
name
of
the
database
that
was
incorrectly
specified
as
remote,
such
as
dyk_cat:
db2
uncatalog
db
<database_name>
3.
Catalog
the
database
again
without
specifying
a
node
name,
by
issuing
the
following
command:
db2
catalog
db
<database_name>
4.
Issue
a
terminate
command:
db2
terminate
5.
After
completing
the
steps
above,
restart
the
installation
program.
Installing
IBM
Tivoli
Service
Level
Advisor
This
section
includes
troubleshooting
problems
that
you
might
encounter
while
installing
any
of
the
installation
options
of
IBM
Tivoli
Service
Level
Advisor.
Blank
Install
Window
or
Incomplete
Text
During
the
install
of
IBM
Tivoli
Service
Level
Advisor,
if
you
encounter
a
blank
install
window
or
a
window
that
contains
incomplete
text,
resize
the
window.
This
causes
the
window
to
refresh
itself
and
display
all
of
the
text.
Install
Screen
Fonts
Not
Readable
If
you
are
installing
on
an
AIX
machine
in
the
de_DE
language,
you
might
find
that
the
fonts
displayed
in
the
installation
windows
are
not
readable.
To
change
this,
do
the
following:
1.
Copy
the
contents
of
the
IBM
Tivoli
Service
Level
Advisor
product
CD
to
a
temporary
directory
on
your
machine.
2.
Rename
the
following
file:
java/aix4-r1/jre/lib/font.properties.UTF8
to
the
following
name:
java/aix4-r1/jre/lib/font.properties.UTF8.bak
3.
Run
the
installation
from
the
temporary
directory
on
your
machine.
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
23
Cleaning
up
Temporary
ISMP
Directories
After
installing
IBM
Tivoli
Service
Level
Advisor,
you
might
find
one
or
more
directories
under
your
temporary
directory
(/tmp
on
UNIX
systems,
or
%TEMP%
on
Windows
systems),
with
a
name
prefix
of
ismp*
(such
as
ismp001,
ismp002,
ismp003,...
depending
on
how
many
times
you
perform
an
installation).
After
the
installation
completes,
manually
remove
these
directories
to
conserve
space
on
your
system.
Receive
DYKIN0005E
or
DYKIN0088E
Errors
Connecting
to
SLM
Databases
During
the
installation
of
IBM
Tivoli
Service
Level
Advisor,
the
installation
wizard
prompts
you
for
connection
information
on
the
SLM
Database
and
SLM
Measurement
Data
Mart,
and
then
attempts
to
connect
to
the
databases
(which
should
have
been
created
prior
to
starting
the
Install
Product
step
from
the
LaunchPad.
Refer
to
information
on
creating
IBM
Tivoli
Service
Level
Advisor
application
databases
in
Getting
Started).
If
the
attempt
to
connect
to
the
databases
fails,
the
following
error
message
is
received:
DYKIN0005E
Unable
to
make
connection
with
the
specified
database.
Verify
that
the
SLM
Database
and
the
SLM
Measurement
Datamart
have
been
correctly
created.
This
message
might
be
received
if
there
was
a
problem
creating
the
database,
or
if
any
of
the
following
problems
occurred:
v
An
error
occurred
in
the
input
data
to
the
installation
wizard,
such
as
an
incorrect
server
name,
DB2
password,
or
port
number.
v
The
DB2
server
might
be
down
at
the
time
the
installation
wizard
attempts
the
connection.
v
There
is
no
connectivity
with
the
database
server.
v
The
file
db2java.zip
might
not
be
included
in
the
CLASSPATH
system
variable,
or
your
system
might
also
have
a
User
CLASSPATH
variable
which
overrides
the
system
CLASSPATH
variable
setting.
Refer
to
Getting
Started
for
information
about
verifying
that
db2java.zip
is
in
your
CLASSPATH.
You
might
need
to
investigate
each
of
these
areas
for
the
cause
of
the
failure,
correct
the
problem,
then
click
Back
on
the
installation
wizard
page
and
attempt
the
connection
again.
Installing
SLM
Reports
or
SLM
Administration
Server
This
section
includes
troubleshooting
problems
that
you
might
encounter
while
installing
the
SLM
Reports
or
SLM
Administration
Server
options
of
IBM
Tivoli
Service
Level
Advisor.
Installing
with
the
IIS
Service
If
you
are
planning
to
install
on
a
Windows
operating
system
that
has
the
IIS
service
installed,
disable
this
service
before
installing
IBM
WebSphere
Application
Server.
This
enables
the
IBM
HTTP
Server
installed
by
WebSphere
to
use
port
80.
SLM
reports
and
the
SLM
Administrative
Console
can
then
be
viewed
using
this
port.
24
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Installation
Fails
because
the
Directory
Service
is
not
Started
If
you
are
using
Lightweight
Directory
Access
Protocol
(LDAP)
or
another
directory
service
to
manage
users
in
your
environment,
it
must
be
up
and
running
when
you
install
or
uninstall
the
SLM
Reports
or
SLM
Administration
Server
options
of
IBM
Tivoli
Service
Level
Advisor
into
the
WebSphere
Application
Server
environment.
This
problem
is
not
detected
during
the
installation
or
uninstallation
process,
but
the
process
fails
because
the
directory
service
is
not
operational,
which
prevents
the
installation
wizard
from
detecting
if
the
WebSphere
Application
Server
is
started.
Check
the
log
files
for
information
about
the
cause
of
the
fail,
verify
that
the
directory
service
is
started,
and
attempt
the
installation
again.
Configuring
ODBC
Data
Sources
This
section
includes
steps
to
verify
ODBC
data
source
creation
and
troubleshooting
problems
that
you
might
encounter
while
configuring
ODBC
data
sources.
Configuring
ODBC
data
sources
is
a
manual
step
that
is
performed
as
part
of
the
installation
procedure
for
IBM
Tivoli
Service
Level
Advisor.
See
Getting
Started
for
more
information
on
configuring
ODBC
data
sources.
Verifying
Successful
ODBC
Data
Source
Creation
To
verify
creation
of
ODBC
Data
Sources
for
IBM
Tivoli
Service
Level
Advisor
databases,
from
a
DB2
command
line
on
the
machine
where
the
Tivoli
Data
Warehouse
control
server
is
located,
issue
the
following
command:
db2
list
system
odbc
data
sources
The
output
of
the
above
command
lists
the
ODBC
data
sources
DYK_CAT
and
DYK_DM.
If
either
is
missing,
run
the
SLM
ODBC
data
source
creation
scripts
or
create
the
data
sources
manually
as
described
in
Getting
Started.
To
verify
that
the
ODBC
data
sources
are
created
correctly,
issue
the
following
commands
from
a
DB2
command
prompt,
where
<datasource_name>
is
DYK_CAT
or
DYK_DM,
<userid>
is
a
valid
DB2
user
name
and
<password>
is
a
valid
password
for
the
specified
user
name:
db2
connect
to
<datasource_name>
user
<userid>
using
<password>
If
you
receive
errors
when
connecting
to
the
ODBC
Data
Source
(such
as
a
SQL30081N
DB2
error),
verify
each
of
the
following
items:
v
The
port
number
or
service
name
of
the
database
node
must
be
the
correct
port
number
on
the
database
server
as
well
as
on
the
machine
creating
the
ODBC
Data
Source
(if
connecting
to
a
remote
machine).
The
SLM
ODBC
creation
scripts
have
a
default
port
value
of
50000.
If
this
port
number
is
not
correct
for
your
system,
you
will
not
be
able
to
connect
to
the
ODBC
data
source.
Refer
to
Getting
Started
for
more
information
on
configuring
ODBC
data
sources
and
about
changing
this
parameter
within
the
ODBC
creation
script.
To
configure
this
value
manually,
refer
to
Appendix
D
in
Getting
Started.
v
The
hostname
(remote
or
local)
is
a
valid
system
name
and
can
be
reached
by
the
system
containing
the
ODBC
data
source.
To
verify
that
the
hostname
can
be
reached,
issue
the
following
command,
where
<hostname>
is
the
hostname
used
when
creating
the
ODBC
data
source:
ping
<hostname>
To
reconfigure
the
hostname
used
by
the
ODBC
data
source,
issue
the
following
commands
from
a
DB2
command
line:
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
25
db2
uncatalog
node
<ODBC_node>
db2
uncatalog
db
<database_name>
db2
uncatalog
system
odbc
data
source
<datasource_name>
db2
terminate
Run
the
SLM
ODBC
creation
scripts
again,
or
configure
the
ODBC
data
source
manually,
as
described
in
Getting
Started.
Note:
This
procedure
assumes
that
you
did
not
modify
the
ODBC
node
names
in
the
SLM
ODBC
creation
scripts
or
the
database
names
in
the
SLM
ODBC
creation
scripts
or
the
SLM
database
creation
scripts.
Installing
and
Configuring
the
Registration
and
Process
ETLs
This
section
includes
troubleshooting
problems
that
you
might
encounter
while
installing
and
configuring
the
Registration
and
Process
ETLs
from
the
DYK
warehouse
pack.
Logging
in
to
the
Data
Warehouse
Center
If
you
launch
the
DB2
Data
Warehouse
Center
(from
the
DB2
Control
Center,
click
Tools
–>
Data
Warehouse
Center)
but
you
are
unable
to
log
in
to
the
Data
Warehouse
Center,
restart
the
following
two
warehouse
services
from
the
Services
control
panel:
v
Warehouse
Logger
v
Warehouse
Server
This
enables
the
services
to
reconnect
to
the
TWH_MD
database
which
is
disconnected
if
the
Tivoli
Data
Warehouse
database
server
was
stopped.
Incorrect
level
of
db2java.zip
If
you
install
or
migrate
DB2
fix
pack
7
or
higher
after
you
have
upgraded
Tivoli
Data
Warehouse
version
1.1
to
Fix
Pack
2,
you
will
not
have
the
correct
level
of
db2java.zip
in
the
<TWH_DIR>/tools/bin
directory.
This
can
cause
problems
during
installation
of
warehouse
packs.
To
correct
this,
manually
copy
<DB2_Dir>/SQLLIB/java12/db2java.zip
into
<TWH_Dir>/tools/bin/
directory,
replacing
the
copy
of
db2java.zip
in
that
folder.
Then
follow
the
procedures
in
the
Tivoli
Data
Warehouse
documentation
to
uninstall
the
warehouse
pack,
and
retry
the
installation
of
the
ETL.
Note
that
this
only
applies
to
version
1.1
of
Tivoli
Data
Warehouse.
Could
not
execute/locate
DB2
command
The
install
log
for
Tivoli
Data
Warehouse
might
contain
the
following
error
message:
CDWIC0024E
Could
not
execute/locate
DB2
command!!!
This
is
caused
by
the
PATH
statement
being
too
long
to
include
the
<DB2_Install_Dir>\sqllib\bin
and
<DB2_Install_Dir>\sqllib\function
directories
in
the
path.
This
might
be
caused
by
a
longer
than
usual
<TEMP>
temporary
directory
location,
such
as
C:\Documents
and
Settings\<user_name>\Local
Settings\Temp,
where
<user_name>
is
the
user
name
with
which
you
signed
onto
the
system.
This
temporary
directory
path
string
might
be
repeated
many
times
in
the
PATH=
statement,
and
the
resulting
string
is
too
large
to
include
the
\sqllib\function
and
\sqllib\bin
directories.
As
a
result,
the
test
of
the
DB2
26
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
command
path
fails
and
the
install
of
the
DYK
application
package
fails.
You
can
verify
this
by
looking
earlier
in
the
log
file
for
the
PATH
statement.
You
can
resolve
this
problem
by
modifying
your
PATH
statement
to
include
the
<DB2_Install_Dir>\sqllib\bin
and
<DB2_Install_Dir>\sqllib\function
directories
at
the
front
of
the
PATH
statement,
as
well
as
modify
the
%TEMP%
system
variable
to
a
shorter
temporary
path,
such
as
C:\Temp.
Reboot
the
system
for
the
changes
to
take
effect,
and
attempt
the
install
of
the
DYK
application
package
again.
System
Startup
This
section
includes
troubleshooting
problems
that
you
might
encounter
related
to
starting
up
the
services
and
components
of
the
SLM
solution.
Server
Hostname
is
Not
Fully
Qualified
If
you
receive
either
of
the
following
messages,
you
might
need
to
change
your
system
configuration
to
return
fully
qualified
hostnames:
v
As
a
result
of
invoking
an
scmd
command:
DYKAL2030E
Unable
to
connect
to
the
Command
Line
Interface
service
on
port
9990.
v
You
find
the
following
messages
in
the
msgTSLAn.log
(located
in
the
Tivoli
Common
Directory):
DYKAL0009E
The
server
host
name
<host
name>
is
not
a
fully
qualified
host
name.
DYKAL1020I
Component
startup
activities
have
completed:0
started,
0
timed
out,
0
failed.
These
errors
can
occur
if
the
SLM
Server
configuration
data
could
not
be
loaded
and
required
SLM
Server
services
are
not
started.
In
the
Tivoli
Common
Directory,
check
the
msgTSLAn.log
files
and
verify
that
you
see
a
message
near
the
bottom
of
the
log,
telling
you
that
all
services
were
started
successfully
with
no
errors.
This
situation
occurs
if
the
machine
where
the
SLM
Server
is
installed
is
no
longer
known
by
the
fully
qualified
hostname.
In
this
condition,
the
server
does
not
properly
read
necessary
configuration
data
that
is
associated
with
the
fully
qualified
hostname
of
the
machine,
and
necessary
services
is
not
started.
Machines
on
which
you
install
the
SLM
Server,
SLM
Administration
Server,
and
SLM
Reports
must
be
configured
so
that
their
hostnames
resolve
to
fully
qualified
names.
Refer
to
Getting
Started
for
more
information
on
configuring
your
machine
to
return
fully
qualified
host
names.
SLM
Server
Startup
Cannot
Connect
to
SLM
Databases
If
the
startup
of
the
SLM
Server
is
halted,
and
you
receive
the
following
message
in
the
msgTSLAn.log,
you
might
be
having
problems
with
the
SLM
Server
connecting
to
the
SLM
Database
or
SLM
Measurement
Data
Mart:
DYKAL1054E
Component
yourmachine.some.company.com:DS:1
failed
startup
with
the
following
error:DYKAL3002E
An
error
occurred
for
sdc
during
DataSource
creation.
This
error
might
also
occur
if
you
execute
the
CLI
command
scmd
list,
and
only
the
rcc,
log,
and
slm
bundles
are
reported
as
available.
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
27
This
error
indicates
that
connection
to
one
or
both
of
the
IBM
Tivoli
Service
Level
Advisor
databases
is
not
possible.
Examine
the
related
messages
in
the
log
to
determine
the
root
cause
of
the
failure.
The
most
common
cause
of
this
type
of
problem
is
the
following:
v
The
db2start
command
(for
distributed
platforms;
if
DB2
Universal
Database
is
started
on
z/OS
or
OS/390
operating
systems,
consult
the
documentation
for
start
procedures)
was
not
issued
on
the
database
server.
You
might
see
the
following
message
in
the
SLM
Server
stderr
or
the
msgTSLAn.log
files
on
the
machine
running
the
SLM
Server:
DYKAL3014E
Error
connecting
to
the
database.
Reason:
[IBM][CLI
Driver]
SQL1032N
No
start
database
manager
command
was
issued.
SQLSTATE=57019
Verify
that
a
db2start
command
(for
distributed
platforms)
has
been
issued
on
the
database
server.
See
the
DB2
Universal
Database
documentation
for
more
information
on
starting
DB2
for
distributed
and
z/OS
or
OS/390
operating
systems.
v
The
JDBC
driver
cannot
be
loaded
because
the
db2java.zip
file
is
not
on
the
system
CLASSPATH.
You
might
see
the
following
message
in
the
SLM
Server
stderr
or
the
msgTSLAn.log
files
on
the
machine
running
the
SLM
Server:
DYKAL3013E
Error
loading
driver
COM.ibm.db2.jdbc.app.DB2Driver
Verify
that
the
DB2
client
or
DB2
server
option
is
installed
on
this
machine
and
verify
the
following
items:
–
If
DB2
Universal
Database
is
installed
and
this
is
a
Windows
machine,
run
the
following
command
from
a
command
prompt:
set
classpath
Examine
the
output
of
this
command
and
ensure
that
the
fully
qualified
path
to
the
db2java.zip
file
is
correct.
If
it
is
not
correct
then
navigate
to
the
Windows
environment
variable
dialog,
correct
the
value,
and
restart
the
SLM
Server.
–
If
DB2
Universal
Database
is
installed
and
this
is
a
UNIX
machine,
then
view
the
contents
of
<TSLA_Dir>/bin/private/generic_unix/runscripts/slmdbsetup.sh,
where
<TSLA_Dir>
is
the
directory
where
IBM
Tivoli
Service
Level
Advisor
was
installed,
and
verify
that
the
paths
to
the
db2profile
and
usejdbc2
scripts
contained
in
this
file
are
correct.
If
they
are
not
correct,
edit
this
file
with
the
correct
paths
and
restart
the
SLM
Server.v
Messages
in
the
log
indicate
that
network
connectivity
to
the
database
server
is
not
possible.
Verify
that
network
connectivity
to
the
database
server
exists
by
using
the
ping
command.
If
none
of
the
previous
solutions
fixes
the
problem,
consult
your
database
administrator
to
determine
the
root
cause
of
the
database
connectivity
errors.
Related
messages
or
problems:
See
“Accessing
SLM
Reports”
for
related
information.
Related
documentation:
See
Getting
Started
for
information
on
SLM
database
installation
and
configuration,
and
see
the
Command
Reference
for
information
on
scmd
list.
Accessing
SLM
Reports
This
section
addresses
problems
you
might
encounter
while
attempting
to
access
SLM
reports.
28
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
HTTP
500
Internal
Server
Error
or
DYKAL3003E
Error
Message
If,
after
signing
in,
you
receive
an
HTTP
500
Internal
server
error
(The
page
cannot
be
displayed),
you
might
be
having
problems
with
the
SLM
Report
Server
or
SLM
Administration
Server
connecting
to
the
SLM
Database.
You
might
also
have
this
problem
if
you
receive
the
following
error
message:
DYKAL3003E
A
DataSource
for
sdc
was
not
found
in
my
SLM
Reports
message
log.
To
resolve
this
problem,
do
the
following
steps:
1.
Search
the
SLM
Reports
or
SLM
Administration
Server
STDERR
and
msgTSLAn.log
files
in
the
Tivoli
Common
Directory
on
the
machine
running
the
SLM
Reports
server
or
the
SLM
Administration
Server
for
either
of
the
following
messages:
v
DYKAL1054E
Component
yourmachine.somecompany.com_servlet:DS:1
failed
startup
with
the
following
error:
DYKAL3002E
An
error
occurred
for
sdc
during
DataSource
creation.
This
message
occurs
if
the
DB2
Server
has
not
been
started.
Verify
that
the
db2start
command
has
been
issued
on
the
database
server.
See
the
DB2
documentation
for
information
on
starting
DB2.
v
DYKAL3013E
Error
loading
driver
COM.ibm.db2.jdbc.app.DB2Driver.
This
message
can
occur
if
the
JDBC
driver
cannot
be
loaded
because
the
db2java.zip
file
is
not
in
the
WebSphere
Application
Server
CLASSPATH.
See
Getting
Started
for
more
information
on
configuring
the
JDBC
driver
in
WebSphere.
Upon
successful
recovery
from
this
error
you
should
be
able
to
log
onto
the
SLM
Reports
or
SLM
Administrative
Console
and
see
messages
similar
to
the
following
in
your
SLM
Reports
or
SLM
Administration
Server
msgTSLAn.log
in
the
Tivoli
Common
Directory:
DYKAL3005I
Driver
loaded
successfully.
DYKAL3001I
DataSource
successfully
created
for
sdc.
DYKAL1001I
Started
component
yourcomputer.some.company.com_servlet:DS:1.
2.
Open
the
web.xml
file,
which
is
located
in
the
following
directory,
where
<app_name>
is
SLMReport
for
SLM
Reports,
or
SLMAdmin
for
the
SLM
Administration
Server:
<WebSphere_Dir>/AppServer/config/cells/<yourcell>/applications
/<app_name>.ear/deployments/SLMAdmin/<app_name>.war/WEB-INF
Edit
this
file
using
your
preferred
XML
or
text
editor.
Verify
that
the
file
names
for
tsla.basedir
and
tsla.programfiles
parameters
are
set
correctly.
3.
If
the
web.xml
file
is
correct,
examine
the
following
log
file
for
detailed
errors:
Default_Server_stdout.log
Possible
errors
include:
v
Missing
tables
in
the
database
v
Incorrect
user
name
or
password
used
to
connect
to
the
database
If
you
find
error
DYKAL3014E,
specifying
the
reason
as
an
incorrect
user
name
or
password,
use
the
dsutil
utility
to
verify
that
the
user
ID
and
password
are
correct.
See
the
Command
Reference
for
details
on
running
the
dsutil
utility.
Related
Messages
or
Problems:
See
“Server
Hostname
is
Not
Fully
Qualified”
on
page
27.
Related
documentation:
See
Getting
Started
for
information
on
installing,
configuring,
and
accessing
the
SLM
Administration
Server
or
SLM
Reports.
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
29
Uninstalling
IBM
Tivoli
Service
Level
Advisor
This
section
includes
troubleshooting
problems
that
you
might
encounter
related
to
uninstalling
IBM
Tivoli
Service
Level
Advisor.
Uninstallation
Fails
because
the
Directory
Service
is
Not
Started
If
you
are
using
Lightweight
Directory
Access
Protocol
(LDAP)
or
another
directory
service
to
manage
users
in
your
environment,
it
must
be
up
and
running
when
you
install
or
uninstall
the
SLM
Reports
or
SLM
Administration
Server
options
of
IBM
Tivoli
Service
Level
Advisor
into
the
WebSphere
Application
Server
environment.
This
problem
is
not
detected
during
the
installation
or
uninstallation
process,
but
the
process
fails
because
the
directory
service
is
not
operational,
which
prevents
the
installation
wizard
from
detecting
if
the
WebSphere
Application
Server
is
started.
Check
the
log
files
for
information
about
the
cause
of
the
fail,
verify
that
the
directory
service
is
started,
and
attempt
the
uninstallation
again.
Uninstalling
SLM
Install
Options
If
the
use
of
the
uninstallation
script
in
the
procedure
outlined
in
Getting
Started
does
not
work,
and
if
you
have
a
Java
runtime
environment
(JRE)
installed
locally
on
the
machine,
try
uninstalling
by
issuing
the
following
command
instead
of
running
the
uninstallation
script:
java
-jar
_uninst/uninstall.jar
Manually
Uninstalling
IBM
Tivoli
Service
Level
Advisor
If
for
some
reason
the
uninstallation
program
does
not
complete
successfully,
manually
uninstall
IBM
Tivoli
Service
Level
Advisor
by
completing
the
following
steps:
1.
Verify
that
the
WebSphere
Application
Server
is
started
before
proceeding
with
the
uninstallation.
Refer
to
Getting
Started
for
information
on
starting
WebSphere
Application
Server.
2.
Shut
down
the
SLM
Server
(see
Getting
Started).
If
you
use
the
Services
Control
Panel
on
Windows,
be
sure
to
close
the
Services
Control
Panel
window
to
enable
the
IBM
Tivoli
Service
Level
Advisor
service
to
be
completely
uninstalled.
3.
Remove
the
IBM
Tivoli
Service
Level
Advisor
service.
4.
Uninstall
the
SLM
Reports
and
SLM
Administration
Server
components
from
WebSphere
by
completing
the
following
steps:
a.
Start
the
WebSphere
Administrative
Console
(see
Getting
Started).
b.
Sign
on
the
WebSphere
Administrative
Console
using
an
authorized
user
name
and
password.
c.
In
the
left
pane
of
the
WebSphere
Administrative
Console,
click
Applications
–>
Enterprise
Applications.
d.
In
the
Enterprise
Applications
table
that
is
displayed,
locate
the
application
named
SLMAdmin
(if
the
SLM
Administration
Server
was
installed
on
this
machine)
or
SLMReport
(if
SLM
Reports
was
installed
on
this
machine).
If
both
components
were
installed
on
the
same
machine
then
they
both
appear
in
the
table.
Select
the
check
box
next
to
each
of
these
applications,
and
click
Stop
to
stop
them
before
uninstalling
them.
e.
Click
Uninstall
to
uninstall
the
stopped
applications.
30
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
f.
Click
Save
(the
link
located
at
the
top
of
the
console
page
under
the
Message(s)
section).
g.
Click
Save
to
save
to
the
Master
Configuration.
5.
Remove
the
JDBC
Driver
from
IBM
WebSphere
Application
Server
by
completing
the
following
steps:
v
With
the
SLM
Administrative
Console
open,
in
the
left
pane,
click
Resources
–>
JDBC
Providers
v
In
the
JDBC
Providers
table
that
is
displayed,
select
the
check
box
for
either
IBMTSLAJDBCProvider_Reports
(if
SLM
Reports
was
installed
on
this
machine)
or
IBMTSLAJDBCProvider_Admin
(if
the
SLM
Administration
Server
was
installed
on
this
machine).
v
Click
Delete
to
delete
the
JDBC
Driver.
v
Click
Save
(the
link
located
at
the
top
of
the
console
page
under
the
Message(s)
section).
v
Click
Save
to
save
to
the
Master
Configuration.
6.
Sign
out
of
the
WebSphere
Administrative
Console
by
clicking
Logout
from
the
toolbar.
Close
the
WebSphere
Administrative
Console
window.
7.
Stop
the
WebSphere
Application
Server
(see
Getting
Started).
8.
Restart
the
WebSphere
Application
Server.
9.
Navigate
to
the
Tivoli
Common
Directory
and
delete
the
DYK
folder.
10.
Navigate
to
the
location
where
IBM
Tivoli
Service
Level
Advisor
was
installed
(for
example,
C:\Program
Files\TSLA)
and
delete
the
\TSLA
directory
(this
might
have
been
specified
under
another
name.
See
Getting
Started).
11.
If
you
are
uninstalling
on
an
HP
platform,
you
might
receive
warnings
stating
that
not
all
JRE
files
could
be
deleted.
You
will
need
to
manually
removed
these
files.
Upgrading
IBM
Tivoli
Service
Level
Advisor
This
section
addresses
problems
that
you
might
experience
while
upgrading
IBM
Tivoli
Service
Level
Advisor
from
a
previous
version.
Upgrade
of
the
SLM
Server
Fails
On
Windows
operating
systems,
the
installation
program
might
fail
during
migration
if
the
Services
control
panel
is
not
closed
before
starting
the
installation
program.
Verify
that
the
Services
control
panel
is
closed,
and
then
start
the
program
again.
Chapter
2.
Troubleshooting
During
Installation
and
Configuration
31
32
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
This
chapter
includes
information
on
various
topics
that
might
help
you
use
IBM
Tivoli
Service
Level
Advisor.
The
following
major
topic
areas
are
discussed
in
this
chapter:
v
“CLI
Service
Commands”
v
“Problems
Related
to
SLM
Databases
(Distributed
Platforms)”
on
page
37
v
“Problems
Related
to
Databases
on
z/OS
Systems”
on
page
43
v
“Problems
Related
to
the
DB2
Data
Warehouse
Center”
on
page
44
v
“Problems
Related
to
Data
Retrieval”
on
page
46
v
“Problems
Related
to
ETLs”
on
page
54
v
“Problems
Related
to
the
SLM
Administrative
Console”
on
page
56
v
“Problems
Related
to
the
SLM
Server”
on
page
57
v
“Problems
Related
to
Creating
Offerings
and
SLAs”
on
page
59
v
“Problems
Related
to
Event
Escalation”
on
page
63
v
“Problems
Related
to
SLM
Reports”
on
page
68
v
“Problems
Related
to
Backup
and
Restore”
on
page
72
v
“Configuring
the
CLI
Service
and
Utilities”
on
page
73
Note:
Throughout
this
chapter
are
various
references
to
message
log
files.
Refer
to
Chapter
1,
“Message
and
Trace
Logging,”
on
page
1
for
information
about
the
location
and
use
of
the
various
log
files.
CLI
Service
Commands
This
section
includes
troubleshooting
problems
you
might
encounter
while
issuing
scmd
commands
using
the
CLI
Service.
CLI
Client
Interface
Cannot
Establish
a
Connection
to
the
CLI
Service
As
a
result
of
issuing
an
scmd
command,
if
you
receive
an
error
message
similar
to
the
following
example,
there
is
a
problem
with
the
connection
between
the
CLI
client
interface
and
the
CLI
Service:
DYKAL2030E
Unable
to
Connect
to
the
CLI
Service
on
Port
<CLI_Client_port_number>
The
cause
of
this
problem
might
be
traced
to
either
the
CLI
client
or
the
CLI
server.
Do
the
following
steps:
1.
Search
the
SLM
Server
stdout
or
the
msgTSLAn.log
files
on
the
machine
running
the
SLM
Server
for
the
following
message:
DYKAL2020I:
The
CLI
service
was
created
and
listening
on
port
<CLI_Server_port_number>.
If
this
message
is
found
then
the
CLI
Service
was
started
correctly,
and
the
problem
might
lie
with
the
CLI
client.
Note
the
port
number
<CLI_Server_port_number>
for
later
use.
If
this
message
was
not
found,
then
the
CLI
Service
might
not
have
started
correctly.
Go
to
step
3.
©
Copyright
IBM
Corp.
2002,
2004
33
2.
If
the
problem
is
with
the
CLI
client,
the
CLI
client
might
not
be
configured
correctly,
or
is
unable
to
reach
the
CLI
service
due
to
a
network
error.
To
check
the
port
configuration,
do
the
following
steps:
a.
Examine
the
original
message
DYKAL2030E
and
get
the
port
number,
<CLI_Client_port_number>,
through
which
the
CLI
client
is
connecting.
If
the
message
is
no
longer
available,
run
the
scmd
again
to
get
the
port
to
which
the
client
is
attempting
to
connect.
b.
Get
the
<CLI_Server_port_number>
port
number
on
which
the
CLI
service
is
running.
This
is
found
in
the
message
DYKAL2020I
that
was
received,
or
by
running
the
following
command
on
the
machine
running
the
SLM
Server:
cliutil
getPort
c.
If
the
two
ports
are
different,
reset
the
CLI
client
port
to
match
the
CLI
Server
port.
On
the
machine
where
the
CLI
client
is
running,
issue
the
following
command
to
reset
the
port
number:
cliutil
setport
<CLI_Server_port_number>
Retry
the
original
scmd
to
verify
that
the
problem
is
resolved.
d.
If
the
two
ports
are
identical,
the
problem
might
be
due
to
a
temporary
network
error.
Retry
the
original
scmd,
and
if
the
problem
persists,
contact
IBM
Customer
Support.3.
If
the
message
DYKAL2020I
is
not
received
as
discussed
in
step
1,
the
CLI
service
is
not
able
to
start
correctly.
No
CLI
clients
can
connect
until
the
CLI
service
is
successfully
started.
Search
the
SLM
Server
stderr
or
the
msgTSLAn.log
files
on
the
machine
running
the
SLM
Server
for
a
message
in
the
following
form:
DYKAL1054E:
Component
<localhost>.CLI:<Y>
failed
startup
with
the
following
error:
<X>
In
this
message,
<localhost>
should
be
the
fully
qualified
name
of
the
machine
running
the
SLM
Server
and
<Y>
is
an
integer
value.
If
this
message
is
not
found,
then
proceed
to
step
4.
If
this
message
is
found,
then
the
CLI
Service
did
not
start
correctly.
The
SLM
server
attempts
to
retry
the
CLI
Service
startup.
If
the
problem
persists,
look
up
the
error
message
<X>
that
followed
the
message
DYKAL1054E
for
specific
explanations
and
recovery
procedures.
4.
If
the
message
DYKAL1054E
was
not
found
in
step
3,
look
for
the
occurrence
of
the
following
two
messages:
DYKAL1020I
Component
startup
activities
have
completed:
DYKAL1000I
Starting
component
localhost:CLI:Y.
If
DYKAL1000I
is
not
found
and
DYKAL1020I
is
found,
then
the
CLI
service
is
not
registered
to
startup.
Contact
IBM
Customer
Support.
5.
It
is
possible
that
the
CLI
Service
startup
is
not
yet
complete.
Wait
until
the
following
message
is
displayed,
where
<fully_qualified_machine_name>
should
be
the
fully
qualified
name
of
the
machine
running
the
SLM
Server,
and
<Y>
is
an
integer
value:
DYKAL1001I:
Started
component
<fully_qualified_machine_name>.CLI:<Y>
After
you
receive
this
message,
retry
the
scmd
command.
If
the
problem
persists
or
the
message
above
is
never
received,
contact
IBM
Customer
Support.
Related
messages:
The
following
messages
are
all
related
to
the
problem
of
the
CLI
Service
not
starting
correctly.
If
these
messages
are
received,
take
the
corrective
action
displayed
by
the
message
responses.
If
the
CLI
Service
cannot
be
started,
then
restart
the
SLM
Server.
v
DYKAL2045E
Unable
to
create
the
CLI
service
on
port
<port
number>.
The
CLI
service
has
not
been
started.
34
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
v
DYKAL2046E
Unable
to
create
the
CLI
service
on
port
<port
number>.
The
port
is
already
in
use.
The
CLI
service
has
not
been
started.
v
DYKAL2047E
Unable
to
create
the
CLI
service
on
port
<port
number>.
The
CLI
service
has
not
been
started.
v
DYKAL2011E
The
CLI
service
could
not
be
created
on
port
<port
number>.
The
CLI
service
could
not
be
started.
v
DYKAL2012E
The
CLI
service
was
not
started
properly.
Related
documentation:
See
the
Command
Reference
for
further
information
on
configuring
and
using
the
cliutil
commands
and
the
CLI
Service.
Server
Hostname
is
Not
Fully-Qualified
If
you
receive
either
of
the
following
messages,
you
might
need
to
change
your
system
configuration
to
return
fully
qualified
hostnames:
v
As
a
result
of
invoking
an
scmd
command:
DYKAL2030E
Unable
to
connect
to
the
Command
Line
Interface
service
on
port
9990.
v
You
find
the
following
messages
in
the
msgTSLAn.log
files:
DYKAL0009E
The
server
host
name
<hostname>
is
not
a
fully
qualified
host
name.
DYKAL1020I
Component
startup
activities
have
completed:0
started,
0
timed
out,
0
failed.
These
errors
occur
if
the
SLM
Server
configuration
data
could
not
be
loaded
and
if
required
SLM
Server
services
are
not
started.
This
situation
occurs
if
the
machine
that
the
SLM
Server
is
installed
on
is
no
longer
known
by
the
fully
qualified
hostname.
In
this
condition,
the
server
does
not
properly
read
necessary
configuration
data
that
is
associated
with
the
fully
qualified
hostname
of
the
machine,
and
necessary
services
are
not
started.
Machines
on
which
you
install
the
SLM
Server,
SLM
Administration
Server,
and
SLM
Reports
must
be
configured
so
that
their
hostnames
resolve
to
fully
qualified
names.
Refer
to
Installing
and
Configuring
Tivoli
Data
Warehouse
for
more
information
on
configuring
your
machine
to
return
fully
qualified
hostnames.
Issuing
scmd
list
Reports
only
rcc,
log,
and
slm
Bundles
If
you
issue
the
scmd
list
command
and
only
the
rcc,
log,
and
slm
bundles
are
reported
as
available,
the
SLM
Server
might
have
stopped
during
startup
because
it
cannot
connect
to
the
SLM
Database
or
the
SLM
Measurement
Data
Mart.
You
might
receive
the
following
related
message
in
the
msgTSLAn.log
files:
DYKAL1054E
Component
yourmachine.some.company.com:DS:1
failed
startup
with
the
following
error:DYKAL3002E
An
error
occurred
for
sdc
during
DataSource
creation.
This
error
indicates
that
connection
to
one
or
both
of
the
IBM
Tivoli
Service
Level
Advisor
databases
is
not
possible.
Examine
the
related
messages
in
the
log
to
determine
the
root
cause
of
the
failure.
The
following
errors
are
the
most
common
causes
of
this
type
of
problem:
v
The
db2start
command
was
not
issued
on
the
database
server.
You
might
see
the
following
message
in
the
SLM
Server
stderr
or
the
msgTSLAn.log
files
on
the
machine
running
the
SLM
Server:
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
35
DYKAL3014E
Error
connecting
to
the
database.
Reason:
[IBM][CLI
Driver]
SQL1032N
No
start
database
manager
command
was
issued.
SQLSTATE=57019
Verify
that
a
db2start
command
is
issued
on
the
database
server.
See
the
DB2
documentation
for
more
information
on
starting
DB2
Universal
Database.
v
The
jdbc
driver
cannot
be
loaded
because
the
db2java.zip
file
is
not
on
the
system
CLASSPATH.
You
might
see
the
following
message
in
the
SLM
Server
stderr
or
the
msgTSLAn.log
files
on
the
machine
running
the
SLM
Server:
DYKAL3013E
Error
loading
driver
COM.ibm.db2.jdbc.app.DB2Driver
Verify
the
following
items:
–
The
DB2
client
or
server
option
is
installed
on
this
machine.
–
If
DB2
is
installed
and
this
is
a
Windows
machine,
run
the
following
command
from
a
command
prompt:
set
classpath
Examine
the
output
of
this
command
and
verify
that
the
fully
qualified
path
to
the
db2java.zip
file
is
correct.
If
it
is
not
correct
then
navigate
to
the
Windows
environment
variable
window,
correct
the
value,
and
then
restart
the
SLM
Server.
–
If
DB2
Universal
Database
is
installed
and
this
is
a
UNIX
machine,
then
view
the
contents
of
<TSLA_Dir>/bin/private/generic_unix/runscripts/slmdbsetup.sh,
where
<TSLA_Dir>
is
the
directory
where
IBM
Tivoli
Service
Level
Advisor
was
installed,
and
verify
that
the
paths
to
the
db2profile
and
usejdbc2
scripts
contained
in
this
file
are
correct.
If
they
are
not
correct,
edit
this
file
with
the
correct
paths
and
restart
the
SLM
Server.v
Messages
in
the
log
indicate
that
network
connectivity
to
the
database
server
is
not
possible.
Verify
that
network
connectivity
to
the
database
server
exists
by
using
the
ping
command.
If
none
of
the
previous
solutions
fixes
the
problem,
consult
your
database
administrator
to
determine
the
root
cause
of
the
database
connectivity
errors.
Related
documentation:
See
Getting
Started
for
information
on
SLM
database
installation
and
configuration.
Failure
Attempting
to
Disable
Source
Applications
After
you
have
registered
a
source
application,
either
by
adding
the
application
to
the
SLM
environment
using
the
CLI
command
scmd
etl
addApplicationData,
or
by
enabling
a
previously
registered
source
application
using
the
scmd
etl
enable
command,
you
can
disable
it
using
the
CLI
command
scmd
etl
disable.
This
command
stops
the
extraction
of
data
from
Tivoli
Data
Warehouse
and
removes
all
of
the
offering
component
information
associated
with
the
application
from
the
SLM
Database,
so
that
no
new
data
for
this
application
is
moved
by
the
Registration
ETL.
You
can
only
disable
a
source
application
if
all
associated
SLAs
have
been
canceled
and
removed,
and
the
associated
offerings
deleted.
For
more
information
about
these
and
other
CLI
Service
commands
and
utilities,
see
the
Command
Reference.
36
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Problems
Related
to
SLM
Databases
(Distributed
Platforms)
This
section
addresses
problems
you
might
encounter
with
databases
on
distributed
platforms.
Exceeding
Maximum
Application
Connections
When
you
use
the
DB2
Control
Center
to
access
a
database,
whenever
you
perform
a
Sample
Contents
operation,
a
connection
is
established
with
the
database
even
when
the
control
center
already
has
a
connection
established.
After
each
Sample
Contents
operation
completes,
this
connection
is
not
released
unless
the
control
center
is
shutdown.
Over
time,
the
number
of
held
connections
can
increase
and
exceed
the
maximum
number
of
applications
allowed.
This
prevents
IBM
Tivoli
Service
Level
Advisor
and
other
applications
from
obtaining
database
connections
when
needed.
By
default,
DB2
databases
are
configured
to
allow
a
maximum
of
40
active
applications
at
one
time
(this
is
the
MAXAPPLS
configuration
parameter).
After
this
maximum
is
reached,
no
further
connections
can
be
made
to
the
database.
When
this
happens,
you
can
do
one
of
the
following:
v
Terminate
applications
such
as
the
DB2
Control
Center,
which
might
be
using
a
substantial
number
of
connections
depending
on
how
long
it
has
been
running.
v
Increase
the
maximum
number
of
allowed
connections
(active
applications)
by
increasing
the
MAXAPPLS
parameter
value
for
the
particular
database.
To
increase
the
MAXAPPLS
parameter
value,
do
either
of
the
following:
–
From
a
DB2
command
line,
enter
the
following,
where
<db_name>
is
the
database
name
and
<new_number>
is
the
number
of
connections
to
set
in
the
MAXAPPLS
parameter:
db2
update
db
cfg
for
<db-name>
using
maxappls
<new
number>
–
From
the
DB2
Control
Center,
do
the
following
steps:
1.
Select
the
database
to
be
changed,
right
click
and
select
Configure.
2.
Select
the
Applications
tab.
3.
Click
Maximum
number
of
applications.
4.
In
the
Value
field,
enter
the
new
value
and
click
OK.
All
applications
must
disconnect
from
the
database
before
the
new
value
can
take
effect.
Reconnecting
to
the
Tivoli
Data
Warehouse
Database
After
Changing
Logfile
Size
If
you
change
the
size
of
your
logfile
for
the
Tivoli
Data
Warehouse
database,
after
making
the
change
and
restarting
DB2,
verify
that
you
can
still
connect
to
the
twh_cdw
database,
using
the
command:
db2
connect
to
twh_cdw
user
<db2_user>
using
<db2_password>
You
may
need
to
increase
the
filesystem
(for
example,
/home/db2install)
in
order
to
handle
a
larger
log
filesize.
SLM
Administrative
Console
or
SLM
Reports
User
Interface
Unresponsive
If
a
link
is
selected
in
the
SLM
Administrative
Console
user
interface
or
when
signed
on
to
SLM
Reports
and
control
is
not
being
returned,
then
this
might
indicate
a
database
availability
problem.
In
the
DB2
database
environment,
if
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
37
network
connectivity
to
the
database
server
is
lost,
then
the
database
client
may
appear
to
be
hung.
The
connection
will
timeout
after
the
TCP/IP
keep
alive
timeouts
have
been
exhausted.
To
resolve
this
problem,
verify
that
the
database
is
available
by
using
the
ping
command.
From
a
command
prompt,
issue
the
following
command,
where
<db
server
hostname>
is
the
hostname
of
the
machine
where
the
database
is
located:
ping
<db
server
hostname>
If
the
database
server
is
not
available
then
contact
your
appropriate
system
administrator
for
assistance.
Related
Documentation:
For
more
information
see
the
TCP/IP
Problems
section
of
the
″Troubleshooting
on
the
Client″
chapter
of
the
DB2
Troubleshooting
Guide.
Receiving
SQL0289N
While
Executing
a
Database
Operation
While
executing
a
database
operation,
you
might
receive
this
error
indicating
that
the
database
is
out
of
space.
You
need
to
extend
the
size
of
the
space
that
contains
the
database
data
files.
You
can
check
the
status
of
your
database
by
first
determining
whether
you
are
using
a
System
Managed
Tablespace
(SMS)
or
a
Database
Managed
Tablespace
(DMS)
by
doing
the
following:
1.
Connect
to
the
database
in
question.
2.
Issue
the
following
command:
db2
list
tablespaces
show
detail
3.
There
will
most
likely
be
multiple
entries
in
the
output
of
the
command.
Look
for
the
tablespace
name
referred
to
in
the
original
error
message,
and
refer
to
the
Type
entry
in
this
tablespace.
It
will
either
be
System
managed
space
for
SMS,
or
Database
managed
space
for
DMS.
If
the
tablespace
is
SMS,
the
hard
disk
is
full.
You
need
to
back
up
the
database
and
restore
it
onto
a
larger
hard
disk.
If
the
tablespace
is
DMS,
you
can
extend
the
tablespace
container
by
running
the
following
command,
where
<tablespace_name>
is
the
name
of
the
tablespace
referred
to
in
the
original
error
message,
and
<num_pages>
is
the
number
of
4K
pages
to
extend
the
tablespace
container:
db2
alter
tablespace
<tablespace_name>
extend
(all
<num_pages>)
Note:
The
database
may
go
through
rebalancing
and
roll
forward
operations
on
the
DMS
tablespace.
To
check
the
status
of
the
tablespace,
issue
the
following
command
after
connecting
to
the
database:
db2
list
tablespace
show
detail
In
the
State
entry
under
the
appropriate
tablespace,
there
is
a
hex
number
that
indicates
the
current
state.
An
entry
of
0x10000000
indicates
that
the
DMS
rebalancer
is
active,
while
an
entry
of
0x0000
indicates
a
normal
state,
and
the
tablespace
is
ready
to
be
used.
38
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Receiving
SQL1224N
When
Attempting
to
Connect
to
SLM
Databases
You
might
find
problems
while
attempting
to
connect
to
the
IBM
Tivoli
Service
Level
Advisor
databases,
failing
with
DB2
error
code
SQL1224N.
This
error
code
can
be
contained
within
many
different
messages
from
IBM
Tivoli
Service
Level
Advisor.
This
usually
indicates
that
DB2
has
exhausted
all
available
shared
memory
segments,
and
will
normally
only
occur
if
the
SLM
databases
reside
on
the
same
machine
with
any
of
the
install
options
of
IBM
Tivoli
Service
Level
Advisor
(SLM
Server,
SLM
Administration
Server,
or
SLM
Reports).
SQL1224N
on
AIX
If
the
SLM
databases
reside
on
the
same
machine
with
any
of
the
install
options
of
IBM
Tivoli
Service
Level
Advisor
and
the
platform
is
AIX®,
then
DB2
Universal
Database
must
be
configured
to
use
extended
shared
memory.
To
enable
this
support,
do
the
following:
1.
Add
EXTSHM=ON
to
the
/etc/environment
file
2.
From
a
DB2
command
prompt,
run
the
following
command:
db2set
DB2ENVLIST=EXTSHM
3.
Add
the
following
lines
to
sqllib/db2profile
EXTSHM=ON
export
EXTSHM
4.
Reboot
the
machine
to
put
the
changes
into
effect
Related
Documentation:
For
more
information
see
the
DB2
documentation
for
configuration
of
shared
memory.
SQL1224N
on
Solaris
This
error
might
indicate
an
incorrect
configuration
of
the
DB2
server
on
a
Sun
Solaris
machine.
The
kernel
configuration
parameters
must
be
properly
set
in
the
/etc/system
kernel
configuration
file
to
ensure
that
DB2
Universal
Database
functions
properly.
These
values
are
found
in
IBM
DB2
Universal
Database
for
UNIX
Quick
Beginnings,
Version
7.
You
must
reboot
your
system
before
these
configuration
parameters
take
effect.
Receiving
SQL30081N
When
Attempting
to
Connect
to
SLM
Databases
Remotely
This
error
is
an
indication
that
the
DB2
client
or
server
might
not
be
set
up
correctly.
Follow
the
steps
below
to
ensure
that
your
DB2
Server
is
properly
configured
for
communications:
1.
On
the
DB2
client
machine,
if
you
have
cataloged
the
remote
node
by
the
DNS
name,
verify
that
the
DNS
server
returns
the
correct
IP
address
of
the
intended
remote
DB2
server.
Verify
that
you
can
ping
or
touch
the
remote
DB2
server
machine,
using
the
IP
address
returned.
2.
If
you
still
cannot
establish
a
connection
between
the
client
and
server,
verify
that
the
DB2
server
is
configured
correctly
by
doing
the
following
steps:
a.
Run
the
following
command
from
a
DB2
command
line
window:
db2
get
dbm
cfg
Retrieve
the
svcename
parameter
if
one
exists
for
your
database
instance.
The
svcename
is
one
of
the
variables
listed
in
the
output
of
the
previous
command.
It
represents
the
port
number
that
the
DB2
Server
will
use
for
its
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
39
communication
port.
If
the
svcename
exists,
you
will
need
to
retrieve
it
for
the
next
step.
If
the
name
does
not
exist,
you
will
have
to
know
this
for
a
later
step
to
properly
configure
the
DB2
server.
b.
Verify
that
the
DB2
Server
listener
port
is
set
in
the
services
file.
On
Windows
systems,
the
services
file
is
located
in
the
<WIN_DIR>\system32\drivers\etc
directory.
On
UNIX
systems,
the
services
file
is
located
in
the
/etc/
directory.
If
you
retrieved
a
name
in
the
previous
step,
search
for
the
name
in
the
services
file
and
retrieve
the
port
number
associated
with
this
name.
If,
in
the
previous
step,
there
was
not
a
svcename
listed
for
your
database
instance,
you
must
do
the
following:
v
Edit
the
services
file
to
add
a
line
that
looks
like
the
following,
where
<db2
instance
name>
is
the
name
of
your
instance
and
<port_num>
is
any
free
port
number
(recommended
50000):
<db2
instance
name>
<port_num>/tcp
This
step
assigns
a
port
number
to
a
particular
service.
You
will
assign
this
service
name
to
DB2
in
the
next
step
below.
v
From
a
DB2
command
line
processor
window,
issue
the
following
command,
where
<service_name>
is
the
name
of
the
port
you
added
to
the
services
file:
db2
update
dbm
cfg
using
svcename
<service_name>
This
step
updates
the
database
manager
to
use
the
assigned
port
from
the
services
file
for
the
communication
listener.c.
Using
the
port
number
that
was
assigned
to
the
DB2
server
in
the
previous
step,
verify
that
nothing
is
currently
using
that
port.
To
verify
this,
issue
the
following
command
and
search
through
the
output
for
the
port
number:
netstat
If
you
find
anything
listening
on
that
port,
you
might
want
to
end
the
service
that
is
currently
using
that
port
number,
or
reboot
the
machine
if
the
port
is
being
used
but
should
not
be,
or
choose
another
port
for
the
DB2
server
and
reconfigure
the
DB2
server
to
use
this
free
port.
To
choose
another
port
follow
the
instructions
from
the
previous
step,
and
follow
the
steps
assuming
you
did
not
have
a
svcename
listed
in
the
DB2
server.
Note:
You
might
need
to
delete
the
old
entry
in
the
services
file,
if
one
exists,
for
the
DB2
server,
because
you
cannot
have
conflicting
service
names
in
the
services
file.
d.
Now
that
the
DB2
server
and
the
services
file
are
correctly
configured,
you
must
check
some
environment
variables
before
restarting
the
DB2
server.
The
communication
listener
requires
an
environment
variable
to
be
set
for
the
proper
configuration
of
the
communication
services.
Run
the
following
command
from
a
DB2
command
line
processor
window:
db2set
The
output
of
this
command
should
return
some
DB2
specific
environment
variables.
The
environment
variable
that
the
communication
service
depends
on
is
the
DB2COMM
variable.
You
should
see
DB2COMM=TCPIP
(if
you
are
using
TCP/IP
as
the
communication
protocol).
If
you
do
not
see
this
variable
or
you
do
not
see
the
correct
information,
issue
the
following
command
from
the
same
window:
db2set
DB2COMM=TCPIP
This
sets
the
DB2
communication
variable
to
use
the
TCP/IP
protocol.
40
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Note:
This
assumes
you
will
be
using
TCP/IP
as
the
communication
protocol.
If
you
choose
another
protocol,
see
IBM
DB2
Universal
Database
Command
Reference,
Version
7
for
further
details.
e.
Stop
and
restart
the
DB2
Server
by
issuing
the
following
commands:
db2stop
force
db2start
When
the
DB2
Server
restarts
it
should
give
you
an
SQL
code.
If
you
see
SQL1063N
then
your
DB2
Server
has
started,
and
should
be
configured
for
communications
properly.
However,
if
you
see
an
SQL1054N,
then
your
DB2
Server
is
not
properly
configured
and
you
should
recheck
the
steps
above
for
configuring
the
DB2
Server.
In
addition,
see
IBM
DB2
Universal
Database
Administration
Guide,
Version
7
for
more
help.
Unable
to
Publish
Service
Monitor
Results
If
you
receive
the
following
error
in
the
msgTSLAn.log
files,
there
is
a
problem
with
the
SLM
Server
attempting
to
write
SLA
results
data
to
the
SLM
Database
(dyk_cat):
DYKME9034E
An
attempt
was
made
to
publish
service
monitoring
results
and
a
failure
occurred.
The
monitoring
results
will
be
stored
locally.
The
connection
to
the
SLM
Database
might
be
down,
at
the
moment
the
SLM
Server
tried
to
store
the
results
in
the
database.
The
results
will
be
stored
locally.
To
resolve
this
problem,
restore
the
connection
between
the
SLM
Server
and
the
SLM
Database.
Then
run
the
following
CLI
command:
scmd
mem
flushEvents
Check
the
message
log
again
to
see
if
another
DYKME9034E
message
was
added
after
running
the
CLI
command.
If
not,
then
the
data
was
stored
in
the
SLM
Database.
Note:
The
SLM
server
automatically
attempts
to
publish
locally
stored
results
after
each
regularly
scheduled
evaluation.
If
evaluations
or
trend
analysis
occur
at
a
daily
frequency,
and
if
the
connection
to
the
SLM
Database
is
restored
before
the
next
evaluation,
the
locally
stored
data
will
be
stored
in
the
SLM
Database
automatically
at
the
time
of
the
next
evaluation.
Optimizing
Performance
on
Data
Collection
Whenever
there
is
significant
activity
on
a
database
table,
either
adding
or
removing
or
otherwise
updating
the
information,
it
is
highly
recommended
to
use
the
runstats
command
to
collect
current
statistics
about
database
tables
and
indexes.
This
provides
the
DB2
optimizer
with
the
most
accurate
information
with
which
to
determine
the
most
efficient
access
plan.
Every
time
the
source
and
target
ETLs
run,
the
Tivoli
Data
Warehouse
central
data
warehouse
(TWH_CDW)
and
the
SLM
Measurement
Data
Mart
(DYK_DM)
are
subject
to
large
amounts
of
update
activity
on
their
tables,
with
hundreds
of
thousands
of
table
entries
being
affected.
The
SLM
Measurement
Data
Mart
holds
at
most
two
months
of
data
at
one
time,
which
means
many
entries
are
being
removed
as
well
on
a
regular
basis.
Metric
evaluators
perform
separate
queries
for
the
data
for
each
component
that
needs
to
be
evaluated.
Running
runstats
on
a
regular
basis
will
significantly
improve
the
query
speed
and
efficiency
of
the
data
collector
function
in
IBM
Tivoli
Service
Level
Advisor.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
41
The
tables
that
are
most
affected
are
the
TWG.MSMT
table
in
the
central
data
warehouse,
and
DYK.EXT_TOT,
DYK.EXT_AVL,
DYK.EXT_MMA,
and
DYK.EXT_PCH
in
the
SLM
Measurement
Data
Mart.
You
should
plan
to
run
runstats
on
the
TWG.MSMT
table
after
the
source
ETLs
have
run,
specifically
after
the
first
run
of
these
ETLs,
and
periodically
after
that
(consult
your
database
administrator
for
the
right
frequency
of
running
runstats).
Similarly,
runstats
should
be
run
on
the
DYK.EXT_TOT,
DYK.EXT_AVL,
DYK.EXT_MMA,
and
DYK.EXT_PCH
tables
after
the
Process
ETLs
have
run
the
first
time,
and
periodically
afterward
as
needed.
Note:
It
is
not
recommended
to
run
runstats
on
tables
in
the
SLM
Database
(dyk_cat).
You
may
experience
decreased
query
performance
that
affects
SLM
Reports
operation.
See
the
IBM
Tivoli
Service
Level
Advisor
Release
Notes
for
more
information.
To
run
runstats
on
these
tables,
do
the
following
steps:
1.
Start
a
DB2
command
line
prompt
(CLP)
session.
2.
Connect
to
the
desired
database.
3.
After
the
source
ETLs
complete
their
processing,
run
runstats
on
the
TWG.MSMT
table
by
issuing
the
following
command:
db2
runstats
on
table
twg.msmt
4.
After
the
Process
ETLs
complete
their
processing,
run
runstats
on
the
DYK.EXT_TOT,
DYK.EXT_AVL,
DYK.EXT.MMA,and
DYK.EXT_PCH
tables
by
issuing
the
following
commands:
db2
runstats
on
table
dyk.ext_mma
db2
runstats
on
table
dyk.ext_avl
db2
runstats
on
table
dyk.ext_tot
db2
runstats
on
table
dyk.ext_pch
For
more
information
on
the
runstats
command,
see
the
DB2
Administration
Guide.
Analyzing
System
Catalog
Tables
using
Reorgchk
When
running
certain
SQL
operations,
tables
may
be
left
with
internal
gaps.
The
reorgchk
utility
can
help
you
determine
the
physical
organization
of
your
tables
and
indexes,
how
much
free
space
is
currently
available,
and
how
much
space
is
being
used.
The
utility
analyzes
the
system
catalog
tables
to
gather
information
about
the
physical
organization
of
tables
and
indexes
and
displays
the
space
allocation
characteristics.
To
run
the
reorgchk
utility,
start
a
DB2
command
line
session,
connect
to
the
database
that
contains
the
table
to
be
analyzed,
and
issue
the
following
command,
where
<schema>
is
the
name
of
the
schema
in
which
the
table,
<table_name>,
was
created:
db2
reorgchk
[current
statistics]
on
table
<schema>.<table_name>
If
the
current
statistics
argument
is
not
specified,
reorgchk
will
first
call
the
runstats
utility
to
get
the
latest
statistics
on
the
table.
For
more
information
about
the
reorgchk
utility
and
interpreting
its
output,
see
IBM
DB2
Universal
Database
Command
Reference,
Version
7.
42
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Problems
Related
to
Databases
on
z/OS
Systems
This
section
addresses
problems
you
might
encounter
with
databases
on
z/OS
operating
systems.
Error
SQL0969N
Received:
There
is
no
message
text
corresponding
to
SQL
error
-873
If
you
have
IBM
Tivoli
Service
Level
Advisor
databases
on
z/OS
systems
and
you
are
running
ETL
processes
in
the
target
(DYK)
or
source
(DY1)
warehouse
packs,
you
might
receive
an
error
message
similar
to
the
following
example:
CDWEX8087E
A
general
SQL
error
occurred:
SQL_ERROR:
’ExecDirect’
2004.06.15
15:30:58.968
sqlState
=
53090,
nativeErr
=
-873,
errorMsg
=
[IBM][CLI
Driver][DB2]
SQL0969N
There
is
no
message
text
corresponding
to
SQL
error
"-873"
in
the
message
file
on
this
workstation.
The
error
was
returned
from
module
"DSNXOEND"
with
original
tokens
"".
SQLSTATE=53090
This
error
can
occur
if
you
attempt
to
run
the
ETLs
without
first
running
the
dyk_translate.bat
or
dy1_translate.bat
script
on
the
Tivoli
Data
Warehouse
control
server
machine.
These
scripts
configure
the
DYK
and
DY1
ETL
processes,
respectively,
to
utilize
the
tablespace
names
chosen
when
the
IBM
Tivoli
Service
Level
Advisor
databases
are
created
on
a
z/OS
system.
See
Chapter
5
of
Getting
Started
for
the
procedures
to
run
the
dyk_translate.bat
and
dy1_translate.bat
scripts
to
configure
the
DYK
and
DY1
ETLs.
Encoding
Issues
and
Limitations
with
the
DY1
Source
Warehouse
Pack
When
using
the
IBM
Tivoli
Service
Level
Advisor
Source
warehouse
pack
(DY1)
with
IBM
Tivoli
Service
Level
Advisor
databases
located
on
z/OS
systems,
be
aware
of
the
following
encoding
issues
and
limitations:
v
The
default
encoding
for
the
DB2
location
must
be
unicode
for
the
DY1
ETL
process
to
work
when
the
target
central
data
warehouse
and
the
SLM
Database
(DYKCAT)
reside
within
the
same
location.
The
main
central
data
warehouse
tablespace
inherits
the
encoding
scheme
of
the
location
in
which
it
is
created,
and
DB2
Universal
Database
does
not
allow
an
SQL
statement
to
intermix
tables
defined
in
tablespaces
of
different
encodings.
v
If
the
target
central
warehouse
database
and
the
SLM
Database
(DYKCAT)
reside
in
different
DB2
locations,
then
the
default
encoding
of
the
location
where
the
central
data
warehouse
resides
does
not
have
to
be
unicode.
However,
the
codepage
for
the
central
data
warehouse
must
be
compatible
with
the
characters
stored
in
the
SLM
Database
tables.
See
your
local
database
administrator
and
DB2
UDB
documentation
for
more
information
on
encoding
schemes.
Incorrect
Port
Number
Specified
during
Database
Creation
You
might
attempt
to
create
an
IBM
Tivoli
Service
Level
Advisor
DB2
database
on
a
z/OS
operating
system,
but
the
creation
fails
and
the
log
file
contains
a
communication
error
similar
to
the
following
example:
SQL30081N
A
communication
error
has
been
detected.
Communication
protocol
being
used:
"TCP/IP".
Communication
API
being
used:
SOCKETS".
location
where
the
error
was
detected:
"".
Communication
function
detecting
the
error:
"connect".
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
43
Protocol
specific
error
code(s):
"10061",
"*",
"*".
SQLSTATE=08001
SQL1024N
A
database
connection
does
not
exist.
SQLSTATE=08003
This
error
might
be
caused
by
an
incorrect
port
number
specified
on
the
database
creation
panel.
The
default
port
value
is
5027
for
DB2
databases
on
z/OS
operating
systems.
Run
the
database
creation
task
again
from
the
IBM
Tivoli
Service
Level
Advisor
Launchpad
installation
program
and
try
creating
the
database
again
after
verifying
the
correct
port
number
has
been
entered
for
the
DB2
location.
See
Getting
Started
for
more
information
on
the
Launchpad
installation
program
and
creating
databases
for
IBM
Tivoli
Service
Level
Advisor.
Error
SQL0913N
Received:
Unsuccessful
execution
caused
by
deadlock
or
timeout
There
is
a
known
problem
that
most
often
occurs
when
running
one
of
the
DYK
ETL
processes
against
a
IBM
Tivoli
Service
Level
Advisor
database
that
is
located
on
a
DB2
for
z/OS
operating
system.
The
ETL
step
fails
with
a
message
that
indicates
a
deadlock
or
timeout
condition
has
occurred.
The
message
is
similar
to
the
following
example:
CDWEX8087E
A
general
SQL
error
occurred:
SQL_ERROR:
’ExecDirect’
2004.06.04
10:52:30.718
sqlState
=
57033,
nativeErr
=
-913,
errorMsg
=
[IBM][CLI
Driver][DB2]
SQL0913N
Unsuccessful
execution
caused
by
deadlock
or
timeout.
Reason
code
"00C9008E".
SQLSTATE=57033
This
error
usually
follows
a
drop
table
or
a
create
table
command.
The
error
is
typically
caused
by
multiple
outside
connections
to
the
same
location,
for
example,
connections
opened
through
the
DB2
Control
Center
or
by
DB2
command
prompts.
To
recover
from
this
error,
close
all
extraneous
connections
other
than
those
opened
by
IBM
Tivoli
Service
Level
Advisor
components,
and
try
the
failed
ETL
step
again.
Problems
Related
to
the
DB2
Data
Warehouse
Center
This
section
addresses
problems
you
may
have
in
logging
into
and
accessing
the
DB2
Data
Warehouse
Center.
Log
in
Fails:
Unexpected
Communication
Error
Login
to
the
DB2
Data
Warehouse
Center
fails
with
the
following
message:
DWC06200E
An
unexpected
communications
error
has
occurred.
Connection
refused:
no
further
information
RC
=
6200
RC2
=
0
This
usually
occurs
when
the
Warehouse
Server
service
on
the
Windows
platform
is
not
running.
Make
sure
that
both
the
Warehouse
Logger
and
Warehouse
Server
services
are
started
on
the
Windows
platform
that
has
been
designated
as
the
Control
Server.
After
both
services
are
started,
try
the
login
again.
Related
Documentation:
See
the
DB2
product
documentation
for
more
information
regarding
this
error
message.
44
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Login
Fails:
Unable
to
Retrieve
DB2
User
Login
to
the
DB2
Data
Warehouse
Center
fails
with
the
following
message:
DWC07035E
The
warehouse
server
was
unable
to
retrieve
user
"db2admin".
The
error
occurred
in
response
to
an
authentication
request
from
client
"clientHostNameHere".
[IBM][CLI
Driver][DB2/NT]
SQL1224N
A
database
agent
could
not
be
started
to
service
a
request,
or
was
terminated
as
a
result
of
a
database
system
shutdown
or
a
force
command.
SQLSTATE=55032
RC
=
7035
RC2
=
2014
This
occurs
when
the
connections
to
the
TWH_MD
database
required
by
the
Warehouse
Server
and
Warehouse
Logger
services
on
the
Windows
platform
have
been
severed.
From
the
Services
panel
on
the
Windows
platform,
stop
and
restart
the
Warehouse
Logger
and
Warehouse
Server
services.
Verifying
Connections
are
Established
To
verify
that
the
connections
are
established
after
stopping
and
starting
the
warehouse
services,
do
the
following
steps:
1.
Start
a
DB2
Command
Line
Processor
(CLP)
window
by
selecting
Start
–>
Run
and
issuing
the
db2cmd
command.
2.
From
the
CLP
window,
issue
the
following
commands:
db2
list
active
databases
The
output
for
the
TWH_MD
database
should
indicate
two
applications
connected.
3.
If
restarting
the
Warehouse
services
does
not
correct
the
problem,
verify
that
the
TWH_MD
database
can
be
connected
to
manually
using
the
following
command
from
a
DB2
CLP
window:
db2
connect
to
twh_md
user
<db2_username>
using
<db2_password>
If
the
connection
succeeds,
refer
to
the
troubleshooting
problem,
“Warehouse
Services
Missing
from
Control
Server”
on
page
46.
If
the
connection
does
not
succeed
with
the
correct
DB2
user
ID
and
password,
contact
Tivoli
Customer
Support.
Login
Fails:
Database
Specified
Does
Not
Match
Login
to
the
DB2
Data
Warehouse
Center
fails
with
the
following
message:
DWC01007E
Logon
Failed.
The
Database
specified
by
the
user
does
not
match
the
database
used
by
the
warehouse
server.
RC
=
1007
RC2
=
0
This
occurs
when
the
Data
Warehouse
Center
is
configured
with
an
incorrect
control
database.
To
resolve
this
problem,
do
the
following:
1.
From
the
Data
Warehouse
Center
login
screen,
click
Advanced.
2.
In
the
Control
Database
field,
enter
TWH_MD.
3.
Click
OK.
4.
Attempt
the
login
again.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
45
Related
Documentation:
See
the
DB2
product
documentation
for
more
information
regarding
this
error
message.
Warehouse
Services
Missing
from
Control
Server
This
problem
might
occur
if
one
or
both
of
the
warehouse
services
(Warehouse
Server
or
Warehouse
Logger)
are
missing.
This
could
occur
following
installation
of
a
fix
pack
on
top
of
an
existing
version
of
DB2,
where
the
migration
of
the
control
database
failed
during
the
fixpack
installation.
To
resolve
this
problem,
do
the
following
steps:
1.
Select
Start
–>
Programs
–>
IBM
DB2
–>
Warehouse
Control
Database
Management.
2.
On
the
subsequent
panel
that
is
launched,
in
the
New
control
database
field,
enter
TWH_MD.
3.
Enter
your
DB2
user
ID
and
password
in
the
corresponding
fields,
and
click
OK.
4.
After
the
processing
is
completed,
click
Cancel.
Note:
If
the
TWH_MD
database
already
exists,
this
procedure
will
not
recreate
it.
Related
Documentation:
See
the
DB2
product
documentation
for
more
information
regarding
this
error
message.
Problems
Related
to
Data
Retrieval
This
section
addresses
problems
in
retrieving
data
from
the
central
data
warehouse
or
the
SLM
databases.
Evaluating
Partial
or
Missing
Data
Data
is
retrieved
from
the
SLM
Measurement
Data
Mart
for
evaluation
and
trend
analysis
after
the
Process
ETL
has
completed
its
transfer
of
data
from
the
central
data
warehouse.
Occasionally,
some
data
might
not
be
available
in
the
SLM
Measurement
Data
Mart
at
the
time
of
the
scheduled
evaluation,
possibly
due
to
any
of
the
following
causes:
v
A
failed
source
application
v
A
source
application
only
reporting
part
of
the
data
for
a
given
time
period
v
A
failure
in
the
execution
of
the
source
or
process
ETLs
v
A
database
connection
problem
v
Incorrect
scheduling
of
the
Process
ETL
relative
to
the
timezones
specified
in
SLAs.
IBM
Tivoli
Service
Level
Advisor
only
detects
database
connection
failures
at
the
time
of
the
evaluation.
Data
missing
as
a
result
of
a
database
connection
failure
may
eventually
become
available
after
the
regularly
scheduled
evaluation
time.
When
data
is
detected
as
missing
the
evaluation
is
placed
in
the
active
retry
state
and
it
is
periodically
retried
a
configurable
number
of
times.
After
the
number
of
retries
has
been
exausted,
the
entry
is
moved
from
the
active
retry
state
to
the
stopped
retry
state
and
the
retry
process
ends.
46
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Retries
for
hourly
evaluations
go
directly
into
the
stopped
retry
state
because
the
retry
interval
is
longer
than
the
next
scheduled
evaluation.
There
are
no
retries
for
hourly
trend
actions
at
all
because
of
the
possibility
of
adversely
affecting
the
trend
with
out
of
sequence
data.
If
you
find
that
you
are
not
getting
data
in
your
reports
for
a
particular
SLA
or
resource,
you
can
run
the
following
command
to
see
if
there
is
a
source
application
reporting
partial
or
no
data:
scmd
mem
showStoppedRetry
This
command
shows
entries
that
are
in
the
active
retry
or
stopped
retry
state.
After
you
check
the
source
application
related
to
the
missing
SLA
or
resource
data
and
verify
that
it
is
reporting
data
correctly,
you
have
two
options:
v
If
the
source
application
finally
does
report
this
data
into
the
SLM
Measurement
Data
Mart,
you
should
run
the
following
command
to
force
the
evaluation
and
trend
processing
of
all
entries:
scmd
mem
retryMissedIntervals
–all
Note:
After
running
this
command,
the
SLAs
in
stopped
retry
state
may
cause
trend
information
to
not
be
reported
correctly.
v
If
the
source
application
failed
and
lost
the
monitoring
data,
or
for
some
other
reason
will
never
report
the
missing
data,
you
should
run
the
following
command
to
remove
those
stopped
retry
entries
for
the
affected
SLA
or
resource:
scmd
mem
removeStoppedRetryEntries
Note:
This
command
should
not
be
run
unless
you
are
sure
that
this
data
will
never
be
reported
by
the
source
application.
See
the
Command
Reference
for
details
on
these
commands.
No
Data
in
SLM
Reports
for
a
Specific
SLA
This
problem
might
occur
when
you
access
SLM
Reports
and
attempt
to
view
results
for
a
specific
SLA
ID,
but
in
the
Service
Level
Objectives
(SLO)
Results
section,
you
instead
observe
the
message:
No
data
for
the
specified
request
Possible
causes
for
this
problem
are
discussed
in
the
following
sections,
and
include
the
following
causes:
v
The
evaluation
has
not
yet
occurred.
v
The
evaluation
did
not
complete
because
data
is
missing.
v
No
valid
data
points
were
received
for
the
specific
SLA
or
resource.
v
A
schedule
state
of
no
service
was
assigned
to
this
specific
time
frame.
v
The
SLM
Server
cannot
write
the
evaluation
data
in
the
SLM
Database
(dyk_cat).
The
Evaluation
Has
Not
Occurred
Yet
If
the
evaluation
has
not
yet
occurred,
then
no
data
will
be
reported.
The
SLA
and
SLOs
are
both
associated
with
a
Service
Offering.
When
the
SLO
is
configured,
a
daily,
weekly,
or
monthly
frequency
is
specified
for
evaluation
and
trending.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
47
Evaluations
occur
when
the
Process
ETL
completes
the
transfer
of
new
measurement
data
from
Tivoli
Data
Warehouse
into
the
SLM
Measurement
Data
Mart.
SLO
evaluations
whose
end
times
occur
before
the
just
completed
Process
ETL,
and
that
occur
later
than
the
previous
run
of
the
Process
ETL
will
be
included.
In
addition,
when
an
SLA
is
first
configured,
a
start
time
for
the
first
evaluation
period
is
specified.
No
evaluations
will
take
place
for
SLOs
whose
SLA
start
time
is
later
than
the
last
run
of
the
Process
ETL.
The
determining
factor
as
to
whether
or
not
an
evaluation
should
have
occurred
is
not
the
current
date,
but
date
of
the
last
run
of
the
ETL.
Consider
the
following
example:
v
Today
is
February
3,
and
it
is
the
first
day
of
the
week.
v
The
Process
ETL
last
completed
a
successful
run
on
January
30.
v
An
SLO
has
been
defined
for
daily
evaluations
and
included
in
an
SLA
that
has
a
start
date
of
February
5.
v
An
SLO
has
been
defined
for
weekly
evaluations
and
included
in
an
SLA
that
has
a
start
date
of
January
20.
In
addition
the
weekly
SLO
has
been
configured
with
a
daily
intermediate
evaluation.
v
An
SLO
has
been
defined
for
monthly
evaluations
and
included
in
an
SLA
that
has
a
start
date
of
January
1.
SLM
reports
will
only
show
evaluations
for
the
weekly
SLO
(a
full
evaluation
of
the
week
from
January
20
through
January
26),
and
the
following
daily
intermediate
evaluations:
v
January
20
through
January
21
v
January
20
through
January
22
(note
that
each
succeeding
evaluation
occurs
for
data
at
the
beginning
of
the
weekly
SLO
evaluation
period,
on
January
20)
v
January
20
through
January
23
v
January
20
through
January
24
v
January
20
through
January
25
v
January
27
through
January
28
(note
that
there
is
no
daily
intermediate
evaluation
for
January
20
through
January
26,
because
the
normal
weekly
SLO
evaluation
is
performed.
Also
note
that
this
intermediate
evaluation
starts
on
the
first
day
of
the
new
week,
January
27.)
v
January
27
through
January
29
(again,
the
intermediate
evaluation
occurs
for
data
since
the
start
of
the
weekly
SLO
evaluation
period
on
January
27.
Also
note
that
since
the
last
Process
ETL
ran
on
January
30,
data
beyond
January
29
is
not
evaluated.)
If
the
Process
ETL
is
run
again
today
(February
3),
the
monthly
SLO
evaluation
for
January
1
to
January
30
will
be
performed,
another
full
weekly
SLO
evaluation
will
be
performed
for
January
27
through
February
2,
and
the
following
daily
intermediate
evaluations
are
performed:
v
January
27
through
January
30
(note
that
the
intermediate
evaluations
for
January
28
and
January
29
were
already
performed)
v
January
27
through
January
31
v
January
27
through
February
1
(again,
note
that
the
daily
evaluation
for
January
27
through
February
2
is
not
performed,
because
this
is
equivalent
to
the
normal
full
week
SLO
evaluation
period)
No
daily
SLO
evaluations
will
be
performed
because
the
SLA
does
not
start
until
February
5.
48
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
To
verify
that
your
SLA
evaluations
should
have
occurred,
complete
the
following
steps:
1.
Run
the
scmd
mem
showMetricEvaluators
command
with
the
–v
option,
specifying
the
SLA
ID
number
for
the
SLA
(see
the
Command
Reference
for
information
on
this
and
other
CLI
commands).
Verify
that
the
SLA
start
time
is
earlier
than
the
current
time.
2.
Using
the
output
from
the
scmd
mem
showMetricEvaluators
command,
note
the
index
number
listed
prior
to
each
SLO
within
the
SLA.
Run
the
scmd
mem
dumpData
command,
specifying
the
SLA
ID
,
the
index
number
for
the
SLO
missing
results
and
specify
1
for
the
–r
option.
In
the
output
listing,
note
the
date
of
the
most
recently
completed
ETL.
If
you
know
that
this
is
incorrect
(for
example,
the
Process
ETL
has
been
run
later
than
this
date),
the
polling
mechanism
that
informs
the
Metric
Evaluator
Manager
might
not
have
detected
this
latest
run
of
the
ETL.
Issue
the
scmd
wdccli
listSettings
command
and
determine
if
the
ETLPoll
period
is
reasonable.
The
default
is
10
minutes,
but
if
this
has
been
changed,
the
time
between
when
the
Process
ETL
completes
and
the
evaluation
process
begins
might
be
extended.
Note
that
the
date
of
the
most
recently
run
ETL
listed
in
the
output
of
the
scmd
mem
dumpData
command
will
not
be
updated
until
the
entire
set
of
SLA
evaluations
that
were
triggered
by
the
current
Process
ETL
is
executed,
so
you
should
allow
time
for
the
evaluations
to
complete
before
checking
if
the
poll
has
correctly
detected
the
most
recent
run
of
the
ETL.
If
there
is
still
a
discrepancy
between
the
last
detected
run
of
the
ETL
and
the
known
date
of
the
last
run
of
the
ETL,
contact
IBM
customer
support
for
further
help.
If
the
date
of
the
most
recently
run
ETL
is
correct
to
the
best
of
your
knowledge,
verify
that
the
SLA
start
time
is
earlier
than
the
time
of
the
most
recent
ETL
run.
3.
Using
the
output
from
scmd
mem
dumpDatacommand,
determine
the
evaluation
interval
specified
for
the
SLO
and
estimate
the
number
of
evaluation
periods
from
the
current
time
to
the
evaluation
period
you
are
investigating.
Issue
the
scmd
mem
dumpData
command
again,
using
the
estimate
for
the
–r
option.
The
output
will
list
all
evaluation
periods
up
to
the
period
requested,
so
if
your
estimate
is
incorrect,
you
should
be
able
to
identify
the
correct
one
and
run
the
command
again.Verify
that
the
end
time
of
the
missing
evaluation
period
occurs
earlier
than
the
most
recent
time
that
the
Process
ETL
was
run.
The
evaluation
did
not
complete
because
data
is
missing
This
is
related
to
the
troubleshooting
topic,
“Evaluating
Partial
or
Missing
Data”
on
page
46..
Data
is
retrieved
from
the
SLM
Measurement
Data
Mart
to
be
processed
for
trending
and
evaluation.
If,
due
to
temporary
network
or
database
outages,
data
is
unavailable
at
the
time
of
evaluation
or
trend
analysis,
the
evaluation
is
put
into
the
active
retry
state
and
the
evaluation
is
periodically
retried
a
configurable
number
of
times.
After
the
number
of
retries
has
been
exhausted,
the
entry
is
moved
from
the
active
retry
state
to
the
stopped
retry
state,
and
the
retry
process
ends.
For
the
case
that
no
results
were
published
for
a
particular
SLA,
there
is
a
possibility
that
the
evaluations
are
in
active
retry
or
stopped
retry
state.
Do
the
following:
1.
Examine
the
output
from
the
scmd
mem
dumpData
command
for
the
missing
evaluation
period.
If
the
retrieval
status
indicates
missing
data,
then
this
is
a
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
49
retry
scenario.
If,
however,
data
points
are
available,
then
it
is
still
possible
that
a
retry
scenario
was
triggered.
The
data
points
might
have
arrived
late
after
the
evaluation
was
first
tried.
2.
Using
the
output
from
the
scmd
mem
showMetricEvaluators
command
produced
earlier,
note
the
Service
Element
Instance
ID,
the
Metric
Evaluators
Instance
Identifier,
and
the
Resource
Name.
3.
Issue
the
scmd
mem
showRetrys
command.
The
command
displays
entries
that
are
in
the
stopped
retry
state
and
the
active
retry
state.
The
entries
in
the
stopped
retry
state
appear
above
the
separator
line,
and
the
entries
in
the
active
retry
state
appear
below.
Verify
if
the
values
mentioned
in
step
1
match
with
this
output.
If
the
values
match,
see
“Data
Extracted
From
Warehouse
Late”
on
page
52.
4.
After
fixing
the
problem
issue
the
scmd
mem
retryMissedIntervals
-all
command.
No
Valid
Data
Points
Received
for
the
Specific
SLA
or
Resource
It
is
possible
that
for
some
reason
no
data
points
were
collected
by
the
IBM
Tivoli
Service
Level
Advisor
data
collector
function
at
the
time
of
the
evaluation.
Metric
Evalutors
type
A
and
B1/B2
will
not
produce
any
results
for
evaluation
periods
that
do
not
have
data
points.
To
check
for
this,
do
the
following:
1.
Examine
the
output
from
the
scmd
mem
dumpData
command
for
the
missing
evaluation
period.
The
output
will
indicate
if
the
retrieval
status
was
successful
but
no
data
points
were
received.
Even
if
the
output
of
the
scmd
mem
dumpData
indicates
that
data
points
exist,
they
might
have
arrived
after
the
evaluation
was
completed.
For
metric
evaluator
type
A,
perform
steps
2
and
3
below
to
completely
eliminate
this
potential
cause.
2.
Examine
the
output
from
the
scmd
mem
ShowMetricEvaluators
command
and
note
the
Resource
Names
associated
with
this
specific
SLA.
For
example,
the
values
of
interest
might
be
similar
to
the
following:
v
/fvtsol17/slmfvt8
job3
v
/fvtaix18.rtp.lab.tivoli.com/slmfvt9
job_name1
v
/SLMFVT5.rtp.lab.tivoli.com/slmfvt5_sti
playback3.
Search
in
the
msgTSLA<n>.log
files
for
the
following
message:
DYKME9064W
0
datapoints
have
been
collected
for
the
evaluation
period:
<evaluation
period
start
time>
–
<evaluation
period
end
time>
ComponentName/MeasurementType/CustomerID:
<resource
name>
/
<measurement
type>
/
<SLA
ID>
This
may
not
be
expected.
Compare
the
values
for
Resource
Name
and
SLA
ID
in
the
message
with
the
specific
SLA
ID
and
the
associated
resource
names
observed
in
step
2
above.
In
this
example,
the
following
message
might
be
observed:
2002.02.15
11:06:41.095
DYKME9064W
0
datapoints
have
been
collected
for
the
evaluation
period:
Tue
Feb
12
00:00:00
EST
2002
-
Tue
Feb
12
23:59:59
EST
2002.
ComponentName/MeasurementType/CustomerID:
/fvtaix18.rtp.lab.tivoli.com/slmfvt9
job_name1/97/1005.
This
may
not
be
expected.
4.
If
the
output
of
the
scmd
mem
dumpData
command
shows
data
points
but
the
message
similar
to
that
in
step
3
is
also
displayed,
the
data
points
arrived
late
and
missed
the
evaluation.
See
“Data
Extracted
From
Warehouse
Late”
on
page
52.
50
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
5.
If
data
points
were
expected
for
this
resource
and
none
were
received
,
see
“Checking
the
Health
of
the
Central
Data
Warehouse.”
6.
Even
if
data
points
are
listed
in
the
output
of
the
scmd
mem
dumpData
comand,
it
is
possible
that
none
of
them
were
considered
valid
and
all
data
points
were
ignored
as
if
they
did
not
exist.
Search
in
the
msgTSLA<n>.log
files
for
the
following
messages
that
indicate
validation
problems
with
the
data
points:
DYKME9075E,
DYKME9076E,
DYKME9078E,
DYKME9079E,
DYKME9081E,
DYKME9082E,
DYKME9084E,
DYKME9085E,
DYKME9086E,
DYKME9087E,
DYKME9088E,
DYKME9089E,
DYKME9090E,
DYKME9091E,
DYKME9092E.
Checking
the
Health
of
the
Central
Data
Warehouse
To
further
diagnose
problems
that
might
be
related
either
to
data
not
being
in
the
warehouse
database
as
expected,
or
problems
with
IBM
Tivoli
Service
Level
Advisor
evaluating
that
data,
you
can
run
the
Tivoli
Data
Warehouse
Health
Tool
script,
which
can
be
obtained
from
the
IBM
Tivoli
Service
Level
Advisor
support
Web
site.
This
script
is
designed
to
query
Tivoli
Data
Warehouse
and
provide
information
about
the
overall
status
of
source
applications
that
are
putting
data
into
the
Tivoli
Data
Warehouse
database.
It
may
help
you
to
determine
if
data
is
not
in
the
warehouse
database
as
expected,
or
if
IBM
Tivoli
Service
Level
Advisor
has
problems
evaluating
existing
data.
To
use
the
Health
Tool,
do
the
following
steps:
1.
Point
your
browser
to
the
following
support
Web
site:
http://www.ibm.com/software/sysmgmt/products/support/
IBMTivoliServiceLevelAdvisor.html
2.
Scroll
down
the
Self
help
column
and
locate
the
Downloads
section.
3.
Under
Diagnostic,
select
the
IBM
Tivoli
Enterprise™
Data
Warehouse
Health
Tool
link.
4.
Download
the
cdw_health.zip
package
to
the
machine
where
your
Tivoli
Data
Warehouse
Control
Server
is
located.
5.
Save
it
to
a
temporary
directory.
6.
Use
your
unzip
utility
to
extract
the
files.
7.
From
a
DB2
command
prompt
window
on
the
Tivoli
Data
Warehouse
Control
Server
machine,
run
the
following
command,
where
<Warehouse_Name>
is
the
ODBC
datasource
name
of
the
Tivoli
Data
Warehouse
database,
<db2_userid>
is
the
DB2
user
name,
and
<db2_password>
is
the
DB2
password:
cdw_health
[-v]
<Warehouse_Name>
<db2_userid>
<db2_password>
In
the
above
command
syntax,
the
–v
parameter
is
an
optional
parameter
that,
when
specified,
displays
additional
information
and
more
detail
by
executing
additional
queries
to
help
further
identify
the
problem.
The
script
performs
a
number
of
queries
on
the
warehouse
database,
and
provides
information
such
as:
v
The
source
applications
that
Tivoli
Data
Warehouse
recognizes
as
being
registered,
by
application
name
and
code
v
The
total
number
of
measurement
records
that
exist
v
Additional
details
on
the
number
of
records
for
each
application
v
Timestamp
information
on
when
ETLs
were
last
run
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
51
The
following
results
may
be
of
particular
interest:
Number
of
measurement
records
per
Source
Application
If
0
records
exist
in
the
warehouse
for
a
particular
source
application,
the
ETL
for
that
application
has
never
successfully
completed
or
there
is
no
data
at
the
source
database
to
obtain.
Latest
date
of
measurement
record
per
Source
Application
If
the
date
of
the
latest
measurement
record
is
more
than
2
days
old,
something
has
caused
the
ETL
to
fail
or
there
is
no
new
information
at
the
source
database
to
obtain.
Latest
successful
extract
timestamp
from
the
Extract,
Transform,
and
Load
(ETL)
Applications
Refer
to
the
ETL
Source
Application
for
information
about
how
Extract
Control
is
used,
and
verify
that
timestamps
are
expected.
Any
dated
entries
should
raise
concern.
If
the
–v
parameter
is
specified,
an
additional
query
provides
even
more
detailed
information
on
the
number
of
measurement
records
per
measurement
type
for
each
source
application.
For
additional
information
or
assistance
in
using
the
cdw_health
script,
contact
Tivoli
Customer
Support.
A
Schedule
State
of
No
Service
was
Assigned
to
this
Time
Frame
The
data
was
retrieved
by
the
SLM
Server
for
evaluation
and
trend
analysis,
but
the
data
in
this
evaluation
period
is
associated
with
a
schedule
state
of
No
Service.
The
SLA
is
associated
with
an
offering,
which
includes
defined
schedules
with
different
times
assigned
to
different
schedule
states.
This
enables
IBM
Tivoli
Service
Level
Advisor
to
offer
multiple
levels
of
service,
tailored
to
the
user’s
specific
business
schedule
needs.
One
of
these
schedule
states,
No
Service,
is
designed
to
not
publish
results
in
that
time
period,
so
resources
can
be
brought
down
for
maintenance
without
generating
false
violations
and
trends.
Check
the
schedule
periods
for
this
SLA.
If
all
of
the
valid
data
occurs
within
the
schedule
period
associated
with
the
No
Service
state,
then
no
results
should
be
expected.
The
SLM
Server
Cannot
Write
the
Evaluation
Data
in
the
SLM
Database
See
the
related
problem,
“Unable
to
Publish
Service
Monitor
Results”
on
page
41
for
details
on
this
possible
cause
of
your
problem.
Data
Extracted
From
Warehouse
Late
SLA
evaluations
depend
on
the
availability
of
application
data
in
the
SLM
Measurement
Data
Mart
at
the
time
that
evaluations
are
performed.
You
must
be
careful
to
coordinate
the
execution
schedules
of
the
source
and
target
ETLs
with
the
evaluation
and
trend
analysis
schedules
on
the
SLM
Server.
These
events
can
occur
on
multiple
machines
in
different
time
zones,
but
SLA
evaluations
are
scheduled
to
occur
relative
to
the
time
zone
in
which
the
SLM
Server
is
located.
SLA
evaluations
occur
on
data
that
has
been
extracted
from
the
warehouse
database
by
the
most
recent
run
of
the
Process
ETL.
In
general,
it
is
always
important
to
ensure
that
the
process
ETL
is
scheduled
at
a
time
that
will
extract
data
from
the
CDW
after
the
source
ETLs
have
completed
writing
data
into
the
CDW.
Some
source
ETLs,
however,
only
move
data
for
the
52
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
previous
day
based
on
the
time
zone
of
their
local
machines
on
which
they
are
running.
In
addition,
special
consideration
for
ETL
scheduling
should
be
given
in
environments
where
SLAs
are
supported
for
time
zones
that
are
west
of
the
SLM
server
timezone.
To
ensure
proper
SLA
evaluations,
you
must
maintain
the
following
order
of
events:
1.
Determine
the
time
zones
that
are
specified
in
existing
SLAs
(and
also
determine,
if
possible,
time
zones
that
you
will
likely
specify
in
future
SLAs)
and
the
time
zone
of
the
SLM
server,
and
select
the
one
which
is
most
west
of
Greenwich
Mean
Time
(GMT)
plus
12
hours
(GMT+
12).
This
is
our
reference
time
zone,
and
the
remaining
steps
in
this
procedure
should
be
performed
to
start
after
midnight
in
that
reference
time
zone.
2.
Source
ETL
executions
occur
to
move
the
previous
day’s
data
into
the
CDW.
By
using
the
westernmost
time
zone
as
a
reference,
any
source
ETL
operating
in
a
different
time
zone
will
have
also
concluded
the
previous
day
in
its
time
zone.
3.
The
execution
of
the
Registration
ETL
occurs
after
the
source
ETLs
complete
their
processing,
moving
data
from
the
warehouse
into
the
SLM
Database.
Note:
This
is
only
a
one
time
step
when
a
new
source
ETL
is
supported,
and
does
not
have
to
be
repeated
each
time
new
data
for
the
same
source
ETL
is
transferred.
4.
The
execution
of
the
Process
ETL
occurs
after
the
Registration
ETL
completes,
moving
data
from
the
warehouse
into
the
SLM
Measurement
Data
Mart.
5.
SLA
evaluations
and
trend
analysis
occurs.
For
more
information
on
Tivoli
Data
Warehouse,
see
the
documentation
for
that
product.
Also,
see
Managing
Service
Level
Agreements
for
related
information
on
defining
time
zones
and
considerations
for
specifying
the
frequency
of
evaluations
and
trend
analyses.
Updating
an
Evaluation
Based
on
the
Arrival
of
Late
Data
There
is
no
automatic
way
to
update
an
evaluation
that
has
occurred
based
on
the
arrival
of
additional
data
for
that
evaluation
interval.
It
is
best
to
avoid
this
problem
by
correctly
scheduling
source
and
process
ETLs.
Once
the
problem
has
occurred,
however,
you
can
still
take
some
steps
to
possibly
correct
the
situation.
See
the
Command
Reference
for
information
on
using
the
scmd
mem
reEval
command
to
perform
re-evaluations
of
late
data.
Receiving
Too
Many
DYKME9094
Messages
During
the
creation
of
an
offering,
you
have
the
option
of
configuring
advanced
metric
settings,
including
the
indication
that
missing
data
is
to
be
considered
an
error
condition.
This
is
usually
enabled
when
you
are
expecting
at
least
one
data
point
in
every
evaluation
interval,
for
example,
if
a
source
application
is
writing
availability
polling
data
on
a
regular
basis,
such
as
every
hour.
If
this
Missing
Data
check
box
is
checked
in
the
advanced
settings
for
the
offering,
but
there
is
no
source
application
that
is
legitimately
supplying
data
points
for
every
evaluation
period,
then
you
will
receive
many
DYKME9094
messages
indicating
that
there
are
missing
data
conditions.
To
resolve
this,
verify
that
there
are
source
applications
that
should
be
supplying
this
data,
and
correct
any
problems
related
to
data
being
written
to
the
central
data
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
53
warehouse.
Also,
verify
that
an
offering
was
not
inadvertently
configured
to
check
for
missing
data
if
there
are
no
source
applications
supplying
this
data.
You
might
need
to
disable
this
check
if
necessary.
Problems
Related
to
ETLs
This
section
includes
troubleshooting
topics
related
to
processing
the
Registration
and
Process
target
ETLs
to
extract
data
from
the
Tivoli
Data
Warehouse
database
and
load
it
into
the
SLM
Database
and
SLM
Measurement
Data
Mart.
SLM
ETL
Step
Failed
This
problem
occurs
when
the
Work
in
Progress
window
of
the
DB2
Data
Warehouse
Center
shows
a
Registration
ETL
or
Process
ETL
step
with
a
status
of
failed.
To
determine
the
cause
of
the
problem,
examine
the
log
file
in
the
<Tivoli
Common
Directory>\cdw\logs\etl
directory
where
<Tivoli
Common
Directory>
is
the
directory
path
location
where
the
Tivoli
Common
Directory
is
located.
The
file
name
will
be
the
same
as
the
step
that
failed
and
the
file
extension
will
be
log.
Verify
connectivity
to
the
databases
by
checking
the
following:
1.
Verify
that
ODBC
data
sources
named
TWH_CDW,
DYK_CAT,
and
DYK_DM
have
been
created
correctly.
2.
Verify
that
the
warehouse
source
and
target
databases
for
the
databases
listed
above
have
been
configured
with
the
correct
user
ID
and
password
information.
3.
In
the
DB2
Data
Warehouse
Center,
expand
the
warehouse
source
and
target
folders
and
for
each
source
or
target
with
a
name
that
begins
with
DYK,
select
a
table
and
attempt
to
sample
its
contents.
4.
Verify
that
a
connection
to
each
of
the
above
databases
can
be
made
using
the
DB2
command
line
processor
by
issuing
the
following
commands:
db2cmd
db2
connect
to
<db_name>
user
<yourDB2Userid>
using
<yourDB2Password>
For
example:
C:\db2
connect
to
dyk_cat
user
myUserid
using
myPassword
Related
Documentation:
For
information
on
how
to
manually
create
ODBC
data
sources
and
how
to
set
user
IDs
and
passwords
for
warehouse
source
and
target
databases,
see
Getting
Started.
Schedules
Changing
in
Work
In
Progress
Display
When
you
schedule
an
ETL
to
run
on
a
regular
basis,
the
schedule
information
is
available
in
the
Work
In
Progress
dialog
of
the
Data
Warehouse
Center.
If
desired,
you
can
select
a
process
and
click
Run
Now
and
the
process
will
be
run
immediately
instead
of
waiting
for
the
normally
scheduled
time.
The
normally
scheduled
ETL
will
not
be
run,
but
will
be
rescheduled
to
run
at
the
next
regularly
scheduled
interval.
For
example,
assume
you
have
an
ETL
scheduled
to
run
daily
at
5:00pm.
If
you
select
this
ETL
at
2:00pm
on
Tuesday
and
run
it
immediately,
the
regularly
scheduled
run
at
5:00pm
on
Tuesday
will
be
rescheduled
to
run
on
Wednesday
at
5:00pm.
If
you
still
want
the
ETL
to
run
at
5:00pm
on
Tuesday,
select
Run
Now
again
at
that
time
to
run
it
immediately.
54
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Recovering
From
SLM
ETL
Failure
It
is
important
to
coordinate
the
scheduling
of
when
source
and
target
ETLs
are
run,
with
source
ETLs
putting
data
into
the
central
data
warehouse
according
to
their
schedule,
and
target
ETLs
extracting
data
from
the
warehouse
database
for
use
by
IBM
Tivoli
Service
Level
Advisor
on
an
independent
schedule
and
frequency
to
evaluate
and
analyze
for
violations
and
trends.
You
must
coordinate
when
these
ETLs
are
run,
to
make
sure
that
processing
of
data
from
the
source
applications
is
completed
before
the
target
ETLs
extract
that
data
for
evaluation.
Problems
can
occur
in
moving
data
when
any
of
the
following
happens:
v
A
target
ETL
is
run
while
a
source
ETL
is
still
running
v
A
target
ETL
is
run
multiple
times
after
a
source
ETL
completes,
causing
duplicate
data
to
be
retrieved
v
In
the
case
of
migrating
from
a
previous
version
of
IBM
Tivoli
Service
Level
Advisor,
there
might
be
a
mismatch
between
the
version
of
the
target
ETL
and
the
versions
of
the
IBM
Tivoli
Service
Level
Advisor
database
schemas.
Recovering
from
Duplicate
Data
Errors
The
specific
problem
of
duplicate
data
errors
may
be
present
if
you
find
a
message
similar
to
the
following
in
the
log:
SQL0803N
One
or
more
values
in
the
INSERT
statement,
UPDATE
statement,
or
foreign
key
update
caused
by
a
DELETE
statement
are
not
valid
because
the
primary
key,
unique
constraint
or
unique
index
identified
by
"1"
constrains
table
"DYK.EXT_TOT"
from
having
duplicate
rows
for
those
columns.
SQLSTATE=23505
This
message
means
that
the
ETL
is
attempting
to
write
data
into
the
dyk_dm
database,
but
there
is
already
duplicate
data
in
dyk_dm,
so
nothing
is
written
into
dyk_dm.
To
isolate
the
cause
of
this
failure,
do
the
following
steps:
1.
Verify
that
the
source
and
target
ETLs
are
scheduled
at
the
right
times
and
frequencies
such
that
the
target
ETLs
do
not
run
before
the
source
ETLs
complete
their
processing.
2.
Check
to
see
if
the
target
ETL
is
running
multiple
times
after
the
source
ETL
completes,
and
adjust
the
schedules
accordingly.
3.
Verify
that
the
version
of
the
target
ETL
in
use
is
compatible
with
the
version
of
the
database
schema
used
by
dyk_dm.
If
you
are
migrating
from
a
previous
version
of
IBM
Tivoli
Service
Level
Advisor,
you
must
uninstall
the
current
Process
ETL
and
install
the
compatible
version.
After
the
ETL
schedules
have
been
adjusted
or
the
target
ETL
has
been
uninstalled
and
reinstalled
to
the
correct
version,
recalibrate
the
Extract
Log
for
the
Process
ETL.
Note:
You
should
complete
the
following
procedure
only
for
recovering
from
problems
with
duplicate
data.
Using
the
DB2
Data
Warehouse
Center
on
the
control
server
machine,
do
the
following:
1.
Locate
the
ETL
Process
step
with
...Update_Extract_Control
in
the
step
name
for
the
ETL
that
failed
(Registration
ETL
or
Process
ETL).
2.
Change
the
mode
of
this
step
from
Production
mode
to
Test
mode.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
55
3.
Run
the
step
by
right-clicking
it
and
selecting
Test
in
the
resulting
context
menu.
4.
Place
the
step
back
in
Production
mode
if
it
was
in
Production
mode
previously.
After
completing
the
above
steps,
run
the
entire
ETL
again
from
beginning
to
end
without
duplicate
data
failures.
If
this
does
not
correct
the
problem,
then
you
will
need
to
contact
IBM
customer
support
for
assistance.
Problems
Related
to
the
SLM
Administrative
Console
This
section
addresses
problems
in
using
the
SLM
Administrative
Console
graphical
user
interface
of
IBM
Tivoli
Service
Level
Advisor.
User
Sign-On
Fails
If
WebSphere
security
is
enabled
when
you
bring
up
the
SLM
Admininstrative
Console,
a
sign-on
screen
is
presented
for
you
to
enter
a
valid
user
name
and
password.
If
your
user
name
or
password
fails
or
you
need
to
obtain
a
new
user
name
or
reset
your
password,
see
your
SLM
Administrator.
Typically
the
SLM
Administrator
will
create
a
user
group
and
associate
it
to
a
particular
role,
such
as
Offering
Specialist.
After
restarting
the
SLMAdmin
application
in
WebSphere,
individual
user
names
can
be
added
to
or
removed
from
the
group
as
desired,
without
restarting
the
SLMAdmin
application.
However,
if
a
new
user
is
added
to
an
existing
group,
you
must
wait
approximately
10
to
15
minutes
for
the
user
credentials
to
be
refreshed
in
WebSphere
before
you
can
attempt
to
sign
on.
Note
that
if
you
attempt
to
sign
on
before
the
user
credentials
are
refreshed,
the
sign
on
will
fail
and
the
wait
time
will
be
restarted.
The
Administrator’s
Guide
contains
information
on
creating
and
configuring
user
names
and
passwords,
associating
users
to
roles,
and
enabling
and
disabling
WebSphere
security.
Tasks
not
Displayed
in
Portfolio
If
you
expect
a
task
to
appear
in
the
portfolio
portion
of
the
SLM
Administrative
Console
but
do
not
see
it
listed,
it
might
be
because
the
user
name
that
you
used
to
sign
on
to
the
SLM
Administrative
Console
is
not
associated
with
the
desired
role
that
is
mapped
to
that
task.
You
should
check
with
your
SLM
Administrator
to
verify
that
you
are
using
the
correct
user
name
and
that
the
user
name
has
the
proper
roles
assigned.
Tivoli
Common
Directory
Logs
Not
Accessible
If
you
are
trying
to
access
log
files
in
the
Tivoli
Common
Directory
but
are
denied
access,
it’s
possible
that
your
system
user
ID
has
not
been
added
to
the
tivoli
user
group.
Files
in
the
Tivoli
Common
Directory
are
assigned
to
the
tivoli
user
group,
and
your
Administrator
should
have
given
your
user
name
access
to
this
group
when
your
IBM
Tivoli
Service
Level
Advisor
user
name
was
first
created.
Refer
to
“Accessing
Log
Files”
on
page
2
for
more
information,
and
contact
your
Administrator
about
adding
you
to
the
tivoli
group.
56
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Resource
Name
Incorrectly
Specified
When
Renaming
a
Resource
When
resource
names
appear
in
a
table
column,
they
are
underlined
because
the
name
is
an
HTML
link
to
open
a
View
Resource
window.
If
a
resource
name
includes
underscore
characters
or
blank
spaces,
it
might
be
difficult
to
see
because
the
HTML
link
underline
masks
the
underscore
characters.
You
might
encounter
this
problem
while
using
the
replace
function
to
rename
a
resource.
Instead
of
typing
the
resource
name
manually,
select
the
resource
name
by
using
the
system
clipboard
feature
to
cut
and
paste
the
resource
name
as
desired.
Object
Description
not
Fully
Displayed
If
you
create
an
object,
for
example,
a
customer
or
realm,
with
a
description
that
is
significantly
long
(500
characters
or
more),
and
afterward
you
notice
that
the
″Manage″
page
for
that
object
does
not
show
the
complete
description
in
the
fly-over
pop-up
window
when
you
move
the
cursor
over
the
description
in
the
table),
it
is
possible
that
you
do
not
have
your
Internet
Explorer
display
settings
configured
correctly.
From
the
Internet
Explorer
tool
bar
at
the
top
of
the
page,
select
Tools
->
Internet
Options.
In
the
General
tab,
under
Temporary
Internet
files,
click
the
Settings
button.
Verify
that
the
Check
for
new
versions
of
stored
pages
option
is
set
to
Automatically.
This
is
the
only
supported
option.
Display
of
Time
Zone
Offset
is
Incorrect
If
the
time
zone
offset
is
displayed
as
GMT-??:??,
the
time
zone
is
unknown
to
the
current
operating
environment
of
the
SLM
Server.
This
might
occur
if
you
did
not
complete
all
of
the
steps
in
upgrading
from
a
previous
release
of
IBM
Tivoli
Service
Level
Advisor.
See
Getting
Started
for
details
on
upgrading
from
a
previous
release.
Problems
Related
to
the
SLM
Server
This
section
addresses
problems
that
you
might
encounter
with
the
SLM
Server
option
of
IBM
Tivoli
Service
Level
Advisor.
Out
of
Java
Memory
If
you
run
out
of
Java
memory,
you
can
increase
the
setting
by
doing
the
following:
v
For
Windows
systems,
you
can
do
either
of
the
following
procedures:
–
Use
regedit
to
alter
the
registry,
by
doing
the
following:
1.
Start
regedit
(select
Start
–>
Run,
then
enter
regedit)
2.
Navigate
to
the
following:
My
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\tslm\Parameters
3.
Locate
the
following:
Name:
jvmOption5
4.
Modify
the
-Xmx384m
parameter,
changing
the
384
to
a
larger
number,
such
as
512
or
1024.–
Modify
the
setting
in
the
tslmconfig
file
by
doing
the
following:
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
57
1.
Stop
the
SLM
Server
(from
a
command
prompt,
issue
the
command:
net
stop
tslm,
or
see
″Shutting
Down
the
SLM
Server″
in
Chapter
6
of
Getting
Started
for
more
information)
2.
Navigate
to
the
following
directory,
where
<sla_install_dir>
is
the
location
where
the
SLM
Server
option
of
IBM
Tivoli
Service
Level
Advisor
is
installed:
<sla_install_dir>\bin\common
3.
Edit
tslmconfig
by
modifying
the
line
containing
the
-Xmx384m
parameter,
changing
the
384
to
a
larger
number,
such
as
512
or
1024.
4.
Navigate
to
<sla_install_dir>\bin
5.
At
a
command
prompt,
run
the
following
command
to
temporarily
remove
IBM
Tivoli
Service
Level
Advisor
as
a
service:
jservice
-u
<sla_install_dir>\bin\common\tslmconfig
6.
At
a
command
prompt,
run
the
following
command
to
restore
IBM
Tivoli
Service
Level
Advisor
as
a
service
with
the
new
java
memory
specification:
jservice
-i
<sla_install_dir>\bin\common\tslmconfig
7.
Start
the
SLM
Server
(from
a
command
prompt,
issue
the
command:
net
start
tslm,
or
see
″Starting
the
SLM
Server″
in
Chapter
6
of
Getting
Started
for
more
information)v
For
UNIX
systems
do
the
following
steps:
1.
Stop
the
SLM
Server
(navigate
to
the
<sla_install_dir>/bin
directory,
where
<sla_install_dir>
is
the
location
where
the
SLM
Server
option
of
IBM
Tivoli
Service
Level
Advisor
is
installed,
and
run
the
following
command:
./slm_service_stop.sh
2.
Edit
<sla_install_dir>/service_util/slm_start.sh
by
modifying
the
line
containing
the
-Xmx384m
parameter,
changing
the
384
to
a
larger
number,
such
as
512
or
1024.
3.
Restart
the
SLM
Server
(navigate
to
the
<sla_install_dir>/bin
directory
and
run
the
following
command:
./slm_service_start.sh
Windows
Error
1053
Encountered
During
Start-up
During
startup
of
IBM
Tivoli
Service
Level
Advisor,
you
might
encounter
the
following
Windows
error
message:
Error
1053:
The
service
did
not
respond
to
the
start
or
control
request
in
a
timely
fashion.
This
is
a
known
Microsoft
service
error.
It
is
possible
that
the
service
may
still
be
starting,
but
it
is
taking
longer
than
usual
to
start
up.
You
should
click
OK
to
continue
to
wait
for
the
service
to
start.
The
Microsoft
documentation
states
that
this
message
may
appear,
but
the
service
may
actually
start
eventually.
Refer
to
the
following
Web
site
for
details
on
this
troubleshooting
topic:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q278712
Trend
Tracking
Information
Cleared
when
SLM
Server
is
Stopped
The
state
information
used
for
trend
calculation
is
cleared
when
the
SLM
Server
is
stopped.
To
minimize
the
impact
of
clearing
state
information
on
predicting
new
trends
and
canceling
existing
trends,
stop
the
SLM
Server
only
when
necessary.
58
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
SLM
Server
Appears
Hung
During
Historical
Evaluations
When
multiple
SLAs
are
submitted
that
have
start
dates
in
the
past,
it
might
appear
that
the
SLM
Server
is
in
a
hung
state
because
the
SLAs
have
not
finished
processing
their
historical
evaluations,
which
in
some
cases
can
take
a
significant
amount
of
time.
Use
the
scmd
mem
skipHistoricSLAs
CLI
command
to
indicate
that
SLAs
that
were
submitted
with
a
start
date
in
the
past
but
have
not
yet
been
deployed
or
evaluated
should
not
have
historical
evaluations
performed,
but
still
be
deployed
for
the
next
regularly
scheduled
evaluation.
See
the
Command
Reference
for
more
information
about
this
CLI
command.
Problems
Related
to
Creating
Offerings
and
SLAs
This
section
addresses
problems
that
you
might
encounter
while
building
offerings
and
SLAs.
Evaluation
Frequency
Selection
List
Does
Not
Include
Hourly
Intervals
During
offering
creation,
as
you
include
metrics
in
your
offering,
you
must
specify
the
frequency
at
which
evaluations
will
be
performed
for
each
metric.
You
might
be
expecting
to
see
the
selection
list
for
Evaluation
Frequency
to
include
intervals
other
than
Daily,
Weekly,
or
Monthly.
Additional
evaluation
frequency
selections
can
be
enabled
by
issuing
the
scmd
mem
showHourlyFrequencyIntervals
enable
command.
See
the
Command
Reference
for
more
information
on
this
CLI
command.
Evaluation
frequency
settings
of
less
than
Daily
should
only
be
enabled
and
included
in
an
offering
if
you
have
source
applications
that
are
writing
data
to
Tivoli
Data
Warehouse
more
than
once
per
day.
You
should
verify
with
your
database
administrator
that
source
applications
and
their
ETLs
have
been
configured
to
provide
this
data
more
than
once
per
day.
No
Selectable
Resources
in
Create
Offering
Window
This
problem
occurs
during
offering
creation,
when
there
are
no
selectable
resources
displayed
in
the
Resource
Type
Tree
of
the
Create
Offering
Component
dialog.
This
error
might
be
caused
by
several
problems:
v
The
Registration
ETL
has
not
been
run
at
least
once
prior
to
creating
offerings.
v
The
Registration
ETL
has
not
run
successfully.
v
The
Registration
ETL
has
run,
but
no
source
applications
have
been
enabled.
v
The
Registration
ETL
has
run
with
enabled
source
applications,
but
the
SLM
Server
has
not
yet
registered
the
warehouse
data
into
the
DYK_CAT
database.
To
resolve
this
problem,
try
the
following:
1.
Verify
that
the
desired
source
applications
whose
data
is
to
be
managed
in
the
SLM
environment
have
been
enabled
in
the
SLM
Server
(using
the
scmd
etl
enable
or
scmd
etl
addApplicationData
CLI
commands).
2.
Examine
the
DB2
Data
Warehouse
Center
to
verify
that
the
DYK_m05_Populate_Registration_Datamart
process
has
executed
successfully.
If
this
process
failed
the
last
time
it
was
run,
try
running
it
again.
If
it
continues
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
59
to
fail,
examine
the
log
files
located
in
the
following
directories,
where
<sqllib_dir>
is
the
directory
where
the
DB2
Data
Warehouse
Center
is
installed:
<sqllib_dir>\logging\dyk_m05_s010_Populate_STAGE_Data.log
<sqllib_dir>\logging\dyk_m05_s020_Populate_Reg_Datamart.log
3.
Make
sure
that
you
have
waited
at
least
15-20
minutes
after
the
initial
run
of
the
Registration
ETL,
to
give
the
SLM
Server
an
opportunity
to
register
the
warehouse
data
for
use
in
building
offering
components.
Setting
up
for
Automatic
Notification
To
set
up
automatic
notification
of
failures
of
this
or
any
ETL
process,
do
the
following
from
within
the
DB2
Data
Warehouse
Center:
1.
Expand
the
Subject
Areas
folder
to
the
process
that
you
want
to
set
up
for
notification.
2.
Left-click
on
the
process
to
select
it,
then
right-click
to
bring
up
the
context
menu
and
select
Notification.
3.
Configure
the
Notification
tab
by
doing
the
following
steps:
a.
Notify
on
failure.
b.
Select
one
or
more
Data
Warehouse
Center
users
(verify
that
addresses
have
been
configured
for
the
selected
users).
c.
Enter
server.
d.
Click
Add.
e.
Click
OK.
Related
Documentation:
For
information
on
how
to
configure
and
run
the
registration
ETL
process,
see
Getting
Started.
For
information
on
the
CLI
commands,
see
the
Command
Reference.
No
Measurement
Sources
Available
for
the
Component
Type
When
creating
an
offering,
a
user
clicking
the
Next
button
on
the
Select
Resource
Type
dialog
of
the
Create
Offering
Component
wizard
might
get
an
error
message
popup:
DYKGU0071E
There
are
no
measurement
sources
available
for
the
component
type
<component
type
name>
This
might
occur
immediately
following
the
IBM
Tivoli
Service
Level
Advisor
installation,
or
after
the
SLM
Database
(dyk_cat)
has
been
rebuilt.
One
possible
cause
of
this
error
is
if
a
source
application
was
disabled
with
the
scmd
etl
disable
command,
but
the
source
application
is
still
shown
in
bold
text
in
the
Select
Resources
list.
If
it
is
selected,
you
will
get
this
error
message.
Until
the
Registration
ETL
is
run
again,
this
application
should
not
be
used
for
any
offerings.
In
this
case
the
information
in
the
remainder
of
this
troubleshooting
section
does
not
apply.
Another
possible
cause
of
this
might
be
that
the
data
from
the
Tivoli
Data
Warehouse
database
has
not
yet
been
registered
with
IBM
Tivoli
Service
Level
Advisor.
Running
the
Registration
ETL
fills
in
some
portions
of
the
SLM
Database,
but
all
of
the
information
needed
to
create
an
offering
is
not
there
until
SDC
is
running
and
gets
a
chance
to
run
its
own
data
registration.
To
further
diagnose
this
problem,
do
the
following
steps:
60
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
1.
Run
the
following
CLI
command
to
determine
if
Service
Elements
exist
in
the
SLM
Database:
scmd
sdc
displayActiveServiceElements
2.
If
there
is
no
output
from
this
command,
attempt
to
manually
register
the
warehouse
data
with
the
following
command:
scmd
sdc
registerWarehouseData
3.
Run
the
following
command
again
and
verify
that
there
is
output
as
a
result:
Scmd
sdc
displayActiveServiceElements
4.
If
there
still
are
no
active
Service
Elements
then
ensure
that
the
IBM
Tivoli
Service
Level
Advisor
Registration
ETLs
have
been
run.
5.
If
the
SLM
Server
is
not
readily
available,
you
can
also
examine
a
table
in
the
SLM
Database
to
determine
if
data
exists
in
the
SLM
Database:
a.
Set
up
a
DB2
environment.
v
For
Windows
systems,
select
Start
–>
Run
and
enter
db2cmd.
v
For
UNIX
systems,
run
the
following
command,
where
<DB2_instance_dir>
is
the
DB2
instance
directory:
.
/<db2_instance_dir>/sqllib/db2profile
b.
Run
the
following
command
to
reconnect
to
the
SLM
Database:
db2
connect
to
dyk_cat
user
<db2_UserID>
using
<db2_password>
c.
Run
the
following
command:
db2
select
*
from
svc_scope
If
this
table
is
empty,
then
this
is
the
reason
for
the
DYKGU0071E
message.
d.
Run
the
following
command
to
disconnect
from
the
SLM
Database:
db2
disconnect
from
dyk_cat
Internal
Error
While
Creating
Offering,
SLA,
Customer,
or
Realm
If
you
attempt
to
create
a
customer,
realm,
offering,
or
SLA,
and
you
receive
an
Internal
error
occurred
message,
check
for
a
message
similar
to
the
following:
DB21034E
The
command
was
processed
as
an
SQL
statement
because
it
was
not
a
valid
Command
Line
Processor
command.
During
SQL
processing
it
returned:
SQL0803N
One
or
more
values
in
the
INSERT
statement,
UPDATE
statement,
or
foreign
key
update
caused
by
a
DELETE
statement
are
not
valid
because
the
primary
key,
unique
constraint
or
unique
index
identified
by
"1"
constrains
table
"DB2INST1.REALM"
from
having
duplicate
rows
for
those
columns.
SQLSTATE=23505
This
message
occurs
because
IBM
Tivoli
Service
Level
Advisor
is
attempting
to
create
an
object
with
the
same
ID
as
an
existing
object.
An
internal
table
called
ID_GENERATOR
keeps
track
of
objects
as
they
are
created.
If
you
restored
or
imported
your
database
tables
but
did
not
include
the
ID_GENERATOR
table,
incorrect
assigning
of
IDs
to
created
objects
may
occur.
To
prevent
this
problem,
include
the
ID_GENERATOR
table
when
you
restore
or
import
your
databases.
To
fix
this
problem,
run
the
following
CLI
command:
scmd
sdc
adjustIdGenerators
This
command
will
adjust
the
mechanism
that
IBM
Tivoli
Service
Level
Advisor
uses
to
determine
the
next
ID
for
each
object
type.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
61
The
same
trouble
shooting
can
be
applied
to
customers,
realms
and
service
offerings.
If
the
problem
persist,
contact
Tivoli
Customer
Support.
See
the
Command
Reference
for
details
on
the
use
of
scmd
sdc
adjustIdGenerators.
Error
Message
SQL0911N
Received,
Current
transaction
rolled
back
because
of
deadlock
or
timeout
While
creating
offerings
and
SLAs
you
might
receive
the
following
error
message:
SQL0911N
The
current
transaction
has
been
rolled
back
because
of
a
deadlock
or
timeout.
Reason
code
"2".
SQLSTATE=40001"
This
problem
might
occur
if
certain
DB2
configuration
settings
are
not
adequate
for
your
enterprise
environment.
For
details
on
how
to
configure
DB2
Universal
Database
for
this
problem,
see
″Configuring
DB2
Settings″
in
the
Administrator’s
Guide
for
IBM
Tivoli
Service
Level
Advisor.
Unable
to
Submit
an
SLA
When
submitting
an
SLA
using
the
SLM
Administrative
Console,
the
attempt
fails
because
there
are
no
available
resources.
This
problem
might
be
caused
by
an
error
that
occurred
during
the
registration
of
warehouse
data
into
the
SLM
Server.
You
can
attempt
to
recover
from
this
problem
by
doing
the
following:
1.
Examine
the
MM.COMPPATH
table
in
DYK_CAT
for
records.
If
there
are
zero
records
in
this
table,
then
either
an
error
occurred
or
there
were
no
records
to
be
built.
2.
To
see
if
an
error
occurred,
examine
the
ffdc
logs
of
the
SLMServer.
If
an
error
did
occur
while
building
the
component
paths,
correct
any
database
or
connectivity
issues
that
might
have
caused
the
error
and
then
reissue
the
scmd
sdc
registerWarehouseData
command.
If
the
error
continues
to
be
logged,
contact
Tivoli
Customer
Support.
3.
If
there
are
no
errors
in
the
ffdc
logs
for
the
SLM
Server,
then
issue
the
following
query
from
a
DB2
command
line
against
the
DYK_CAT
database:
SELECT
COUNT(*)
FROM
MM.COMP
WHERE
COMPTYP_CD
IN
(SELECT
DISTINCT
COMPTYP_CD
FROM
MM.MSMTRUL)
If
this
query
returns
the
value
0,
then
there
are
no
component
resource
records
in
the
SLM
Measurement
Dat
a
Mart
for
warehouse
source
applications
that
have
been
enabled
in
IBM
Tivoli
Service
Level
Advisor.
If
there
are
no
component
resource
records
in
the
SLM
Measurement
Data
Mart,
verify
the
following:
v
Source
applications
to
be
used
with
IBM
Tivoli
Service
Level
Advisor
have
been
enabled
(see
chapter
5
of
Getting
Started
for
information
on
enabling
source
applications,
and
see
the
Command
Reference
for
information
on
the
scmd
etl
enable
command)
v
The
Registration
ETL
has
been
run
successfully
v
the
SLM
Server
has
had
a
chance
to
process
the
registration
data
(you
can
also
issue
the
scmd
sdc
registerWarehouseData
command
to
begin
processing
the
registration
data
immediately).
If
the
above
suggestions
have
been
attempted
but
the
problem
is
still
not
resolved,
then
the
central
data
warehouse
needs
to
be
examined
to
verify
that
the
source
applications
have
successfully
populated
the
database
with
the
necessary
data.
The
amount
of
time
that
the
SLM
Server
needs
to
process
and
build
the
component
information
in
the
SLM
Database
depends
on
the
number
of
records
62
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
certain
internal
tables,
and
the
applications
that
have
been
enabled
in
IBM
Tivoli
Service
Level
Advisor.
Only
the
component
information
for
enabled
applications
are
built.
To
determine
when
the
building
of
this
component
information
starts
and
ends,
and
the
number
of
component
paths
built,
examine
the
SLM
Server
message
log
(the
file
name
is
msgTSLAx.log)
for
messages
DYKET2501I
and
DYKET2502I.
These
messages
will
be
displayed
similar
to
the
following:
2004-02-17
17:19:50.484
myhost.raleigh.ibm.com
DYKET2501I
Starting
the
component
path
table
build
process.
2004-02-17
17:19:50.703
myhost.raleigh.ibm.com
DYKET2502I
Completed
the
component
path
table
build
process.
Total
component
path
resources
processed:
28
Multihomed
Host
A
multihomed
host
is
one
that
is
connected
to
two
or
more
networks,
or
that
has
two
or
more
network
addresses.
For
example,
a
network
server
might
be
connected
to
a
serial
line
and
a
LAN,
or
to
multiple
LANs.
If
your
SLM
Server
is
a
multihomed
host
and
you
receive
error
message
DYKGU0087E
while
attempting
to
submit
an
SLA,
then
the
wrong
IP
address
of
the
SLM
Server
might
be
in
use
during
remote
communication
from
the
SLM
Administration
Server.
Check
the
log
on
the
SLM
Administration
Server
machine
and
look
for
the
nested
errors
within
the
DYKGU0087E
message.
If
the
errors
indicate
a
connection
refused
or
an
inability
to
reach
the
host,
then
check
the
IP
address
in
the
referenced
message.
If
the
IP
address
referenced
in
the
message
is
not
accessible
to
the
SLM
Administration
Server
then
perform
the
following
steps:
v
For
Windows
systems,
do
the
following
steps:
1.
Select
Start
–>
Run,
and
enter
regedit.
2.
Navigate
to
My
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\tslm\Parameters.
3.
Create
a
new
String
value
named
jvmOption6.
4.
Modify
the
value
data
to
be
the
following,
where
<Fully_Qualified_SLM_Server_Hostname>
is
the
fully
qualified
hostname
of
the
SLM
Server
that
is
accessible
by
the
SLM
Administration
Server:
–Djava.rmi.server.hostname=<Fully_Qualified_SLM_Server_Hostname>
5.
Restart
the
SLM
Server.v
For
UNIX
systems,
do
the
following:
1.
Edit
the
file
<TSLM>/service_util/slm_start.sh.
2.
Add
the
following
to
the
JVMARGS
environment
variable,
where
<Fully_Qualified_SLM_Server_Hostname>
is
the
fully
qualified
hostname
of
the
SLM
Server
that
is
accessible
by
the
SLM
Administration
Server:
–Djava.rmi.server.hostname=<Fully_Qualified_SLM_Server_Hostname>
3.
Restart
the
SLM
Server.
Problems
Related
to
Event
Escalation
This
section
addresses
problems
you
might
encounter
during
event
escalation
and
notification
activities.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
63
Message
Logged:
DYKME9071I:
Violation
Detected
but
not
Published
You
might
receive
a
message
in
the
log
similar
to
the
following,
which
is
generated
when
a
violation
is
detected
against
an
SLA
that
was
submitted
after
the
start
time
of
the
current
evaluation
period:
DYKME9071I
A
violation
for
the
metric
<metric
name>
of
the
resource
<resource
name>
of
the
SLA
<SLA
ID>
was
detected
but
not
published
neither
escalated
because
the
Evaluation
Period
start
time
<eval
start
time>
was
previous
to
the
time
the
SLA
was
submitted
<SLA
submit
time>.
This
function
is
performing
as
designed.
Refer
to
Managing
Service
Level
Agreements
for
an
explanation
and
example
of
this
occurrence,
and
for
related
information
on
submitting
SLAs
and
performing
evaluations.
Problems
with
Message
Content
If
you
choose
to
use
as
the
notification
method
for
IBM
Tivoli
Service
Level
Advisor
event
escalation
and
notification,
you
should
test
to
determine
if
the
substitution
variables
included
in
the
message
text
are
working
correctly.
This
is
particularly
important
in
environments
using
languages
other
than
English.
The
procedures
below
are
performed
by
using
the
IBM
Tivoli
Service
Level
Advisor
command
line
interface
(CLI)
commands.
Substitution
Variable
Test
Procedure
To
test
the
substitution
variables
in
notification
messages,
do
the
following:
1.
Determine
if
notification
is
enabled
and
if
the
recipients
and
SMTP
server
have
been
defined
by
using
the
following
command:
scmd
escalate
view
If
is
not
enabled,
or
the
recipients
and
SMTP
server
have
not
been
defined,
use
the
following
command
to
provide
this
information:
scmd
escalate
enable
-to
addresses>
[-cc
addresses>]
-smtp
<SMTP
server>
Example:
scmd
escalate
enable
-to
-smtp
mailserver.mycompany.com
2.
Test
the
mechanism
by
issuing
the
following
command:
scmd
escalate
test
This
will
send
the
following
four
sample
e-mails
to
the
address
defined
above:
v
SLO
violation
v
SLO
trend
v
SLO
trend
cancelled
v
Application
Problem3.
Verify
the
results
of
the
test
from
the
inbox
of
the
destination
user.
Examine
the
three
sample
types
that
have
substitution
variables
defined
in
them
(SLO
violation,
SLO
trend,
and
SLO
trend
cancelled).
A
substitution
variable
is
a
character
string
that
begins
with
a
dollar
sign
($).
When
working
correctly,
each
substitution
variable
should
be
replaced
by
sample
text.
If
any
of
the
sample
e-mails
still
contain
substitution
variables,
perform
the
corrective
procedure
below.
64
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Correcting
Substitution
Variable
Problems
To
correct
problems
that
may
arise
with
substitution
variables,
do
the
following:
1.
Determine
if
an
message
has
been
defined
for
each
type
of
message
(SLO
violation,
SLO
trend,
SLO
trend
cancelled,
and
Application
Problem)
by
using
the
following
command:
scmd
escalate
view
If
any
of
the
messages
display
as
all
blanks,
then
set
that
message
type
to
default
by
issuing
the
following
command
one
or
more
times,
where
<event_type>
is
set
to
violation,
trend,
or
cancelled:
scmd
escalate
customize
-event
<event_type>
-content
default
2.
Determine
the
available
substitution
variables
by
issuing
the
following
command:
scmd
escalate
help
Within
the
resulting
display,
the
allowable
substitution
variables
are
displayed
in
the
language
for
your
installation.
For
example,
the
English
language
variables
are:
$MetricName
$CustomerName
$CustomerOrderId
$ComponentName
$ServiceOfferingName
$RealmName
$ScheduleState
$TrendProjectedDetail
$ViolationDetail
Notes:
a.
If
the
displayed
results
of
the
command
are
different
than
the
list
above,
use
the
scmd
results.
These
substitution
variables
will
be
different
depending
on
the
language
being
used.
b.
$TrendProjectedDetail
may
only
be
used
in
SLO
trend
messages.
c.
$ViolationDetail
may
only
be
used
in
SLO
violation
messages.3.
Display
all
the
current
message
templates
that
may
contain
substitution
variables
(SLO
violation,
SLO
trend,
and
SLO
trend
cancelled)
by
using
the
following
command:
scmd
escalate
view
Examine
the
messages
displayed.
Identify
substitution
variables
in
the
that
are
not
correct
because
they
do
not
match
the
allowable
list
displayed
in
step
2.
For
each
type
of
message
that
needs
to
be
corrected
set
the
message
correctly,
with
the
correct
substitution
variables
by
using
the
customize
command.
While
doing
this,
you
may
further
customize
the
message
wording,
but
you
must
only
use
substitution
variables
from
the
allowable
list
displayed
in
step
2.
For
example,
for
violation
messages,
use
the
following
command:
scmd
escalate
customize
-event
violation
-content
<content>
Replace
<content>
with
the
message
that
you
want
to
see,
enclosed
in
double
quotes,
and
including
appropriate
substitution
variables.
Note:
To
display
the
syntax
of
the
command,
issue
command:
scmd
escalate
customize
help
4.
After
making
changes,
test
the
messages
again.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
65
Corrupted
Characters
in
Received
If
you
receive
notifications
and
notice
that
some
characters
appear
to
be
corrupted,
verify
that
your
system
is
configured
to
handle
the
UTF-8
character
set.
You
might
need
to
consult
your
system
administrator
for
assistance.
Tivoli
Enterprise
Console
Event
Server
Communication
Problems
If
there
are
problems
communicating
with
the
Tivoli
Enterprise
Console®
Server,
the
event
will
be
cached
and
retried
hourly
until
successfully
received
at
the
server.
You
can
use
the
scmd
escalate
flush
command
to
manually
send
the
cached
events
to
the
server.
See
the
Command
Reference
for
details.
Error
While
Forwarding
Tivoli
Enterprise
Console
Event
You
may
be
having
problems
forwarding
Tivoli
Enterprise
Console
events
to
the
Tivoli
Enterprise
Console
Server
if
you
receive
either
of
the
following
error
messages:
v
DYKSL1102E
Error
occurred
while
forwarding
the
Tivoli
Enterprise
Console
event
to
the
Tivoli
Enterprise
Console
Server.
This
message
means
that
IBM
Tivoli
Service
Level
Advisor
could
not
forward
a
Tivoli
Enterprise
Console
Event
to
the
Tivoli
Enterprise
Console
Server.
v
DYKSL1104E
Unable
to
send
the
event
to
The
Tivoli
Enterprise
Console
Server.
The
event
is
cached.
This
message
means
IBM
Tivoli
Service
Level
Advisor
could
not
forward
a
Tivoli
Enterprise
Console
Event
to
the
Tivoli
Enterprise
Console
Server,
and
the
Tivoli
Enterprise
Console
event
will
be
stored
locally.
It
will
retry
sending
the
event
on
an
hourly
basis.
One
of
several
things
might
be
causing
this
problem:
v
The
Tivoli
Enterprise
Console
Server
might
be
down
v
A
network
connection
may
not
exist
v
Your
escalation
may
not
be
configured
correctly
v
The
SLM.baroc
may
not
be
properly
imported
in
the
Tivoli
Enterprise
Console
Server.
To
further
diagnose
and
resolve
this
problem,
try
the
following:
1.
Test
your
Tivoli
Enterprise
Console
escalation
configuration
with
the
CLI
command
scmd
escalate
test.
If
you
receive
the
DYKSL1102E
error
proceed
to
step
2.
Otherwise,
proceed
to
step
4.
2.
Verify
your
Tivoli
Enterprise
ConsoleC
Server
is
running.
3.
If
the
Tivoli
Enterprise
Console
server
is
running,
verify
that
the
SLM.baroc
file
was
imported
successfully
into
the
Tivoli
Enterprise
Console
Server.
4.
Verify
your
escalation
configuration
by
doing
the
following:
a.
Use
the
scmd
escalate
view
command
to
verify
your
Tivoli
Enterprise
Console
server
is
configured
correctly.
b.
Use
the
Tivoli
Enterprise
Console
server
address
returned
from
step
2
to
ping
the
Tivoli
Enterprise
Console
server.
If
the
server
does
not
send
a
reply,
a
network
connection
cannot
currently
be
made.
Verify
the
server
name
is
correct.
If
it
is
correct,
the
server
cannot
be
reached
due
to
network
problems.
If
the
server
name
is
incorrect
use
the
scmd
escalate
enable
–tec
command
to
modify
the
Tivoli
Enterprise
Console
server
name.
66
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
c.
Verify
the
Tivoli
Enterprise
Console
port
returned
from
step
2
is
the
correct
port
your
Tivoli
Enterprise
Console
server
is
listening
on.
If
the
port
is
incorrect,
use
the
scmd
escalate
enable
–tec
command
to
modify
the
Tivoli
Enterprise
Console
port
number.5.
Once
the
Tivoli
Enterprise
Console
server
can
be
reached,
you
can
issue
the
scmd
escalate
checkCache
command
to
determine
if
any
Tivoli
Enterprise
Console
events
are
currently
stored
locally.
If
locally
stored
Tivoli
Enterprise
Console
events
exist,
the
SLM
Server
will
attempt
to
send
the
events
again
to
the
Tivoli
Enterprise
Console
server
on
an
hourly
basis.
To
attempt
sending
the
Tivoli
Enterprise
Console
events
immediately,
run
the
scmd
escalate
flush
command.
Verify
that
the
Tivoli
Enterprise
Console
events
were
flushed
by
using
the
scmd
escalate
checkCache
command.
If
no
results
are
returned,
the
retry
was
successful.
Related
Documentation:
See
the
Command
Reference
for
instructions
on
using
the
scmd
escalate.
See
also
Getting
Started,
chapter
5,
″Additional
Installation
Tasks.″
Resolving
Additional
Tivoli
Enterprise
Console
Event
Forwarding
Problems
in
Non-English
Locales
If,
after
examining
and
resolving
any
Tivoli
Enterprise
Console
Server
configuration
or
availability
problems
(see
the
previous
topic,
“Error
While
Forwarding
Tivoli
Enterprise
Console
Event”
on
page
66),
you
continue
to
receive
error
messages
DYKSL1102E
and
DYKSL1002E
when
the
next
event
is
forwarded,
and
you
are
running
in
a
non-English
locale,
you
may
have
a
corrupted
Tivoli
Enterprise
Console
event
cache
file
and
will
need
to
apply
APAR
IY32860
to
recover.
To
correct
this
problem,
do
the
following
steps:
1.
Obtain
the
APAR
IY32860.
2.
Stop
the
SLM
Server:
v
For
Windows
systems,
from
a
command
prompt,
issue
the
command:
net
stop
tslm
v
For
UNIX
systems,
navigate
to
<SLM_Server_Install_Dir>/bin
and
run
the
following
script:
./slm_service_stop.sh
3.
Delete
the
corrupted
cache
file,
located
at
<SLM_Install_Dir>/tecCache/cache.
4.
Follow
the
instructions
in
the
APAR
to
copy
the
eif.jar
file
to
the
IBM
Tivoli
Service
Level
Advisor
jar
directory,
replacing
the
existing
file,
<SLM_Install_Dir>/jars/eif.jar.
5.
Restart
the
SLM
Server:
v
For
Windows
systems,
from
a
command
prompt,
issue
the
command:
net
start
tslm
v
For
UNIX
systems,
navigate
to
<SLM_Server_Install_Dir>/bin
and
run
the
following
script:
./slm_service_start.sh
Refer
to
Getting
Started
for
more
information
on
starting
the
SLM
Server.
SNMP
Trap
Notification
Problems
SNMP
traps
are
sent
using
the
connectionless
protocol,
UDP.
Thus
there
is
no
way
to
determine
if
a
trap
actually
makes
it
to
its
destination.
The
only
error
that
can
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
67
be
generated
is
if
the
SNMP
API
is
unable
to
open
a
socket
on
the
local
host,
otherwise
it
is
assumed
that
the
SNMP
trap
was
sent
successfully.
Test
the
CLI
to
verify
that
there
is
connectivity
between
IBM
Tivoli
Service
Level
Advisor
and
the
trap
daemon.
The
test
traps
are
not
stored
in
the
SLM
Database.
Information
in
the
SNMP
Event
is
not
Translated
The
trap
script
files
found
in
the
<TSLA_Base_Dir>/escalate/
directory
are
only
for
use
in
English
with
NetView®
systems.
The
scripts
are
provided
as
an
example
of
how
traps
that
are
sent
by
IBM
Tivoli
Service
Level
Advisor
can
be
formatted
for
reception
on
Netview
running
on
UNIX
or
Windows
systems.
If
the
system
on
which
you
are
receiving
trap
information
is
not
Netview
using
the
English
language,
then
you
must
customize
the
scripts
to
match
your
environment.
SNMP
Traps
Not
Sent
from
Linux
SLM
Server
If
you
have
a
Linux™
SLM
Server
sending
SNMP
traps
to
Netview
7.1
(English
version)
or
Netview
7.1.2
(Japanese
version),
trapd.exe
might
become
out
of
control
and
CPU
usage
might
climb
to
100%.
If
this
occurs,
SNMP
packets
from
the
Linux
SLM
Server
are
not
displayed
on
NetView
Event
Browser.
During
this
unstable
status,
NetView
is
unable
to
receive
SNMP
packets
from
SLM
Servers
on
other
platforms.
If
you
restart
the
NetView
service,
trapd.exe
returns
to
normal
and
can
receive
SNMP
packets
from
SLM
Servers
on
platforms
other
than
Linux.
But
if
NetView
receives
SNMP
packets
from
the
Linux
SLM
Server
again,
trapd.exe
again
becomes
out
of
control
and
fails
to
receive
SNMP
packets.
This
problem
has
not
been
seen
when
these
SNMP
traps
are
sent
to
Netview
7.1.3
(English),
or
if
the
SLM
Server
is
running
on
Windows
or
AIX
platforms.
You
should
examine
trace
and
log
files
to
look
for
any
unexpected
behavior
from
IBM
Tivoli
Service
Level
Advisor,
and
verify
that
SNMP
traps
are
being
properly
sent
by
the
SLM
Server.
If
the
problem
persists,
you
should
upgrade
your
Netview
installation
to
version
7.1.3.
Problems
Related
to
SLM
Reports
This
section
addresses
problems
you
might
encounter
while
working
with
SLM
Reports.
Sign-in
to
SLM
Reports
Unsuccessful
If
you
attempt
to
sign
in
to
SLM
Reports
by
opening
your
Web
browser
and
pointing
to
the
SLM
Reports
Console,
you
might
not
be
able
to
sign
in
successfully
if
you
have
session
cookies
disabled
in
your
Web
browser.
Note:
You
must
have
your
Web
browser
configured
to
enable
session
″cookies″
to
successfully
log
on
to
SLM
Reports.
To
verify
this,
do
the
following:
v
For
Netscape,
select
Edit
–>
Preferences...,
then
click
Advanced
and
verify
that
the
Disable
cookies
radio
button
is
not
selected.
v
For
Internet
Explorer,
select
Tools
–>
Internet
Options...,
then
select
the
Privacy
tab,
click
Advanced,
and
verify
that
cookies
are
not
blocked.
68
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
If
you
attempt
to
sign
on
to
SLM
Reports
with
a
user
name
and
password
but
the
sign
on
attempt
fails,
see
your
SLM
Administrator
to
establish
user
names
and
passwords
or
to
change
your
view
authorization.
If
you
are
using
a
directory
service
such
as
Lightweight
Directory
Access
Protocol
(LDAP)
which
ignores
case,
and
the
scmd
report
listUser
command
displays
users
with
uppercase
characters
in
their
names,
you
must
delete
them
using
the
scmd
report
deleteUser
CLI
command
and
recreate
them
in
all
lowercase
characters
using
the
scmd
report
addUser
CLI
command.
Error
Message
DYKRP0070E,
Page
Not
Found
Because
you
can
customize
which
report
page
is
displayed
for
each
user,
it
is
possible
that
a
user
might
be
directed
to
the
wrong
page
or
to
a
page
that
does
not
exist.
If
you
receive
message
DYKRP0070E,
you
should
report
this
error
to
your
SLM
Administrator.
After
receiving
this
error
your
session
will
remain
active,
but
it
will
be
unusable.
You
should
close
this
browser
window.
After
your
SLM
Administrator
corrects
the
problem,
you
can
open
another
browser
window
and
sign
on
again.
Your
SLM
Administrator
can
help
determine
which
report
page
your
user
name
is
directed
to
by
default
after
you
sign
on
to
the
SLM
Reports
Console.
You
can
view
which
report
page
your
user
name
is
directed
to
by
issuing
the
scmd
report
listUser
CLI
command
and
verifying
that
the
value
specified
for
the
-page
option
is
correct.
If
not,
your
SLM
Administrator
can
issue
the
scmd
report
changeUser
command
to
specify
the
correct
report
page.
See
the
Command
Reference
for
more
information
on
these
commands,
and
see
the
Administrator’s
Guide
for
more
information
about
creating
and
managing
user
names
for
accessing
SLM
reports.
Understanding
Trend
Lines
on
Graphs
On
graphical
displays,
a
linear
trend
line
is
displayed
to
reflect
trends
that
are
projected
using
the
linear
trending
algorithm
provided
by
IBM
Tivoli
Service
Level
Advisor.
When
viewing
graphs
and
examining
this
trend
line,
keep
in
mind
the
following
behaviors
of
the
trend
line
as
it
is
displayed
on
the
graphs:
v
At
certain
times
of
the
analysis,
the
linear
trend
line
might
appear
to
discard
data
points,
as
shown
in
Figure
1
on
page
70.
Although
it
might
appear
that
the
trend
line
does
not
include
these
data
points,
all
data
is
taken
into
consideration
for
trend
analysis.
Due
to
factors
of
scale,
the
trend
lines
cannot
always
be
accurately
displayed
when
significant
changes
in
scale
of
the
data
points
are
shown.
This
is
similar
to
the
problem
of
displaying
the
actual
data
points
themselves,
in
trying
to
display
very
small
values
along
with
very
large
values
on
the
same
graph.
This
is
a
normal
function
of
producing
these
graphical
displays.
The
trend
analyzer
is
using
all
of
the
data
points
for
trend
analysis,
and
is
functioning
properly.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
69
v
At
other
times
of
analysis
the
linear
trend
line
appears
to
represent
all
of
the
data
points
on
the
graph.
After
an
evaluation,
the
trend
line
is
drawn
against
only
the
latest
datapoint,
when
there
is
a
set
of
data
points
on
the
graph.
This
results
from
the
trend
analysis
system
correcting
itself,
as
it
has
determined
that
the
current
actual
data
point
value
has
proven
the
previous
trend
line
to
be
inaccurate.
Because
there
is
evidence
to
support
the
inaccuracy,
the
trend
analysis
system
will
no
longer
take
advantage
of
the
historical
datapoints,
and
it
begins
its
analysis
again
based
on
the
new
data
point.
The
trend
line
displayed
on
the
graph
only
shows
one
data
point,
signifying
that
the
trend
analysis
system
is
beginning
with
a
new
set
of
data.
This
is
a
proper
function
of
the
trend
line
analysis
function.
Graph
Not
Displayed
on
UNIX
If
you
click
on
the
results
link
to
display
a
graph
in
SLM
Reports,
and
no
graph
is
displayed,
or
if
you
do
not
see
the
business
level
summary
charts
displayed
at
the
top
of
your
high
level
reports,
you
might
need
to
change
your
DISPLAY
environment
settings
if
your
WebSphere
Application
Server
is
on
a
UNIX
machine.
The
DISPLAY
environment
variable
must
be
set
to
specify
where
graphics
for
a
particular
machine
should
be
displayed.
You
can
check
for
the
DISPLAY
environment
variable
setting
by
issuing
the
following
command:
echo
$DISPLAY
This
command
should
return
the
host
name
information
for
the
target
machine
where
WebSphere
Application
Server
is
running,
such
as
tslaserver.raleigh.ibm.com:0.0.
After
configuring
the
DISPLAY
environment
variable,
you
should
verify
the
setting
to
make
sure
the
variable
points
to
a
valid
location.
You
might,
for
example,
start
xclock
and
verify
that
it
displays
correctly
on
the
target
machine.
Be
sure
to
stop
WebSphere
Application
Server,
source
the
db2profile,
and
start
WebSphere
Application
Server
again.
Figure
1.
All
data
points
are
considered
in
trend
line
calculations,
even
if
the
resulting
display
does
not
appear
so.
70
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Fonts
on
Graphs
Not
Properly
Displayed
On
all
UNIX
environments,
if
you
log
into
a
UTF-8
environment
and
start
IBM
WebSphere
Application
Server,
the
fonts
on
the
graphs
in
SLM
Reports
should
be
properly
displayed.
On
other
platforms,
if
fonts
are
not
properly
displayed,
you
might
need
to
install
the
IBM
Times
New
Roman
worldtype
TrueType
font.
See
the
section
titled,
″Viewing
SLM
Reports
in
Double
Byte
Character
Languages″
in
Getting
Started
for
more
information
on
installing
the
Worldtype
font.
No
Results
in
Reports
when
Performing
Hourly
Evaluations
If
you
enabled
IBM
Tivoli
Service
Level
Advisor
to
perform
evaluations
more
often
than
once
per
day,
using
the
optional
hourly
evaluation
frequency
settings
during
offering
creation
(see
Managing
SLAs
for
more
information),
but
you
are
not
seeing
hourly
results
in
your
reports,
verify
the
following:
v
You
must
have
at
least
one
source
application
that
is
writing
data
to
Tivoli
Data
Warehouse
more
than
once
per
day.
Most
ETLs
are
configured
to
write
data
only
once
per
day,
or
combine
multiple
data
points
into
a
single
data
point
that
is
written
daily
to
Tivoli
Data
Warehouse.
Consult
with
your
source
application
administrators
to
verify
that
the
source
application
and
the
associated
ETL
is
properly
configured
and
scheduled
to
write
measurement
data
at
the
desired
frequency.
v
The
Registration
and
Process
ETLs
for
IBM
Tivoli
Service
Level
Advisor
must
also
be
scheduled
to
obtain
data
from
Tivoli
Data
Warehouse
on
the
desired
hourly
frequency,
to
perform
evaluations
when
planned.
Care
must
be
taken
to
allow
enough
time
for
all
data
to
be
processed
between
intervals
before
the
ETL
runs
again.
v
The
schedule
relationship
between
the
source
and
target
ETLs
must
also
be
carefully
coordinated
to
be
sure
that
all
data
is
written
to
Tivoli
Data
Warehouse
by
the
source
ETLs
before
the
Registration
and
Process
target
ETLs
are
run.
Handling
Data
Points
That
Are
Not
Valid
If
you
are
receiving
many
messages
that
indicate
invalidated
data
points,
such
as
negative
or
null
values,
it
is
likely
that
the
source
ETL
that
is
putting
this
data
into
Tivoli
Data
Warehouse
has
not
been
written
to
consider
the
valid
data
that
IBM
Tivoli
Service
Level
Advisor
metric
evaluators
support.
If
you
write
a
custom
ETL
and
followthe
Tivoli
Data
Warehouse
enablement
rules
for
creating
data
points,
you
can
still
create
data
points
that
are
not
supported
by
IBM
Tivoli
Service
Level
Advisor
and
are
considered
to
be
not
valid.
Refer
to
the
Appendix
titled,
″Validating
Data
Points
Using
Metric
Evaluators″
in
Managing
Service
Level
Agreements
that
identifies
the
metric
evaluators
used
by
IBM
Tivoli
Service
Level
Advisor
and
defines
how
data
is
considered
to
be
valid
or
not
valid.
Consult
your
source
application
administrator
and
ETL
developer
to
resolve
any
issues
with
unsupported
data.
SLM
Reports
Not
Displayed
in
the
Correct
Time
Zone
When
a
reports
user
is
defined
and
a
time
zone
is
specified
that
is
not
available
on
the
SLM
Reports
server,
the
dates
that
are
displayed
in
reports
for
that
user
are
in
GMT
time
instead
of
the
requested
time
zone.
In
addition,
at
the
top
of
the
reports
window
the
requested
time
zone
key
is
displayed
instead
of
the
time
zone
name.
For
example,
Timezone:
America/New_York
is
displayed
(note
the
underscore
character
(_)
is
included
in
the
time
zone
key)
instead
of
Timezone:
America/New
York.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
71
To
correct
this
problem,
complete
the
following
steps:
1.
Signoff
the
reports
user.
2.
Determine
the
time
zone
names
that
are
available
on
the
SLM
Reports
server
by
opening
a
Web
browser
and
navigating
to
the
following
Web
site,
where
<report_server>
is
the
fully
qualified
machine
name
where
SLM
Reports
is
installed,
and
<port>
is
the
HTTP
port
number
used
by
WebSphere
Application
Server:
http://<report_server>:<port>/SLMReport/timezone.jsp
3.
Issue
the
following
command
to
display
time
zones
available
on
the
SLM
Server:
scmd
report
displayTimezones
This
command
is
described
in
the
Command
Reference.
4.
Use
the
scmd
report
changeUser
command
to
specify
the
time
zone
for
the
reports
user
<name>
using
the
time
zone
index
number
(n)
for
a
time
zone
that
is
available
on
the
SLM
Reports
server:
scmd
report
changeUser
-name
<name>
-timezone
n
For
this
user,
the
specified
time
zone
name
should
be
displayed
at
the
top
of
reports
Web
pages,
and
dates
should
be
correctly
displayed
in
that
time
zone.
Problems
Related
to
Backup
and
Restore
This
section
addresses
problems
you
might
encounter
while
performing
backup
and
restore
operations.
No
Backup
in
UNIX
Destination
Directory
If
you
are
performing
a
backup
to
a
destination
directory
on
a
UNIX
machine,
and
it
appears
that
the
backup
completed
successfully
but
your
destination
directory
is
empty,
verify
that
the
directory
is
write-enabled
to
allow
data
to
be
written
to
the
directory.
If
necessary,
issue
the
following
command:
chmod
777
<directory>
Receiving
SQL1116N
When
Attempting
to
Connect
to
SLM
Databases
This
error
indicates
that
your
database
is
in
backup
pending
state
and
requires
a
backup
to
be
taken
before
any
applications
may
connect
to
the
database.
The
SLM
database
is
in
this
state
because
a
major
configuration
change
or
event
has
occurred
to
the
database,
such
as
enabling
roll-forward
logging.
To
backup
the
database,
follow
the
procedures
outlined
in
the
Administrator’s
Guide
for
backing
up
the
SLM
Database.
Note:
Before
backing
up
any
databases,
consult
with
your
database
administrator.
Incorrectly
backing
up
the
database
could
leave
your
environment
in
an
undesirable
state.
For
more
information
on
DB2
backup
procedures,
consult
see
the
IBM
DB2
Universal
Database
Data
Recovery
and
High
Availability
Guide
and
Reference,
Version
7.
Receiving
SQL1117N
When
Attempting
to
Connect
to
SLM
Databases
This
error
indicates
that
your
database
is
in
a
roll
forward
pending
state
and
requires
the
database
be
rolled
forward
before
any
applications
can
connect
to
the
database.
The
SLM
Database
is
in
this
state
because
either
a
recover
database
command
was
72
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
issued
or
a
major
database
system
event
has
occurred
where
the
DB2
system
put
the
database
into
a
roll
forward
pending
state.
Note:
Rolling
forward
a
database
could
leave
the
SLM
database
in
an
undesirable
state
and
should
only
be
performed
by
a
database
administrator.
For
more
information
on
rolling
forward
a
database,
refer
to
IBM
DB2
Universal
Database
Data
Recovery
and
High
Availability
Guide
and
Reference,
Version
7.
Configuring
the
CLI
Service
and
Utilities
There
are
several
administrative
tasks
that
you
can
perform
to
configure
IBM
Tivoli
Service
Level
Advisor
CLIs
and
utilities
that
are
executed
outside
of
the
CLI
Service.
Support
for
the
CLI
Service
includes
the
ability
to
reset
the
CLI
password
and
modifying
the
port
on
which
the
CLIs
listen.
Support
for
remote
communication
includes
updating
the
communication
port
on
the
IBM
Tivoli
Service
Level
Advisor
server
and
updating
the
same
port
and
the
IBM
Tivoli
Service
Level
Advisor
hostname
in
the
SLM
Administration
Server.
Before
running
an
scmd
or
utility
command,
run
the
slmenv
command
to
initialize
the
command
environment.
See
the
Command
Reference
for
details
on
the
use
of
slmenv.
Resetting
the
CLI
Service
Password
If
the
password
for
accessing
the
CLI
service
has
been
corrupted
or
forgotten
or
is
otherwise
unknown,
you
can
reset
it
to
a
known
value
using
the
cliutil.bat
command
(or
cliutil
script
on
UNIX
systems)
located
in
the
<Install_Dir>\bin
directory
(where
<Install_Dir>
is
the
directory
in
which
IBM
Tivoli
Service
Level
Advisor
was
installed).
Issue
the
following
command
to
reset
the
password:
cliutil
resetpassword
This
command
resets
the
password
to
the
value:
password.
You
should
then
use
the
normal
CLI
command
scmd
setPassword
to
change
the
password
to
a
less
trivial
value.
See
the
Command
Reference
for
details
on
changing
the
password
for
the
CLI
service.
Modifying
the
CLI
Port
You
can
also
use
the
cliutil.bat
command
(or
cliutil
script
on
UNIX
systems)
to
display
the
current
port
number
for
the
CLI
service
or
to
modify
it
to
a
new
port
number
in
case
of
port
conflicts.
To
display
the
current
port
number,
issue
the
following
command:
cliutil
getport
This
command
lists
the
current
port
for
the
CLI
service.
You
can
modify
the
CLI
service
port
by
issuing
the
following
command:
cliutil
setport
<port>
This
command
sets
the
current
port
to
the
value
specified
by
<port>.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
73
Updating
the
Communication
Port
Updating
the
communication
port
must
take
place
on
all
machines
where
the
SLM
Server,
SLM
Administration
Server,
and
SLM
Reports
are
installed,
or
communication
will
not
be
possible.
Updating
the
SLM
Server
Port
To
display
the
communication
port
on
the
IBM
Tivoli
Service
Level
Advisor
Server
machine,
issue
the
following
CLI
command:
scmd
rcc
getport
To
modify
the
communication
port
on
the
IBM
Tivoli
Service
Level
Advisor
Server
machine,
issue
the
following
command:
scmd
rcc
setport
<port>
This
command
sets
the
current
port
to
the
value
specified
by
<port>.
Updating
the
SLM
Administration
Server
Port
and
SLM
Reports
Port
To
modify
the
communication
port
on
the
SLM
Administration
Server
and
SLM
Reports
server
machines,
do
the
following:
1.
Start
a
command
prompt
and
execute
slmenv
to
setup
the
command
environment
2.
Navigate
to
<SLM_Install_Dir>/psbin,
where
<SLM_Install_Dir>
is
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed
3.
Issue
the
following
command,
where
<fully_qualified_hostname>
is
the
fully
qualified
hostname
of
the
SLM
Server
machine
and
<port>
is
the
desired
port
number:
rcomutil
<fully_qualified_hostname>
<port>
This
command
sets
the
current
port
to
the
value
specified
by
<port>.
Note:
If
the
SLM
Reports
and
SLM
Administration
Server
are
installed
on
different
machines,
the
command
must
be
executed
on
both
machines.
Problems
Related
to
Commands
and
Utilities
This
section
addresses
problems
you
might
encounter
while
executing
CLI
commands
and
utilities.
SBCS
Characters
Get
Corrupted
in
Command
Line
Note:
This
applies
to
the
following
languages:
French,
Italian,
German,
Spanish,
and
Brazilian
Portuguese.
When
you
issue
IBM
Tivoli
Service
Level
Advisor
commands
in
a
Windows
command
line
interface
(CLI)
for
the
French,
Italian,
German,
Spanish,
and
Brazilian
Portuguese
single-byte
character
sets
(SBCS),
some
characters
in
returned
messages
fail
to
display
properly.
To
display
the
characters
correctly
in
a
command
line
interface
for
those
languages,
do
the
following:
1.
Open
a
Windows
command
prompt
window.
74
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
2.
At
the
prompt,
enter
chcp
to
check
the
code
cpage
currently
used
by
the
SBCS
command
prompt
window.
3.
If
the
system
displays
the
message,
Active
code
page:
850,
enter
chcp
1252
to
change
the
code
page
to
1252.
4.
Right-click
the
window
title
bar
and
select
Properties
to
open
the
Command
Prompt
Properties
window.
5.
Select
the
Font
tab
and
set
the
font
to
Lucida
Console.
6.
Edit
the
slmenv.bat
file
located
in
the
root
installation
directory
of
IBM
Tivoli
Service
Level
Advisor
and
modify
the
line
REM
set
TSLA_CMD_ENC=###
by
removing
the
word
REM
and
replacing
###
with
the
codepage
obtained
in
step
2.
The
line
should
look
like
the
following
after
the
edits
have
been
performed:
set
TSLA_CMD_ENC=850
Note:
This
step
only
needs
to
be
performed
one
time
and
can
be
skipped
when
setting
up
subsequent
command
windows.
7.
In
this
same
command
prompt,
setup
the
command
line
environment
by
executing
the
slmenv.bat
command,
located
in
the
root
installation
directory
of
IBM
Tivoli
Service
Level
Advisor
8.
In
this
same
command
prompt
window,
enter
the
CLI
command
that
you
want
to
use.
The
characters
of
the
five
SBCSs
are
displayed
properly
in
the
IBM
Tivoli
Service
Level
Advisor
command
line
interface.
Chapter
3.
Troubleshooting
IBM
Tivoli
Service
Level
Advisor
75
76
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Appendix.
Notices
This
information
was
developed
for
products
and
services
offered
in
the
U.S.A.
IBM
may
not
offer
the
products,
services,
or
features
discussed
in
this
document
in
other
countries.
Consult
your
local
IBM
representative
for
information
on
the
products
and
services
currently
available
in
your
area.
Any
reference
to
an
IBM
product,
program,
or
service
is
not
intended
to
state
or
imply
that
only
that
IBM
product,
program,
or
service
may
be
used.
Any
functionally
equivalent
product,
program,
or
service
that
does
not
infringe
any
IBM
intellectual
property
right
may
be
used
instead.
However,
it
is
the
user’s
responsibility
to
evaluate
and
verify
the
operation
of
any
non-IBM
product,
program,
or
service.
IBM
may
have
patents
or
pending
patent
applications
covering
subject
matter
described
in
this
document.
The
furnishing
of
this
document
does
not
give
you
any
license
to
these
patents.You
can
send
license
inquiries,
in
writing,
to:
IBM
Director
of
Licensing
IBM
Corporation
North
Castle
Drive
Armonk,
NY
10504-1785
U.S.A.
For
license
inquiries
regarding
double-byte
(DBCS)
information,
contact
the
IBM
Intellectual
Property
Department
in
your
country
or
send
inquiries,
in
writing,
to:
IBM
World
Trade
Asia
Corporation
Licensing
2-31
Roppongi
3-chome,
Minato-ku
Tokyo
106,
Japan
The
following
paragraph
does
not
apply
to
the
United
Kingdom
or
any
other
country
where
such
provisions
are
inconsistent
with
local
law:
INTERNATIONAL
BUSINESS
MACHINES
CORPORATION
PROVIDES
THIS
PUBLICATION
″AS
IS″
WITHOUT
WARRANTY
OF
ANY
KIND,
EITHER
EXPRESS
OR
IMPLIED,
INCLUDING,
BUT
NOT
LIMITED
TO,
THE
IMPLIED
WARRANTIES
OF
NON-INFRINGEMENT,
MERCHANTABILITY
OR
FITNESS
FOR
A
PARTICULAR
PURPOSE.
Some
states
do
not
allow
disclaimer
of
express
or
implied
warranties
in
certain
transactions,
therefore,
this
statement
might
not
apply
to
you.
This
information
could
include
technical
inaccuracies
or
typographical
errors.
Changes
are
periodically
made
to
the
information
herein;
these
changes
will
be
incorporated
in
new
editions
of
the
publication.
IBM
may
make
improvements
and/or
changes
in
the
product(s)
and/or
the
program(s)
described
in
this
publication
at
any
time
without
notice.
Any
references
in
this
information
to
non-IBM
Web
sites
are
provided
for
convenience
only
and
do
not
in
any
manner
serve
as
an
endorsement
of
those
Web
sites.
The
materials
at
those
Web
sites
are
not
part
of
the
materials
for
this
IBM
product
and
use
of
those
Web
sites
is
at
your
own
risk.
©
Copyright
IBM
Corp.
2002,
2004
77
IBM
may
use
or
distribute
any
of
the
information
you
supply
in
any
way
it
believes
appropriate
without
incurring
any
obligation
to
you.
Licensees
of
this
program
who
wish
to
have
information
about
it
for
the
purpose
of
enabling:
(i)
the
exchange
of
information
between
independently
created
programs
and
other
programs
(including
this
one)
and
(I)
the
mutual
use
of
the
information
which
has
been
exchanged,
should
contact:
IBM
Corporation
2Z4A/101
11400
Burnet
Road
Austin,
TX
78758
U.S.A.
Such
information
may
be
available,
subject
to
appropriate
terms
and
conditions,
including
in
some
cases
payment
of
a
fee.
The
licensed
program
described
in
this
document
and
all
licensed
material
available
for
it
are
provided
by
IBM
under
terms
of
the
IBM
Customer
Agreement,
IBM
International
Program
License
Agreement
or
any
equivalent
agreement
between
us.
Any
performance
data
contained
herein
was
determined
in
a
controlled
environment.
Therefore,
the
results
obtained
in
other
operating
environments
may
vary
significantly.
Some
measurements
may
have
been
made
on
development-level
systems
and
there
is
no
guarantee
that
these
measurements
will
be
the
same
on
generally
available
systems.
Furthermore,
some
measurement
may
have
been
estimated
through
extrapolation.
Actual
results
may
vary.
Users
of
this
document
should
verify
the
applicable
data
for
their
specific
environment.
Information
concerning
non-IBM
products
was
obtained
from
the
suppliers
of
those
products,
their
published
announcements
or
other
publicly
available
sources.
IBM
has
not
tested
those
products
and
cannot
confirm
the
accuracy
of
performance,
compatibility
or
any
other
claims
related
to
non-IBM
products.
Questions
on
the
capabilities
of
non-IBM
products
should
be
addressed
to
the
suppliers
of
those
products.
All
statements
regarding
IBM’s
future
direction
or
intent
are
subject
to
change
or
withdrawal
without
notice,
and
represent
goals
and
objectives
only.
This
information
contains
examples
of
data
and
reports
used
in
daily
business
operations.
To
illustrate
them
as
completely
as
possible,
the
examples
include
the
names
of
individuals,
companies,
brands,
and
products.
All
of
these
names
are
fictitious
and
any
similarity
to
the
names
and
addresses
used
by
an
actual
business
enterprise
is
entirely
coincidental.
COPYRIGHT
LICENSE:
This
information
contains
sample
application
programs
in
source
language,
which
illustrate
programming
techniques
on
various
operating
platforms.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM,
for
the
purposes
of
developing,
using,
marketing
or
distributing
application
programs
conforming
to
the
application
programming
interface
for
the
operating
platform
for
which
the
sample
programs
are
written.
These
examples
have
not
been
thoroughly
tested
under
all
conditions.
IBM,
therefore,
cannot
guarantee
or
imply
reliability,
serviceability,
or
function
of
these
programs.
78
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Trademarks
IBM,
the
IBM
logo,
Lotus,
Rational,
Tivoli,
the
Tivoli
logo,
WebSphere,
AIX,
DB2,
DB2
Universal
Database,
eServer,
iSeries,
NetView,
Passport
Advantage,
pSeries,
Redbooks,
Tivoli
Enterprise,
Tivoli
Enterprise
Console,
and
z/OS
are
trademarks
or
registered
trademarks
of
International
Business
Machines
Corporation
in
the
United
States,
other
countries,
or
both.
Microsoft,
Windows,
Windows
NT,
and
the
Windows
logo
are
registered
trademarks
of
Microsoft
Corporation
in
the
United
States,
other
countries,
or
both.
UNIX
is
a
registered
trademark
of
The
Open
Group
in
the
United
States
and
other
countries.
Java
and
all
Java-based
trademarks
and
logos
are
trademarks
or
registered
trademarks
of
Sun
Microsystems,
Inc.
in
the
United
States,
other
countries,
or
both.
Linux
is
a
trademark
of
Linus
Torvalds
in
the
United
States,
other
countries,
or
both.
Other
company,
product,
or
service
names
may
be
trademarks
or
service
marks
of
others.
Appendix.
Notices
79
80
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
Index
Special
characters%Program
Files%
2
Aaudit
logging
1,
17
CCDWIC0024E
Could
not
execute/locate
DB2
command
26
CLI
Service,configuring
73
CLI
utilities
73
configuringlog
files
3
trace
filtering
masks
16
DDB2
v
troubleshooting
19
dyk_message
file
11
DYKRP0070E
69
Eetl
troubleshooting
install
26
FFFDC
1
first
fail
data
capture
1
IIBM
DB2
v
IBM
Tivoli
Service
Level
Advisortroubleshooting
install
23
IBM
WebSphere
v
JJava
Server
Pages
v
JDBC
leveltroubleshooting
20
JSP
files
v
Llog
additional
files
10
audit
1,
17
file
names
and
locations
5
file,
configuring
3
file,
SLM
Reports
4
file,
SLM
server
3
log
(continued)filter
2
first
fail
data
capture
(FFDC)
1
handler
2
message
and
trace
1
message
format,
understanding
11
message,viewing
8
trace
13
viewing
10
log
files,
accessing
2
loggers,
available
trace
14
Mmessage
Tivoli
Message
Standard
12
viewing
in
HTML
11
viewing,Task
Assistant
11
message
log
format
11
message
logs,
viewing
8
OODBC
data
sourcestroubleshooting
25
ODBC
datasourceverifying
creation
25
Ppage
not
found
69
Rreports
page
not
found
69
SSLM
databasetroubleshooting
21
SLM
Reportsconfiguring
log
file
4
enabling
tracing
15
troubleshooting
24,
28
SLM
Serverconfiguring
log
file
3
enabling
tracing
13
startuptroubleshooting
27
TTask
Assistantusing
for
Web
Services
11
viewing
messages
11
Tivoli
common
directorytroubleshooting
logs
not
accessible
56
Tivoli
Common
Directory
2
Tivoli
Message
Standard
12
traceenabling
for
SLM
Reports
15
enabling
for
SLM
Server
13
filtering
masks,
configuring
16
log
format,
understanding
15
trace
logging
13
tracingturning
off
14,
15
troubleshooting
19
backup
and
restore
72
blank
install
window
23
cleanup
temporary
ISMP
directories
24
CLI
Service
commands
33
common
logs
not
accessible
56
connecting
to
SLM
Databases
24
data
retrieval
46
data
warehouse
center
26
database
creation
scripts
21
databases
37
databases,
on
z/OS
and
OS/390
systems
43
DB2
data
warehouse
center
44
DYKAL3003E
message
29
etl
install
and
configuration
26
etl
installation
26
ETLs
54
event
escalation
63
find/replace
resource
57
fully
qualified
host
name
27
HTTP
500
error
29
IBM
Console
56
IIS
Service,
SLM
Reports
24
incomplete
text
23
install
screen
fonts
unreadable
23
installing
DB2
19
installing
IBM
Tivoli
Service
Level
Advisor
23
instance
creation
19
Java
memory,
out
of
57
logs,
common
56
memory,
Java
out
of
57
ODBC
data
sources
25
offerings
and
orders
59
renaming
a
resource
57
resource
name
change
57
resource,
none
displayed
in
create
offering
window
59
server
host
name
27
SLM
Database
connection
27
SLM
database
creation
21
SLM
Reports
24,
28,
68
SLM
Server
57
SLM
Server
startup
27
system
startup
27
uninstalling
30
UNIX
DB2
install
19
updating
JDBC
level
20
tslmerr.txt
1
©
Copyright
IBM
Corp.
2002,
2004
81
tslmout.txt
1
Uuninstalling
troubleshooting
30
Vviewing
product
logs
10
WWebSphere
v
82
IBM
Tivoli
Service
Level
Advisor:
Troubleshooting
