154
IBM Tivoli Service Level Advisor Managing Service Level Agreements Version 2.1 SC32-1247-00
IBM
Tivoli
Service
Level
Advisor
Managing
Service
Level
Agreements
Version
2.1
SC32-1247-00
���
IBM
Tivoli
Service
Level
Advisor
Managing
Service
Level
Agreements
Version
2.1
SC32-1247-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
.
.
.
.
.
.
.
.
.
.
.
.
.
. vi
IBM
Tivoli
Service
Level
Advisor
library
.
.
.
. vi
IBM
DB2
Universal
Database
Enterprise
Edition
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
Tivoli
Data
Warehouse
library
.
.
.
.
.
.
. vii
Warehouse
Packs
.
.
.
.
.
.
.
.
.
.
. viii
IBM
WebSphere
Application
Server
library
.
. viii
SLM
Administrative
Console
Information
.
.
. viii
Related
publications
.
.
.
.
.
.
.
.
.
. viii
Accessing
Publications
Online
.
.
.
.
.
.
.
. viii
Ordering
publications
.
.
.
.
.
.
.
.
.
.
. ix
Accessibility
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Tivoli
technical
training
.
.
.
.
.
.
.
.
.
. ix
Contacting
IBM
Software
Support
.
.
.
.
.
.
. ix
Determine
the
business
impact
of
your
problem
. x
Describe
your
problem
and
gather
background
information
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Submit
your
problem
to
IBM
Software
Support
.
. x
Searching
knowledge
bases
.
.
.
.
.
.
.
. xi
Obtaining
fixes
.
.
.
.
.
.
.
.
.
.
.
. xi
Updating
support
information
.
.
.
.
.
.
. xii
Participating
in
newsgroups
.
.
.
.
.
.
.
. xiii
Conventions
used
in
this
guide
.
.
.
.
.
.
. xiii
Typeface
conventions
.
.
.
.
.
.
.
.
.
. xiv
Operating
system-dependent
variables
and
paths
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Chapter
1.
Introduction
.
.
.
.
.
.
.
. 1
The
Service
Level
Management
Environment
.
.
. 1
Managing
Levels
of
Service
.
.
.
.
.
.
.
. 2
Event
Notification
.
.
.
.
.
.
.
.
.
.
. 3
Reporting
Evaluation
and
Analysis
Results
.
.
. 3
Starting
the
SLM
Administrative
Console
.
.
.
.
. 4
Layout
of
the
SLM
Administrative
Console
.
.
.
. 5
Accessibility
Features
of
the
SLM
Administrative
Console
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Chapter
2.
Overview
of
the
SLA
Process
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11
The
SLA
Process
Flow
.
.
.
.
.
.
.
.
.
.
. 11
Step
1.
Enabling
Source
Application
Data
.
.
.
. 12
Step
2.
Obtaining
Measurement
and
Resource
Type
Information
.
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Step
3.
Creating
Offerings
.
.
.
.
.
.
.
.
. 13
Step
4.
Creating
Service
Level
Agreements
.
.
.
. 15
Step
5.
Getting
Measurement
Data
for
Evaluation
. 16
Step
6.
Evaluating
Data
for
Violations
and
Trends
17
Step
7.
Notification
of
Service
Level
Violations
and
Trends
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Step
8.
Accessing
Web-Based
SLA
Reports
.
.
.
. 17
Chapter
3.
Creating
and
Managing
Schedules
.
.
.
.
.
.
.
.
.
.
.
.
. 19
Rules
for
Business
and
Auxiliary
Schedules
.
.
.
. 20
Creating
Auxiliary
Schedules
.
.
.
.
.
.
.
. 20
Creating
Business
Schedules
.
.
.
.
.
.
.
.
. 22
Creating
Periods
.
.
.
.
.
.
.
.
.
.
.
.
. 23
Defining
Schedule
States
.
.
.
.
.
.
.
.
. 26
Specifying
Time
Zones
.
.
.
.
.
.
.
.
.
. 27
Defining
Period
Frequency
.
.
.
.
.
.
.
. 29
Managing
Overlapping
Periods
.
.
.
.
.
.
. 29
Customizing
Schedule
Preferences
.
.
.
.
.
.
. 31
Changing
Schedule
State
Names
.
.
.
.
.
. 31
Customizing
Your
Fiscal
Quarter
and
Year
.
.
. 32
Defining
Compatible
Schedules
.
.
.
.
.
.
.
. 34
Adding
a
Period
for
a
Single
Future
Date
.
.
.
. 34
Managing
Schedules
.
.
.
.
.
.
.
.
.
.
. 35
Chapter
4.
Creating
and
Managing
Offerings
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
Creating
Offerings
.
.
.
.
.
.
.
.
.
.
.
. 38
Selecting
the
SLA
Type
.
.
.
.
.
.
.
.
. 39
Adding
Offering
Components
.
.
.
.
.
.
. 41
Configuring
Service
Level
Objectives
.
.
.
.
. 43
Publishing
the
Offering
.
.
.
.
.
.
.
.
. 50
Managing
Offerings
.
.
.
.
.
.
.
.
.
.
. 51
Chapter
5.
Creating
and
Managing
Realms
.
.
.
.
.
.
.
.
.
.
.
.
.
. 53
Creating
Realms
.
.
.
.
.
.
.
.
.
.
.
.
. 53
Managing
Realms
.
.
.
.
.
.
.
.
.
.
.
. 54
Chapter
6.
Creating
and
Managing
Customers
.
.
.
.
.
.
.
.
.
.
.
.
. 55
Creating
Customers
.
.
.
.
.
.
.
.
.
.
. 55
Managing
Customers
.
.
.
.
.
.
.
.
.
.
. 56
Chapter
7.
Creating
and
Managing
SLAs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 57
Creating
SLAs
.
.
.
.
.
.
.
.
.
.
.
.
. 58
Submitting
the
SLA
.
.
.
.
.
.
.
.
.
.
. 60
Managing
SLAs
.
.
.
.
.
.
.
.
.
.
.
.
. 61
SLA
States
.
.
.
.
.
.
.
.
.
.
.
.
.
. 61
Deployment
States
.
.
.
.
.
.
.
.
.
.
. 62
Viewing
SLA
Details
.
.
.
.
.
.
.
.
.
. 63
Changing
SLAs
.
.
.
.
.
.
.
.
.
.
.
. 63
Canceling
an
SLA
.
.
.
.
.
.
.
.
.
.
. 64
Resubmitting
an
SLA
.
.
.
.
.
.
.
.
.
. 64
Deleting
an
SLA
.
.
.
.
.
.
.
.
.
.
.
. 64
Adding
Remarks
to
an
SLA
.
.
.
.
.
.
.
. 64
Replacing
a
Resource
.
.
.
.
.
.
.
.
.
.
. 65
Replacing
an
Offering
.
.
.
.
.
.
.
.
.
.
. 65
Managing
Violations
.
.
.
.
.
.
.
.
.
.
. 66
©
Copyright
IBM
Corp.
2002,
2004
iii
Chapter
8.
Evaluations
and
Trend
Analysis
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
Introducing
Metric
Evaluators
.
.
.
.
.
.
.
. 68
Retrying
an
Evaluation
.
.
.
.
.
.
.
.
.
. 68
Analyzing
Trends
.
.
.
.
.
.
.
.
.
.
.
. 69
Caution
Regarding
Trend
Tracking
Information
72
Evaluating
Historical
Data
.
.
.
.
.
.
.
.
. 72
Adjudicating
Evaluation
Results
.
.
.
.
.
.
. 73
Performing
Reevaluations
.
.
.
.
.
.
.
.
. 73
Unique
Evaluation
Examples
.
.
.
.
.
.
.
. 74
Receiving
more
violations
and
results
than
expected
.
.
.
.
.
.
.
.
.
.
.
.
.
. 74
Mixing
of
daily
and
hourly
evaluation
intervals
74
Trending
an
Imminent
Violation
.
.
.
.
.
. 75
Chapter
9.
Event
Escalation
and
Notification
.
.
.
.
.
.
.
.
.
.
.
.
. 77
Event
Notification
.
.
.
.
.
.
.
.
.
. 77
Including
HTML
Link
in
Event
Notification
.
.
.
.
.
.
.
.
.
.
.
.
. 78
Tivoli
Enterprise
Console
Event
Notification
.
.
. 79
SNMP
Trap
Event
Notification
.
.
.
.
.
.
.
. 79
Application
Event
Escalation
.
.
.
.
.
.
.
. 80
Escalating
Messages
.
.
.
.
.
.
.
.
.
.
. 80
Appendix
A.
Introducing
Metric
Evaluators
.
.
.
.
.
.
.
.
.
.
.
.
. 81
Availability
.
.
.
.
.
.
.
.
.
.
.
.
.
. 81
Percent
of
Time
in
State
.
.
.
.
.
.
.
.
. 81
State
Transitions
.
.
.
.
.
.
.
.
.
.
.
. 82
Transaction
Availability
.
.
.
.
.
.
.
.
. 83
Performance
.
.
.
.
.
.
.
.
.
.
.
.
.
. 84
Weighted
Average
Performance
.
.
.
.
.
.
. 84
Total
Performance
.
.
.
.
.
.
.
.
.
.
. 85
Utilization
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 85
Incident
and
Change
Metrics
.
.
.
.
.
.
.
. 86
Counts
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 86
Percentages
.
.
.
.
.
.
.
.
.
.
.
.
. 87
Time
in
State
.
.
.
.
.
.
.
.
.
.
.
.
. 88
Time
to
State
.
.
.
.
.
.
.
.
.
.
.
.
. 88
Business
Schedule
Considerations
.
.
.
.
.
. 89
Appendix
B.
Validating
Data
Points
Using
Metric
Evaluators
.
.
.
.
.
.
. 91
Metric
Evaluator
Type
A
-
Min/Max/Avg
.
.
.
. 91
Metric
Evaluator
Type
A
-
Transaction
Success
.
.
. 92
Metric
Evaluator
Type
B
-
Total
.
.
.
.
.
.
.
. 93
Metric
Evaluator
Type
B1
and
B2
-
Problem
Management
.
.
.
.
.
.
.
.
.
.
.
.
.
. 93
Metric
Evaluator
Type
C
-
Availability
.
.
.
.
. 94
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
.
.
.
.
.
.
.
. 95
Modifying
Properties
to
Create
New
SLM
Objects
96
Modifying
Properties
for
Realms
.
.
.
.
.
. 97
Modifying
Properties
for
Customers
.
.
.
.
. 97
Modifying
Properties
for
Schedules
.
.
.
.
. 98
Modifying
Properties
for
Offerings
.
.
.
.
. 102
Modifying
Properties
for
SLAs
.
.
.
.
.
. 110
Example:
Creating
a
Realm
.
.
.
.
.
.
.
.
. 113
Example:
Creating
a
Customer
.
.
.
.
.
.
. 116
Appendix
D.
Sample
SLM
Object
Properties
Files
.
.
.
.
.
.
.
.
.
. 117
Sample
Properties
File
for
a
Realm
.
.
.
.
.
. 117
Sample
Properties
File
for
a
Customer
.
.
.
.
. 117
Sample
Properties
File
for
a
Schedule
.
.
.
.
. 118
Sample
Properties
File
for
an
Offering
.
.
.
.
. 121
Sample
Properties
File
for
an
SLA
.
.
.
.
.
. 125
Appendix
E.
Notices
.
.
.
.
.
.
.
. 129
Trademarks
.
.
.
.
.
.
.
.
.
.
.
.
.
. 131
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 133
iv
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Preface
Managing
Service
Level
Agreements
provides
information
on
the
tasks
required
to
create
and
manage
the
components
that
make
up
a
service
level
agreement
(SLA)
using
IBM®
Tivoli®
Service
Level
Advisor,
including
schedules,
offerings,
customers,
realms,
and
resources,
and
managing
violations
and
trends
toward
future
violations
that
are
reported
against
agreed
upon
levels
of
service.
This
document
assumes
that
IBM
Tivoli
Service
Level
Advisor
and
its
prerequisite
software
has
already
been
successfully
installed
and
configured
for
your
enterprise
environment,
and
that
your
enterprise
environment
currently
collects
and
measures
performance
and
availability
data
and
stores
that
data
using
Tivoli
Data
Warehouse.
For
more
information
on
the
installation
of
IBM
Tivoli
Service
Level
Advisor,
see
the
installation
document
titled,
Getting
Started.
Who
should
read
this
guide
This
document
is
written
for
administrators
and
designated
specialists
in
your
organization
whose
responsibilities
include
creating
and
managing
multiple
levels
of
service
offerings,
as
well
as
those
responsible
for
negotiating
and
establishing
service
level
agreements
for
customers
and
consumers
of
services
provided
by
your
enterprise
environment.
You
should
be
familiar
with
the
service
level
management
(SLM)
needs
of
your
organization,
as
well
as
the
the
business
objectives
associated
with
Tivoli’s
SLM
solution.
There
should
be
someone
in
your
organization
who
is
designated
as
an
SLM
Administrator.
This
role
is
responsible
for
configuring
and
maintaining
the
service
level
management
environment,
creating
and
maintaining
user
IDs
for
access
to
IBM
Tivoli
Service
Level
Advisor,
as
well
as
day
to
day
operations,
such
as
backup
and
restore
of
databases
and
the
software.
The
SLM
Administrator
also
works
with
a
database
administrator
to
make
sure
databases
are
created
and
configured
correctly,
and
that
data
transfers
are
scheduled
to
occur
on
a
regular
basis
to
write
the
collected
performance
and
availability
data
to
the
central
data
warehouse
database
component
of
Tivoli
Data
Warehouse.
You
might
need
to
consult
your
SLM
Administrator
for
assistance
in
the
following
areas:
v
Access
to
the
SLM
Administrative
Console,
the
Web
based
user
interface
where
you
create
and
manage
service
level
offerings
and
SLAs.
The
SLM
Administrator
must
create
user
IDs
and
passwords
for
you
to
have
access
to
the
various
tasks
available.
Your
designated
role
as
an
Offering
Specialist,
an
SLA
Specialist,
or
an
SLA
Adjudicator
is
assigned
certain
tasks
that
you
are
authorized
to
perform.
v
Problems
with
connecting
to
databases
in
your
enterprise
environment
v
Information
on
when
data
is
scheduled
to
be
transferred
into
Tivoli
Data
Warehouse
as
well
as
from
Tivoli
Data
Warehouse
and
into
the
local
databases
for
use
by
IBM
Tivoli
Service
Level
Advisor.
v
Operating
in
the
OS/390®
environment,
if
you
have
IBM
Tivoli
Service
Level
Advisor
databases
created
and
maintained
on
an
OS/390
platform
v
Knowledge
of
which
source
applications
are
available
in
your
enterprise
environment,
and
what
data
they
are
configured
to
collect
and
write
to
the
©
Copyright
IBM
Corp.
2002,
2004
v
central
data
warehouse.
This
information
affects
the
types
of
data
and
the
resources
for
which
you
can
develop
levels
of
service
and
SLAs.
v
Security
access
to
IBM
WebSphere®
Application
Server,
which
is
used
in
support
of
the
SLM
Administrative
Console
interface.
Your
SLM
Administrator
should
be
responsible
for
making
sure
the
server
is
installed,
configured,
and
started
for
use
with
IBM
Tivoli
Service
Level
Advisor.
In
general
this
document,
combined
with
the
online
user
assistance
provided
by
the
Task
Assistant
function
of
IBM
Tivoli
Service
Level
Advisor
as
part
of
the
SLM
Administrative
Console,
should
be
your
primary
resource
for
information
on
creating
and
managing
service
level
offerings
and
SLAs.
Other
documentation
available
in
the
library
is
described
below.
Publications
This
section
lists
publications
in
the
IBM
Tivoli
Service
Level
Advisor
library
and
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
on
Windows®
automatically
launches
the
Tivoli
Software
Information
Center,
enbling
you
to
select
any
of
the
available
documentation.
The
following
documents
are
available
in
the
IBM
Tivoli
Service
Level
Advisor
library:
v
A
short
″Read
Me
First″
document
that
provides
a
starting
point
to
help
you
become
oriented
with
the
set
of
IBM
and
Tivoli
products
that
support
Tivoli’s
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
to
enable
you
or
your
vi
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
customer
to
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
track
and
manage
service
level
agreements
(SLAs)
between
your
organization
and
customers
who
depend
on
your
enterprise
for
agreed
upon
levels
of
service.
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.
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
normal
operation
of
the
product.
Information
about
message
and
trace
logging
is
also
provided.
v
Online
user
assistance
for
IBM
Tivoli
Service
Level
Advisor
The
online
user
assistance
provides
integrated
online
help
topics
for
all
IBM
Tivoli
Service
Level
Advisor
administrative
tasks
that
are
performed
using
the
SLM
Administration
Console.
Online
user
assistance
is
displayed
in
the
Task
Assistant
portion
of
the
SLM
Administration
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
Administration
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®
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
Preface
vii
Warehouse
Packs
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
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
is
available
elsewhere
in
this
document.
User
assistance
for
the
SLM
Administrative
Console
is
available
as
part
of
its
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.
viii
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
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.
For
additional
information,
see
“Accessibility
Features
of
the
SLM
Administrative
Console”
on
page
8.
Tivoli
technical
training
For
Tivoli
technical
training
information,
refer
to
the
following
IBM
Tivoli
Education
Web
site:
http://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
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
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
IBM
Software
Support
Web
site
and
click
the
name
of
your
geographic
region:
http://techsupport.services.ibm.com/guides/contacts.html
v
For
IBM
eServer™
software
products
(including,
but
not
limited
to,
DB2
and
WebSphere
products
that
run
in
zSeries®,
pSeries®,
and
iSeries®
environments),
you
can
purchase
a
software
maintenance
agreement
by
working
directly
with
Preface
ix
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:
http://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
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:
http://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:
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.
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
is
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
x
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
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.”
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.
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
Preface
xi
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
check
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
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:
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.
Click
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.
xii
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
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.
To
access
a
newsgroup
use
the
following
instructions.
If
you
use
Mozilla
as
your
browser:
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:
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.
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
IBM
DB2
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.
Preface
xiii
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
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:
Managing
SLAs
Chapter
1.
Introduction
This
document
describes
how
you
can
use
IBM
Tivoli
Service
Level
Advisor
to
create
and
manage
service
level
agreements
(SLAs)
between
your
enterprise
and
the
customers
who
use
the
services
that
you
provide.
Your
customers
depend
on
the
performance
and
availability
of
the
services
provided
by
your
enterprise
for
the
success
of
their
own
organization.
With
IBM
Tivoli
Service
Level
Advisor,
you
can
more
quickly
and
efficiently
obtain
information
to
help
you
manage
network
and
application
services.
This
enables
you
to
maintain
productivity
and
customer
satisfaction,
minimize
revenue
impact,
manage
costs,
and
improve
planning
by
assuring
offered
services.You
can
also
create
and
manage
SLAs
within
your
enterprise
that
enable
you
to
monitor
internal
levels
of
service
that
are
critical
to
guaranteeing
the
service
levels
agreed
upon
with
your
customers.
You
use
the
SLM
Administrative
Console
user
interface
of
IBM
Tivoli
Service
Level
Advisor
to
define
the
levels
of
service
and
make
them
available
as
offerings.
These
offerings
are
then
selected
and
associated
with
your
defined
customers
and
managed
resources
to
create
SLAs.
After
the
completed
SLA
is
submitted
to
IBM
Tivoli
Service
Level
Advisor,
the
performance
and
availability
measurements
that
are
collected
for
the
associated
managed
resources
are
obtained
from
Tivoli
Data
Warehouse
according
to
a
predefined
schedule.
This
data
is
then
analyzed
and
evaluated
for
violations
and
trends
toward
future
violations
of
the
agreed
upon
levels
of
service.
Notifications
of
violations
and
trends
are
sent
automatically,
and
reports
of
the
results
can
be
generated
and
viewed
using
a
Web
browser.
The
Service
Level
Management
Environment
IBM
Tivoli
Service
Level
Advisor
is
installed
in
your
enterprise
environment
as
part
of
an
overall
service
level
management
solution.
You
should
already
have
in
place
one
or
more
Tivoli
products
that
measure
and
monitor
performance
and
availability
of
resources
in
your
enterprise,
and
these
applications
should
already
be
enabled
and
configured
to
write
this
performance
and
availability
data
to
a
central
data
warehouse
as
provided
with
Tivoli
Data
Warehouse
(see
your
SLM
Administrator
for
more
information,
or
refer
to
the
Getting
Started
document
for
information
on
installing
and
configuring
Tivoli
Data
Warehouse
and
other
prerequisite
software).
The
service
level
management
capabilities
of
IBM
Tivoli
Service
Level
Advisor
complement
the
performance
and
availability
measurement
functions
of
Tivoli
products
that
write
data
to
the
central
data
warehouse,
such
as
the
following
applications:
v
IBM
Tivoli
Monitoring
v
IBM
Tivoli
Monitoring
for
Transaction
Performance
v
IBM
Tivoli
Business
Systems
Manager
v
IBM
Tivoli
Enterprise
Console®
For
example,
IBM
Tivoli
Monitoring
for
Transaction
Performance
measures
the
response
time
of
a
Web
site,
breaking
a
service
into
associated
subapplications
that
complete
an
service
transaction.
This
response
time
data
is
collected
and
written
to
the
central
data
warehouse
on
a
regular
basis
as
scheduled
by
the
database
administrator,
and
IBM
Tivoli
Service
Level
Advisor
can
later
obtain
that
data
from
©
Copyright
IBM
Corp.
2002,
2004
1
the
central
data
warehouse
and
evaluate
it
for
conformance
to
the
service
level
agreement
that
is
established
for
the
acceptable
response
time
of
the
Web
site.
The
general
flow
of
monitor
data
from
source
applications
to
Tivoli
Data
Warehouse
and
then
on
to
IBM
Tivoli
Service
Level
Advisor
is
illustrated
in
Figure
1.
Figure
1
shows
how
multiple
source
applications
collect
and
store
their
data
in
their
local
databases,
which
are
then
written
to
the
Tivoli
Data
Warehouse
database.
This
takes
place
on
a
specific
time
interval,
for
example,
once
per
day
or
once
per
hour.
At
some
other
scheduled
time
interval,
data
of
interest
to
IBM
Tivoli
Service
Level
Advisor
is
sent
to
its
local
databases,
shown
in
Figure
1
as
the
SLM
Database
and
SLM
Measurement
Data
Mart
(see
Getting
Started
for
more
information
on
these
databases).
IBM
Tivoli
Service
Level
Advisor
evaluates
this
data
for
violations
and
trends
toward
violations
of
SLAs,
generates
reports
of
SLA
results,
and
sends
notifications
of
violations
or
trends
to
appropriate
support
personnel
or
supporting
applications.
Managing
Levels
of
Service
The
information
collected
by
performance
and
availability
monitoring
applications
is
used
by
IBM
Tivoli
Service
Level
Advisor
to
manage
against
SLAs
associated
with
your
enterprise
customer,
which
might
be
an
individual,
a
department,
or
a
division
in
your
organization.
Analysis
of
the
data
collected,
identification
of
trends
in
service
levels,
and
generated
reports
can
be
associated
with
a
specific
enterprise
customer.
You
can
manage
your
SLAs
by
completing
the
following
steps:
1.
Create
an
offering,
defining
the
service
level
objectives
(SLOs)
to
be
measured,
along
with
the
associated
schedules
used
to
determine
peak
hours,
standard
hours,
off
hours,
and
other
schedule
states.
See
Chapter
4,
“Creating
and
Managing
Offerings,”
on
page
37
for
more
information
about
this
step.
2.
Create
and
submit
a
service
level
agreement
(SLA),
that
specifies
the
customer
interested
in
the
SLA,
and
associate
that
customer
with
an
available
offering.
Figure
1.
IBM
Tivoli
Service
Level
Advisor
analyzes
performance
and
availability
data
from
multiple
source
applications
that
store
their
data
in
the
Tivoli
Data
Warehouse
database.
2
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Included
in
the
SLA
is
information
on
the
enterprise
resources
that
are
to
be
included
in
the
management
of
the
SLA.
Submitting
the
SLA
means
that
the
SLOs
in
the
offering
are
now
agreed
upon
by
the
offering
provider
and
by
the
customer.
This
agreement
is
the
SLA
that
is
analyzed
and
validated.
See
Chapter
7,
“Creating
and
Managing
SLAs,”
on
page
57
for
more
information
about
this
step.
Chapter
2,
“Overview
of
the
SLA
Process,”
on
page
11
provides
an
overview
of
the
process
for
creating
and
managing
your
SLAs.
Event
Notification
IBM
Tivoli
Service
Level
Advisor
automatically
creates
events
whenever
the
breach
values
for
the
specific
metrics
in
the
SLA
are
violated,
or
when
the
analysis
shows
a
trend
toward
a
violation.
IBM
Tivoli
Service
Level
Advisor
sends
an
SLA
event
to
the
appropriate
and
responsible
resources,
using
SNMP,
Tivoli
Enterprise
Console®
events,
or
as
the
notification
mechanism.
Event
notification
is
usually
configured
at
installation
time
(see
the
Getting
Started
document
for
details
on
configuring
for
event
notification),
but
can
be
configured
and
modified
at
any
time.
Consult
your
SLM
Administrator
or
refer
to
the
Administrator’s
Guide
and
Command
Reference
documents
for
related
information
about
configuring
for
event
notification.
Reporting
Evaluation
and
Analysis
Results
After
a
service
level
agreement
is
submitted,
IBM
Tivoli
Service
Level
Advisor
extracts
the
appropriate
data
from
the
central
data
warehouse
according
to
a
predetermined
schedule
and
evaluates
the
data
for
conformance
to
the
agreed
upon
levels
of
service
as
specified
in
the
SLA.
IBM
Tivoli
Service
Level
Advisor
analyzes
the
measurement
data
for
violations
or
trends
toward
future
violations,
and
stores
the
results
of
this
analysis
in
the
SLM
Database.
You
or
your
customers
can
view
Web-based
reports
of
this
evaluation
and
analysis
in
graphical
and
tabular
form.
These
reports
can
help
answer
the
following
questions:
v
What
level
of
service
is
being
achieved?
v
Are
the
agreements
being
met
or
violated?
v
Is
the
level
of
service
trending
toward
future
violations?
You
can
use
these
results
to
provide
executive
summaries,
aid
in
service
administration
and
planning,
help
manage
operations,
and
validate
service
levels
for
the
customer.
Web
reports
can
help
you
to
manage
costs,
justify
expenses,
improve
internal
customer
satisfaction,
and
provide
information
to
help
you
measure
the
business
impact
of
problems
with
your
IT
infrastructure
in
terms
of
revenue,
productivity,
and
contribution
to
the
success
of
your
business.
IBM
Tivoli
Service
Level
Advisor
can
deliver
a
report
on
any
monitored
service,
resource,
SLA,
or
customer,
and
display
it
in
your
Web
browser
for
you
to
view
or
print.
You
can
control
access
to
these
reports,
allowing
customers
to
only
view
reports
that
are
associated
with
their
particular
service
level
agreements.
You
can
also
provide
reports
at
different
levels
of
detail,
for
example,
high
level
summary
reports
to
executives,
or
more
detailed
reports
to
IT
operations
personnel
as
well
as
customers.
See
the
SLM
Reports
document
for
more
information
on
the
evaluation
and
reporting
functions
of
IBM
Tivoli
Service
Level
Advisor.
Chapter
1.
Introduction
3
Starting
the
SLM
Administrative
Console
The
SLM
Administrative
Console
is
the
user
interface
for
performing
tasks
with
IBM
Tivoli
Service
Level
Advisor.
It
is
a
role-based
interface,
presenting
and
authorizing
only
the
tasks
that
are
relevant
for
the
roles
to
which
your
user
ID
is
assigned.
The
SLM
Administrative
Console
provides
consistent
controls
and
behaviors
across
tasks,
and
includes
embedded
user
assistance.
You
can
bring
up
the
SLM
Administrative
Console
using
a
supported
Web
browser.
You
should
already
have
IBM
Tivoli
Service
Level
Advisor
installed
and
configured
in
your
enterprise
environment.
Before
starting
the
SLM
Administrative
Console,
you
might
need
to
verify
the
following
conditions:
v
IBM
WebSphere
Application
Server
is
started
on
the
machine
where
the
SLM
Administration
Server
component
of
IBM
Tivoli
Service
Level
Advisor
is
located.
See
the
Getting
Started
document
for
the
procedure
to
start
IBM
WebSphere
Application
Server,
if
needed.
You
might
need
to
ask
your
SLM
Administrator
for
the
fully
qualified
host
name
of
this
machine.
You
need
this
host
name
to
bring
up
the
SLM
Administrative
Console
in
your
Web
browser.
v
The
SLM
Server
component
of
IBM
Tivoli
Service
Level
Advisor
is
started
(note
that
the
SLM
Server
might
be
located
on
a
different
machine
than
the
SLM
Administration
Server).
See
Getting
Started
for
the
procedure
to
start
the
SLM
Server,
if
needed.
v
WebSphere
security
might
be
enabled,
and
if
so,
you
should
obtain
an
authorized
user
ID
and
password
created
by
your
SLM
Administrator
to
sign
on
to
the
SLM
Administrative
Console.
Do
not
use
passwords
with
double-byte
characters:
Some
systems
do
not
have
an
input
method
for
double-byte
character
sets,
and
most
Web
browsers
do
not
allow
the
direct
entry
of
double-byte
characters
in
password
fields.
To
start
the
SLM
Administrative
Console,
do
the
following
steps:
1.
Open
your
Web
browser
and
navigate
to
the
following
location:
http://<Fully_Qualified_SLM_Administration_Server_host_name>:<Port>/SLMAdmin
where
Fully_Qualified_SLM_Administration_Server_host_name
is
the
fully
qualified
host
name
of
the
machine
on
which
the
SLM
Administration
Server
is
installed,
for
example,
myMachine.raleigh.ibm.com
Port
is
the
port
number
(the
default
is
80.
You
might
need
to
ask
your
SLM
Administrator
if
a
different
port
number
is
configured.)This
location
should
be
specified
similar
to
the
following
example:
http://myMachine.raleigh.ibm.com:80/SLMAdmin
2.
If
WebSphere
security
is
enabled,
a
sign
on
screen
is
displayed,
prompting
you
for
your
user
ID
and
password.
Sign
on
using
your
assigned
user
ID
and
password
provided
by
your
SLM
Administrator.
If
WebSphere
security
is
not
enabled,
the
sign
on
screen
is
not
presented,
and
you
are
automatically
signed
on
as
the
default
SLM
Administrator
user
name
that
was
specified
at
installation
time,
with
authorization
to
perform
tasks
as
an
SLM
Administrator.
If
your
user
ID
and
password
are
accepted,
the
SLM
Administrative
Console
is
displayed.
After
viewing
the
Welcome
page,
you
can
select
a
task
in
the
portfolio,
which
opens
a
task
page
similar
to
the
Create
Offerings
example
in
Figure
2
on
page
5.
4
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
From
the
SLM
Administration
Console
you
can
perform
tasks
such
as
creating
and
managing
schedules,
offerings,
realms,
customers,
and
SLAs,
managing
violations,
and
replacing
resources
and
offerings,
depending
on
the
role
authority
granted
to
your
user
name.
Layout
of
the
SLM
Administrative
Console
The
SLM
Administrative
Console
is
displayed
as
a
Web
page
in
your
browser,
and
consists
of
four
main
areas,
as
illustrated
in
Figure
2.:
v
The
portfolio,
along
the
left
side
of
the
window,
that
shows
the
tasks
that
you
are
authorized
to
perform
according
to
your
assigned
role.
The
portfolio
area
is
titled
My
Work,
and
can
be
closed
or
opened
to
provide
more
room
for
the
work
area
if
needed.
Click
the
small
arrow
icon
to
the
right
of
the
My
Work
title
to
open
and
close
the
portfolio.
Figure
2.
The
SLM
Administrative
Console
is
displayed,
showing
the
Portfolio,
table
of
contents,
work
area,
and
optional
Task
Assistant
online
help
function.
Chapter
1.
Introduction
5
Tasks
in
the
portfolio
are
organized
into
task
groups
for
administering
offerings
and
administering
SLAs.
You
can
collapse
and
expand
these
task
groups
by
clicking
the
arrow
icons
next
to
the
task
group
names.
When
you
select
a
task
from
the
task
group,
the
associated
tables,
input
fields,
and
selection
menus
are
displayed
in
the
work
area
to
enable
you
to
perform
the
selected
task.
v
The
table
of
contents,
which
appears
between
the
portfolio
and
the
work
area
as
shown
in
Figure
3.
The
table
of
contents
helps
you
keep
track
of
where
you
are
in
the
creation
process
as
you
progress
through
the
various
steps
in
the
creation
wizard.
The
current
step
is
highlighted,
and
completed
steps
are
indicated
by
a
check
mark.
v
The
work
area,
in
the
center
of
the
page,
in
which
the
various
tasks
are
performed.
When
the
Welcome
page
is
displayed,
an
optional
table
is
displayed
in
the
work
area
that
shows
any
SLAs
that
have
recent
trends
or
violations.
You
can
set
preferences
to
display
only
trends
or
violations,
or
not
display
the
table
at
all.
When
you
create
and
manage
schedules,
offerings,
realms,
customers,
and
SLAs,
the
work
area
is
used
to
perform
those
tasks.
The
work
area
also
includes
the
optional
field
description
area
(FDA)
text,
that
provides
context
sensitive
information
for
the
specific
field
that
currently
has
focus
in
the
work
area,
as
shown
in
Figure
4
on
page
7.
Click
the
information
icon
(i)
in
the
upper
right
corner
to
show
or
hide
the
FDA
text.
Figure
3.
The
portfolio
contains
one
or
more
task
groups,
each
with
a
set
of
unique
tasks.
6
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
v
The
Task
Assistant,
to
the
right
of
the
work
area,
which
includes
the
online
embedded
user
assistance.
The
Task
Assistant
is
represented
by
the
question
mark
(?)
symbol
in
the
upper
right
area
of
the
SLM
Administrative
Console,
as
shown
in
Figure
5
on
page
8.
Click
the
question
mark
(?)
symbol
to
open
or
close
the
Task
Assistant.
Figure
4.
The
Field
Description
Area
(FDA)
text
is
optionally
displayed
to
the
left
of
the
work
area,
and
can
be
enabled
or
disabled
as
needed.
Chapter
1.
Introduction
7
The
Task
Assistant
provides
help
for
the
task
that
you
are
currently
performing.
If
the
Task
Assistant
is
displayed
as
you
change
tasks
or
move
through
multiple
steps
in
the
work
area,
the
information
in
the
Task
Assistant
changes
to
match
the
current
operation
in
the
work
area.
When
you
first
sign
on
to
the
SLM
Administration
Console,
the
Welcome
page
is
displayed.
While
the
Welcome
page
is
displayed,
click
the
question
mark
icon
to
open
the
Task
Assistant,
and
then
scroll
down
and
click
Key
Components
of
IBM
Tivoli
Service
Level
Advisor
to
learn
more
about
the
SLM
Administration
Console
and
the
functions
that
are
available.
Accessibility
Features
of
the
SLM
Administrative
Console
Accessibility
features
help
a
user
who
has
a
physical
disability,
such
as
restricted
mobility
or
limited
vision,
to
use
software
products
successfully.
These
are
the
major
accessibility
features
of
the
SLM
Administrative
Console:
v
You
can
use
screen-reader
software
and
a
digital
speech
synthesizer
to
hear
what
is
displayed
on
the
screen.
You
can
also
use
voice-recognition
software
to
enter
data
and
to
navigate
the
user
interface.
v
You
can
operate
all
features
using
the
keyboard
rather
than
the
mouse.
The
keyboard
shortcuts
for
the
SLM
Administrative
Console
are
the
standard
keyboard
shortcuts
for
your
Web
browser.
v
You
can
change
the
font
size
and
color
scheme
of
the
SLM
Administrative
Console
through
the
standard
controls
for
these
items
in
your
Web
browser,
or
in
the
Preferences
section
of
the
SLM
Administrative
Console.
Figure
5.
The
Task
Assistant
is
optionally
displayed
to
the
left
of
the
work
area,
and
provides
context
sensitive
help
information
for
the
task
currently
being
performed.
8
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
You
can
use
the
IBM
Home
Page
Reader
screen
reader
with
the
SLM
Administrative
Console.
For
information
about
this
screen
reader,
see
the
following
Web
site:
http://www-306.ibm.com/able/solution_offerings/hpr.html
Chapter
1.
Introduction
9
10
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
2.
Overview
of
the
SLA
Process
This
chapter
introduces
you
to
the
typical
flow
of
measurement
data
between
the
various
components
of
IBM
Tivoli
Service
Level
Advisor,
from
the
first
time
data
is
retrieved
from
the
Tivoli
Data
Warehouse
database
through
the
customer
viewing
Web-based
reports
of
the
data
analysis
performed
by
IBM
Tivoli
Service
Level
Advisor.
You
also
learn
where
in
the
overall
process
that
schedules,
offerings,
customers,
and
realms
are
created,
and
how
they
are
associated
with
available
resources
to
create
the
SLAs
that
are
managed
with
IBM
Tivoli
Service
Level
Advisor.
Though
some
of
these
steps
can
occur
at
the
same
time,
they
are
presented
here
in
sequence
to
help
you
understand
the
general
flow
of
events.
This
chapter
addresses
the
primary
flow
of
creating
and
managing
SLAs,
including
secondary
flows
such
as
changing
or
canceling
schedules
and
offerings.
This
flow
does
not
address
the
collection
of
metric
data
by
the
various
source
applications
and
writing
this
data
into
the
Tivoli
Data
Warehouse
database.
For
purposes
of
this
flow
it
is
assumed
that
this
data
already
exists
in
the
data
warehouse,
and
that
source
applications
are
configured
and
scheduled
to
regularly
write
performance
and
availability
data
to
Tivoli
Data
Warehouse.
The
SLA
Process
Flow
Figure
6
on
page
12
shows
the
overall
flow
of
data
from
the
Tivoli
Data
Warehouse
database
through
the
local
databases
used
by
IBM
Tivoli
Service
Level
Advisor,
and
into
the
evaluation
and
reporting
functions,
resulting
in
Web-based
reports
for
customers
and
internal
users.
With
these
reports
and
from
automated
event
notification
of
violations
or
trends
toward
violations,
support
personnel
can
take
necessary
corrective
action
to
continue
to
provide
the
agreed
upon
levels
of
service.
©
Copyright
IBM
Corp.
2002,
2004
11
The
steps
in
the
flow
are
numbered
in
sequence
in
the
diagram,
and
are
described
in
the
following
sections.
References
to
other
documentation
point
you
to
more
detailed
information.
The
general
process
flow
steps,
as
shown
in
Figure
6,
are
described
in
the
following
sections:
v
“Step
1.
Enabling
Source
Application
Data”
v
“Step
2.
Obtaining
Measurement
and
Resource
Type
Information”
on
page
13
v
“Step
3.
Creating
Offerings”
on
page
13
v
“Step
4.
Creating
Service
Level
Agreements”
on
page
15
v
“Step
5.
Getting
Measurement
Data
for
Evaluation”
on
page
16
v
“Step
6.
Evaluating
Data
for
Violations
and
Trends”
on
page
17
v
“Step
7.
Notification
of
Service
Level
Violations
and
Trends”
on
page
17
v
“Step
8.
Accessing
Web-Based
SLA
Reports”
on
page
17
Though
all
of
the
steps
listed
above
are
described
briefly
in
this
chapter,
the
remaining
chapters
of
Managing
Service
Level
Agreements
focuses
on
the
first
four
steps
listed
above.
Refer
to
the
SLM
Reports
document
for
more
detail
on
the
subsequent
steps
in
this
overall
process,
related
to
obtaining
the
measurement
data,
evaluation
of
the
data,
event
notification,
and
accessing
the
reports.
Step
1.
Enabling
Source
Application
Data
Before
you
create
offerings
or
SLAs
using
IBM
Tivoli
Service
Level
Advisor,
you
should
find
out
which
source
applications
are
enabled
for
data
collection
by
IBM
Tivoli
Service
Level
Advisor.
Your
enterprise
environment
might
have
several
different
performance
and
availability
monitoring
applications
that
are
locally
collecting
data
on
monitored
resources
and
periodically
writing
this
data
to
Tivoli
Data
Warehouse.
Because
there
can
be
many
Tivoli
applications
and
other
third
Figure
6.
The
overall
flow
of
measurement
data
in
IBM
Tivoli
Service
Level
Advisor.
12
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
party
applications
writing
performance
and
availability
data
to
the
Tivoli
Data
Warehouse
database,
your
SLM
Administrator
usually
enables
only
certain
source
applications
and
register
them
with
IBM
Tivoli
Service
Level
Advisor
for
regular
data
collection
and
evaluation.
This
reduces
the
amount
of
data
being
moved
from
the
central
data
warehouse
to
the
local
SLM
databases,
and
enables
IBM
Tivoli
Service
Level
Advisor
to
operate
more
efficiently.
Consult
with
your
SLM
Administrator
to
find
out
if
source
applications
have
already
been
added
to
the
SLM
environment
and
enabled
for
data
collection,
and
refer
to
the
Getting
Started
document
for
information
on
enabling
data
collection
for
source
applications.
Step
2.
Obtaining
Measurement
and
Resource
Type
Information
After
enabling
one
or
more
source
applications
for
data
collection,
the
SLM
Administrator
also
configures
and
schedules
the
Registration
ETL.
The
Registration
ETL
is
responsible
for
registering
information
about
the
types
of
measurement
data
that
exist
in
Tivoli
Data
Warehouse
for
the
source
applications
that
were
enabled
for
data
collection
(see
“Step
1.
Enabling
Source
Application
Data”
on
page
12.).
For
example,
you
might
have
a
Web
application
that
is
being
monitored
for
response
time
using
IBM
Tivoli
Monitoring
for
Transaction
Performance.
This
Tivoli
source
application
might
use
the
Transaction
Node
resource
type
to
measure
the
QoS
(quality
of
service)
of
the
real
transactions.
After
IBM
Tivoli
Monitoring
for
Transaction
Performance
is
enabled
for
data
collection
by
your
SLM
Administrator,
information
about
this
source
application
and
the
resource
types
that
are
available
are
registered
using
the
Registration
ETL.
The
Registration
ETL
extracts
records
from
the
data
warehouse,
transforms
them
into
a
format
usable
by
IBM
Tivoli
Service
Level
Advisor,
and
then
loads
the
resulting
records
into
the
SLM
Database.
In
later
steps
when
you
create
offerings
and
SLAs
to
measure
response
time,
you
can
select
this
resource
type
from
the
list
of
available
information.
The
Registration
ETL
can
be
run
explicitly
from
the
Data
Warehouse
Center
component
of
Tivoli
Data
Warehouse,
or
it
can
be
scheduled
to
run
automatically
at
regular
intervals.
Approximately
ten
minutes
after
the
first
time
that
the
Registration
ETL
is
run
successfully,
the
data
is
registered
to
IBM
Tivoli
Service
Level
Advisor,
and
from
that
time
forward
IBM
Tivoli
Service
Level
Advisor
checks
for
new
data
to
register
every
ten
minutes.
Consult
with
your
SLM
Administrator
to
verify
that
the
Registration
ETL
is
scheduled
and
run
at
least
once.
As
new
source
applications
are
enabled
for
data
collection,
this
data
is
registered
at
the
next
regularly
scheduled
interval
after
the
Registration
ETL
is
run.
Step
3.
Creating
Offerings
After
the
SLM
Database
is
populated
with
information
on
the
types
of
resources
and
measurement
data
that
exist
in
the
Tivoli
Data
Warehouse
database
for
source
applications
that
are
enabled,
use
the
SLM
Administrative
Console
to
create
an
offering
by
doing
the
following
steps:
1.
Select
the
Create
Schedule
task
in
the
portfolio
to
define
a
business
schedule
for
the
offering.
Business
schedules
segment
the
hours
of
business
operation
into
unique
schedule
states,
such
as
peak,
standard,
prime,
off
hours,
and
others.
Later
in
the
offering
creation
process,
when
you
select
metrics
to
include
in
the
offering,
you
can
assign
unique
breach
values
to
each
schedule
state,
enabling
you
to
define
different
periods
in
the
schedule
when
measurements
might
be
more
critical
than
at
other
times
in
the
schedule.
Chapter
2.
Overview
of
the
SLA
Process
13
You
can
also
use
the
Create
Schedule
task
to
optionally
define
one
or
more
auxiliary
schedules
that
you
can
include
in
your
business
schedule,
which
might
contain
company
holiday
schedules
or
maintenance
schedules
that
apply
throughout
your
enterprise.
You
can
include
an
auxiliary
schedule
in
more
than
one
business
schedule,
and
you
can
define
schedule
periods
once
and
include
them
in
multiple
business
schedules.
2.
Select
the
Create
Offering
task
in
the
portfolio
to
define
the
details
of
the
offering.
The
offering
is
created
by
completing
the
following
general
steps:
a.
Define
the
type
of
SLA
(external,
internal,
or
outsourced)
for
which
this
offering
is
being
created.
See
“Selecting
the
SLA
Type”
on
page
39
for
more
information.
b.
Optionally
include
one
or
more
previously
deployed
SLAs
in
the
offering.
When
this
offering
is
later
included
in
another
SLA,
you
have
effectively
created
an
SLA
within
an
SLA,
or
a
tiered
SLA.
c.
Include
the
business
schedule
(and
any
auxiliary
schedules
that
are
included
in
the
business
schedule),
that
you
created
previously
(you
can
also
create
a
new
business
schedule
at
this
point
if
you
have
not
already
done
so,
and
then
select
it
to
be
included
in
the
offering)
d.
Include
one
or
more
offering
components,
which
are
defined
by
completing
the
following
steps:
1)
Select
a
resource
type
from
the
list
of
available
resource
types
in
a
table,
based
on
the
source
applications
that
are
enabled
for
IBM
Tivoli
Service
Level
Advisor
2)
Configure
the
selected
resource
type
by
doing
the
following
steps:
a)
Select
a
metric
from
the
list
of
available
metrics
that
are
associated
with
the
selected
resource
type
b)
Configure
the
metric
by
doing
the
following
steps:
i.
Specify
unique
breach
values
(minimum,
maximum,
average,
or
total)
to
be
applied
for
each
schedule
period
(except
periods
in
the
No
Service
state).
These
schedule
periods
are
defined
in
the
business
schedule
that
you
included
in
this
offering.
ii.
Specify
the
frequency
at
which
the
metric
is
evaluated
for
violations
and
analyzed
for
trends.
You
can
set
the
frequency
for
this
service
level
objective
(SLO)
evaluation
to
occur
on
a
daily,
weekly,
or
monthly
interval
(for
certain
metrics
you
can
optionally
enable
hourly
evaluation
intervals).
The
evaluations
are
automatically
performed
after
the
Process
ETL
completes
the
moving
of
the
most
recent
measurement
data
from
the
central
data
warehouse
into
the
SLM
Measurement
Data
Mart.
iii.
Optionally
configure
advanced
settings
for
the
metric
if
they
apply:
v
Enable
intermediate
evaluations.
v
Define
the
frequency
for
trend
analysis
(which
can
be
different
than
evaluation
frequency).
v
If
you
have
source
applications
that
are
reliably
collecting
data
for
certain
metrics
and
writing
that
data
into
the
central
data
warehouse
on
a
regular
frequency,
and
your
SLA
is
dependent
upon
this
data
being
consistently
present
in
every
evaluation
interval,
you
can
indicate
that
any
missing
data
is
to
be
considered
an
error
condition
that
needs
to
be
logged.c)
Select
another
metric
and
repeat
the
above
configuration
steps
for
that
metric.
14
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
3)
Specify
a
name
and
optional
text
description
for
the
offering
component.
4)
Include
another
offering
component
and
repeat
the
above
steps
for
that
offering
component.e.
Publish
the
offering,
which
makes
it
available
to
be
included
in
an
SLA.
At
this
point
you
can
also
save
the
offering
in
a
draft
(not
yet
published)
state,
to
be
completed
at
a
later
time.
These
tasks
are
typically
performed
by
a
user
with
the
role
of
Offering
Specialist
(see
the
Administrator’s
Guide
document
for
information
on
users
and
roles).
See
Chapter
4,
“Creating
and
Managing
Offerings,”
on
page
37
for
details
on
the
offering
creation
process.
Step
4.
Creating
Service
Level
Agreements
After
creating
and
publishing
one
or
more
offerings,
each
of
which
define
a
unique
level
of
service,
you
can
select
one
of
these
offerings
and
associate
it
with
a
customer
name
and
a
resource
or
set
of
resources
to
create
a
service
level
agreement
(SLA).
To
create
the
SLA,
complete
the
following
basic
steps:
1.
Select
the
Create
Realm
task
in
the
portfolio
to
define
a
collection
of
customers
called
a
realm.
Customers
in
the
same
or
different
organizations,
companies,
geographic
regions,
and
so
on,
can
be
grouped
into
realms
that
segregate
one
customer’s
data
and
reports
from
another.
For
example,
you
might
create
a
realm
for
all
customers
in
the
United
States,
and
another
realm
for
customers
in
Europe.
You
might
also
create
a
realm
for
customers
in
a
particular
line
of
business
within
your
organization,
or
other
grouping
that
makes
sense
for
your
enterprise.
Customers
can
be
associated
with
more
than
one
realm.
2.
Select
the
Create
Customer
task
in
the
portfolio
to
define
a
customer
name
and
associate
it
with
one
or
more
exisiting
realms.
You
can
also
create
new
realms
and
associate
them
to
the
customer
name
if
you
did
not
previously
define
them.
3.
Select
the
Create
SLA
task
in
the
portfolio
to
associate
customers,
offerings,
and
resources
into
a
service
level
agreement,
by
completing
the
following
steps:
a.
Optionally
specify
a
name
and
description
for
the
SLA
(if
not
provided,
an
ID
number
is
automatically
assigned).
b.
Select
an
existing
customer
from
the
list
of
available
customers
to
include
in
this
SLA.
You
can
also
create
a
new
customer
(and
one
or
more
associated
realms)
and
include
the
new
customer
in
the
SLA
if
you
had
not
previously
defined
it.
c.
Select
an
offering
from
the
list
of
published
offerings
that
were
previously
defined
(see
“Step
3.
Creating
Offerings”
on
page
13).
d.
Based
on
the
offering
that
you
selected,
and
the
resource
types
defined
in
the
offering,
you
then
select
specific
resources
(or
define
a
dynamic
list
of
resources
that
might
change
over
time)
in
your
enterprise
that
match
those
resource
types,
on
which
the
customer
wants
levels
of
service
to
be
managed.
Filtering
techniques
enable
you
to
quickly
select
the
resources
from
the
potentially
large
list
of
possible
resources
available
in
the
SLM
Database.
You
must
select
at
least
one
resource
or
create
one
filtered
dynamic
resource
list
for
every
offering
component
that
is
defined
in
the
offering.
Chapter
2.
Overview
of
the
SLA
Process
15
e.
Specify
a
start
date
for
when
you
want
the
SLA
to
become
active.
This
enables
you
to
specify
a
date
in
the
past
if
you
want
to
evaluate
historical
data
that
is
already
in
the
Tivoli
Data
Warehouse
database,
or
specify
a
date
in
the
future
if
you
do
not
want
to
activate
the
SLA
immediately.
Based
on
the
SLA
start
date
that
you
specify,
IBM
Tivoli
Service
Level
Advisor
calculates
when
the
first
daily,
weekly,
or
monthly
SLO
evaluations
(and
hourly
evaluations,
if
enabled)
occur.
f.
After
completing
the
above
steps,
submit
the
SLA
to
IBM
Tivoli
Service
Level
Advisor,
where
it
is
processed
and
scheduled
for
evaluating
measurement
data
associated
with
the
selected
resources.
These
tasks
are
typically
performed
by
a
user
with
the
role
of
SLA
Specialist
(see
the
Administrator’s
Guide
document
for
information
on
users
and
roles).
For
details
on
the
SLA
creation
process,
see
Chapter
7,
“Creating
and
Managing
SLAs,”
on
page
57.
Step
5.
Getting
Measurement
Data
for
Evaluation
IBM
Tivoli
Service
Level
Advisor
does
not
evaluate
measurement
data
directly
from
Tivoli
Data
Warehouse,
but
uses
data
that
is
transferred
from
the
data
warehouse
into
the
SLM
Measurement
Data
Mart.
Measurement
data
from
the
data
warehouse
is
transformed
through
the
Process
ETL
into
a
simpler
format
for
use
by
IBM
Tivoli
Service
Level
Advisor.
The
Process
ETL
is
run
either
explicitly
by
the
warehouse
administrator
or
run
on
a
schedule
defined
and
maintained
by
the
warehouse
administrator,
and
is
run
after
all
of
the
source
applications
have
written
their
latest
measurement
data
into
the
data
warehouse.
The
Process
ETL
should
be
scheduled
to
run
at
a
frequency
that
matches
when
you
expect
SLO
evaluations
(or
the
more
frequent
intermediate
evaluations,
if
they
are
enabled)
to
be
performed
on
the
data.
For
example,
if
you
specify
in
the
offering
for
the
SLA
that
you
want
SLO
evaluations
to
be
performed
on
a
daily
basis,
then
you
must
ensure
that
the
Process
ETL
is
set
up
to
move
the
latest
measurement
data
from
the
warehouse
database
into
the
SLM
Measurement
Data
Mart
on
a
daily
basis
as
well,
so
that
the
latest
data
is
evaluated
at
the
right
time.
As
another
example,
if
you
have
source
applications
that
write
the
latest
measurement
data
to
the
warehouse
on
an
hourly
basis,
the
Process
ETL
should
be
configured
to
move
data
on
an
hourly
basis
from
the
warehouse,
and
you
might
choose
to
define
your
SLO
evaluation
frequency
as
hourly,
or
specify
the
SLO
evaluation
frequency
as
daily,
and
enable
intermediate
evaluations
to
occur
on
an
hourly
basis.
See
Chapter
4,
“Creating
and
Managing
Offerings,”
on
page
37
for
more
information
on
the
effect
of
specifying
SLO
and
intermediate
evaluation
frequencies,
and
see
Chapter
9,
“Event
Escalation
and
Notification,”
on
page
77
for
more
information
about
the
escalation
and
evaluation
processes.
See
the
Administrator’s
Guide
document
for
more
information
about
the
Process
ETL
and
the
SLM
Measurement
Data
Mart.
16
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Step
6.
Evaluating
Data
for
Violations
and
Trends
SLAs
that
you
submit
to
IBM
Tivoli
Service
Level
Advisor
include
information
that
you
specified
that
determines
the
frequency
of
when
evaluations
and
trend
analysis
are
to
be
performed
on
measurement
data
from
the
SLM
Measurement
Data
Mart,
with
these
tasks
occurring
on
a
daily,
weekly,
or
monthly
basis
(and,
if
enabled,
on
an
hourly
basis).
After
the
Process
ETL
has
completed
moving
the
most
recent
measurement
data
from
the
data
warehouse
into
the
SLM
Measurement
Data
Mart
on
a
day
when
the
hourly,
daily,
weekly,
or
monthly
SLO
evaluation
interval
is
reached,
IBM
Tivoli
Service
Level
Advisor
pulls
the
appropriate
data
from
the
SLM
Measurement
Data
Mart
and
evaluates
the
collected
measurement
data
on
the
resources
against
the
breach
values
defined
in
the
offering.
Data
can
be
evaluated
on
an
intermediate
frequency
as
well,
if
intermediate
evaluations
are
enabled
for
that
metric.
IBM
Tivoli
Service
Level
Advisor
looks
for
violations
of
the
agreed
upon
levels
of
service,
or
trends
toward
a
potential
future
violation,
and
stores
the
results
of
this
analysis
in
the
SLM
Database.
Step
7.
Notification
of
Service
Level
Violations
and
Trends
Each
violation
or
trend
is
stored
in
the
SLM
Database,
and
a
notification
is
sent
to
external
support
personnel
or
other
applications,
by
way
of
e-mail,
SNMP
traps,
or
Tivoli
Enterprise
Console
events.
These
methods
of
notification
are
specified
during
the
installation
of
IBM
Tivoli
Service
Level
Advisor,
and
can
be
configured
at
any
time
by
the
SLM
Administrator
using
command
line
interface
(CLI)
commands.
See
Chapter
9,
“Event
Escalation
and
Notification,”
on
page
77
for
more
information
on
notification
of
violations
and
trends,
and
the
Administrator’s
Guide
and
Command
Reference
documents
for
information
on
configuring
for
notification.
Step
8.
Accessing
Web-Based
SLA
Reports
After
the
measurement
data
is
evaluated
and
analyzed,
SLA
reports
can
be
generated
on
demand
and
viewed
using
a
Web
browser.
SLA
reports
include
tabular
and
graphical
views
of
results,
trends,
violations,
and
SLA
details
associated
with
an
SLA.
Reports
are
generated
in
HTML
and
can
be
integrated
into
a
customer’s
Web
site.
Reports
can
be
filtered
by
customer,
SLA,
offering
component,
realm,
SLA
type,
and
resource,
and
can
be
displayed
with
hourly,
daily,
weekly,
or
monthly
time
intervals.
User
authentication
can
be
used
to
restrict
access
to
reports
and
to
segregate
report
data.
Reports
can
also
be
exported
to
or
Microsoft
Excel
files,
for
easier
distribution
or
manual
modification
for
use
in
presentations,
status
reports,
and
other
uses.
See
the
SLM
Reports
document
for
details
on
the
various
reports
and
reports
related
functions
that
are
available.
Chapter
2.
Overview
of
the
SLA
Process
17
18
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
3.
Creating
and
Managing
Schedules
This
chapter
describes
the
process
of
creating
and
managing
business
schedules
and
auxiliary
schedules
by
using
the
SLM
Administration
Console.
Before
you
can
complete
the
creation
of
an
offering,
you
must
define
and
include
the
schedules
that
reflect
when
various
levels
of
service
must
be
monitored
and
guaranteed.
With
IBM
Tivoli
Service
Level
Advisor
you
can
define
one
or
more
schedules
and
later
select
one
from
the
available
list
to
be
included
in
an
offering.
Schedules
are
made
up
of
one
or
more
periods,
each
of
which
has
a
defined
start
and
end
time.
Each
unique
period
that
you
define
in
a
schedule
is
associated
with
a
particular
schedule
state,
which
is
used
to
represent
a
unique
level
of
service
during
that
particular
time
period.
For
example,
suppose
that
you
have
a
critical
resource,
such
as
a
server,
in
your
enterprise,
that
must
be
maintained
at
98%
availability
during
the
work
week,
defined
as
Monday
through
Friday,
09:00
through
16:59.
You
might
define
a
period
in
the
schedule
for
this
time
of
the
day,
and
associate
it
with
a
peak
schedule
state.
Later,
when
you
include
this
schedule
in
your
offering,
you
would
configure
the
service
level
objective
for
this
peak
schedule
state
to
reflect
a
98%
availability
during
this
time
period.
Outside
of
this
time
period,
suppose
that
the
availability
for
this
server
is
not
as
critical,
with
an
acceptable
availability
of
95%.
If
so,
the
remainder
of
the
week
might
be
defined
in
a
second
period,
defined
as
the
times
after
17:00
for
the
rest
of
that
day
and
the
hours
before
09:00
the
next
day,
as
well
as
all
day
Saturday
and
Sunday.
This
second
period
would
be
associated
with
a
different,
off
hours,
schedule
state.
When
configuring
the
service
level
objective
for
the
offering,
this
schedule
state
would
be
associated
with
the
less
critical
95%
availability
service
level.
You
might
also
define
a
third
schedule
period
with
a
state
of
no
service,
when
maintenance
work
is
performed
on
the
server.
This
period
might
be
defined
as
every
second
Wednesday
evening
between
the
hours
of
20:00
and
22:00,
during
non-peak
hours.
During
this
maintenance
time,
there
is
no
specific
guaranteed
availability
percentage,
because
the
system
is
taken
offline
for
maintenance.
Therefore
there
is
no
need
to
configure
this
no
service
schedule
state
in
the
offering.
You
might
also
optionally
define
certain
holidays
as
maintenance
or
no
service
times
for
all
resources
in
your
enterprise,
for
example,
Christmas
Day
(December
25).
You
can
define
this
common
schedule
period
once
in
an
auxiliary
schedule
and
then
include
this
common
auxiliary
schedule
in
one
or
more
business
schedules
that
you
have
defined.
Auxiliary
schedules
are
ideal
for
applying
special
schedule
periods
that
are
common
across
multiple
business
schedules.
Schedule
states
that
are
defined
in
an
auxiliary
schedule
must
also
be
configured
for
the
offering,
along
with
the
schedule
states
in
the
business
schedule
that
contains
the
auxiliary
schedule.
The
portfolio
contains
three
tasks
related
to
schedules:
v
Create
Schedule
is
for
creating
new
business
schedules
and
auxiliary
schedules
©
Copyright
IBM
Corp.
2002,
2004
19
v
Manage
Schedules
is
for
working
with
existing
schedules.
From
the
Manage
Schedules
page
you
can
also
create
new
business
and
auxiliary
schedules,
and
you
can
perform
the
following
additional
tasks:
–
Create
a
new
schedule
from
a
copy
of
an
existing
schedule
–
Change
the
contents
of
a
schedule
–
Delete
a
schedule
–
View
the
contents
of
a
schedulev
Customize
Schedules
is
used
for
setting
preferences
that
affect
all
schedules:
–
You
can
customize
the
default
names
of
schedule
states
to
suit
your
environment,
for
example,
changing
the
default
name
of
the
Standard
state
to
Normal,
or
another
name.
–
You
can
customize
your
enterprise
definition
of
fiscal
quarter
and
year,
if
they
occur
at
different
times
than
the
default
values.
Rules
for
Business
and
Auxiliary
Schedules
When
creating
and
managing
business
and
auxiliary
schedules,
keep
the
following
rules
in
mind:
v
You
can
only
include
one
business
schedule
in
an
offering.
v
You
can
include
one
or
more
auxiliary
schedules
in
a
business
schedule.
v
You
cannot
include
a
business
schedule
in
an
auxiliary
schedule.
v
You
cannot
include
a
business
schedule
in
another
business
schedule.
v
You
cannot
include
an
auxiliary
schedule
in
another
auxiliary
schedule.
v
You
cannot
directly
include
an
auxiliary
schedule
in
an
offering.
It
must
first
be
included
in
a
business
schedule,
and
then
the
business
schedule
is
included
in
the
offering.
v
After
an
auxiliary
schedule
is
included
in
one
or
more
business
schedules,
or
a
business
schedule
is
included
in
one
or
more
offerings,
the
schedule
can
be
changed
only
by
using
the
scmd
mem
addSingleSchedulePeriod
or
scmd
mem
removeSingleSchedulePeriod
CLI
commands
(in
the
Manage
Schedules
page,
the
Schedules
table
indicates
if
the
schedule
is
in
use).
v
A
schedule
must
have
at
least
one
period
defined.
If
you
include
an
auxiliary
schedule
in
a
business
schedule,
you
do
not
have
to
include
additional
periods
in
the
business
schedule,
because
there
is
already
at
least
one
period
defined
in
the
auxiliary
schedule.
v
If
an
auxiliary
schedule
has
not
yet
been
included
in
a
business
schedule,
it
can
be
changed
to
a
business
schedule.
v
An
auxiliary
schedule
does
not
have
a
default
schedule
state.
v
If
you
plan
to
include
auxiliary
schedules
in
your
business
schedule,
you
should
create
the
auxiliary
schedules
first.
Creating
Auxiliary
Schedules
You
can
create
a
new
auxiliary
schedule
by
doing
any
of
the
following
tasks:
v
From
the
portfolio,
select
Create
Schedule.
v
From
the
portfolio,
select
Manage
Schedules,
and
then
from
the
Manage
Schedules
page,
click
Create.
v
From
the
Manage
Schedules
page,
select
any
schedule
(business
or
auxiliary)
from
the
table
and
then
click
Create
Like
to
create
a
copy
of
the
selected
schedule,
which
you
can
then
modify
as
needed.
This
method
reduces
the
20
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
amount
of
configuring
you
have
to
do
by
enabling
you
to
make
a
few
changes
to
the
copy
and
save
it
as
a
new
auxiliary
schedule.
Create
a
new
auxiliary
schedule
by
completing
the
following
basic
steps:
1.
Type
a
name
for
the
schedule.
This
is
the
name
that
is
displayed
in
the
Included
Auxiliary
Schedules
table
when
you
later
include
this
auxiliary
schedule
in
a
business
schedule.
You
should
enter
a
name
that
is
meaningful
to
distinguish
this
auxiliary
schedule
from
other
auxiliary
schedules.
This
name
is
also
displayed
in
the
Schedules
table
on
the
Manage
Schedules
page,
which
contains
all
defined
business
and
auxiliary
schedules.
This
name
is
also
displayed
in
SLM
reports.
2.
Optionally
type
a
text
description
for
the
auxiliary
schedule.
This
is
additional
information
that
appears
in
the
Schedule
table
and
helps
describe
the
auxiliary
schedule.
This
information
might
make
it
easier
during
the
creation
of
business
schedules
to
select
the
auxiliary
schedule
to
include
in
the
business
schedule.
This
description
is
also
displayed
in
SLM
reports.
3.
Indicate
that
this
is
an
auxiliary
schedule
rather
than
a
business
schedule.
The
business
schedule
is
the
primary
schedule
that
is
included
in
an
offering.
An
auxiliary
schedule
is
used
to
define
common
schedule
periods
that
can
then
be
included
in
one
or
more
business
schedules,
and
is
useful
for
defining
periods
that
are
common
to
all
business
schedules
in
your
enterprise,
such
as
maintenance
times
or
holidays.
4.
Define
schedule
periods
for
the
auxiliary
schedule.
Unlike
business
schedules,
auxiliary
schedules
do
not
have
a
default
schedule
state
that
is
in
effect
for
time
periods
when
no
other
period
is
defined.
The
auxiliary
schedule
can
be
viewed
as
a
collection
of
one
or
more
schedule
periods
that
are
added
to
the
top
of
the
table
of
periods
in
the
business
schedule.
You
can
create
schedule
periods
and
add
them
to
the
Periods
table
for
the
auxiliary
schedule.
Each
unique
period
that
you
define
includes
the
following
information:
v
The
schedule
state,
such
as
Critical,
Peak,
Prime,
Standard,
Low
Impact,
Off
Hours,
and
No
Service
(maintenance
downtime).
v
The
time
zone
of
the
start
and
end
times
for
the
period
v
The
start
and
end
times
for
the
period
v
The
frequency
at
which
the
schedule
period
is
repeated
(only
once
on
a
specific
date,
or
daily,
weekly,
or
monthly
at
specific
intervals
that
you
can
configure)
See
“Creating
Periods”
on
page
23
for
more
information
on
creating
periods
for
your
auxiliary
schedule.
After
creating
the
periods
for
your
auxiliary
schedule,
you
can
view,
change,
or
delete
them
in
the
Periods
table,
and
you
can
move
them
up
and
down
in
the
table
relative
to
each
other.
The
order
of
the
periods
that
are
listed
in
the
Periods
table
take
precedence
from
top
to
bottom
in
the
table,
with
periods
at
the
top
of
the
list
taking
precedence
over
periods
further
down
the
list.
When
you
include
this
auxiliary
schedule
in
a
business
schedule,
all
periods
defined
in
this
auxiliary
schedule
take
precedence
over
any
periods
defined
in
the
business
schedule.
See
“Managing
Overlapping
Periods”
on
page
29
for
more
information
on
the
order
of
schedule
periods
in
business
and
auxiliary
schedules,
and
how
they
affect
the
overall
schedule
states
applied
to
the
offering.
Chapter
3.
Creating
and
Managing
Schedules
21
Creating
Business
Schedules
You
can
create
a
new
business
schedule
by
doing
any
of
the
following
tasks:
v
From
the
portfolio,
select
Create
Schedule.
v
From
the
portfolio,
select
Manage
Schedules,
and
then
from
the
Manage
Schedules
page,
click
Create.
v
From
the
Manage
Schedules
page,
select
any
schedule
(business
or
auxiliary)
from
the
table
and
then
click
Create
Like
to
create
a
copy
of
the
selected
schedule,
which
you
can
then
modify
as
needed.
With
this
method
you
can
minimize
the
amount
of
configuring
you
have
to
do
by
making
only
a
few
changes
to
the
copy
and
saving
it
as
a
new
business
schedule.
v
While
creating
an
offering,
you
can
create
a
new
schedule
if
the
preferred
schedule
is
not
already
in
the
schedule
table
(see
Chapter
4,
“Creating
and
Managing
Offerings,”
on
page
37).
Create
a
new
business
schedule
by
completing
the
following
basic
steps:
1.
Type
a
name
for
the
schedule.
This
is
the
name
that
is
displayed
in
the
table
of
available
schedules
when
you
later
include
a
business
schedule
in
an
offering.
You
should
type
a
name
that
is
meaningful
to
distinguish
this
business
schedule
from
other
business
schedules.
This
name
is
also
displayed
in
the
Schedules
table
on
the
Manage
Schedules
page,
which
contains
all
defined
business
and
auxiliary
schedules.
This
name
is
also
displayed
in
SLM
reports.
2.
Optionally
type
a
text
description
for
the
business
schedule.
This
is
additional
information
that
appears
in
the
Schedules
table
and
helps
describe
the
business
schedule.
This
information
might
make
it
easier
during
the
offering
creation
process
to
select
the
business
schedule
to
include
in
an
offering.
3.
Indicate
that
this
is
a
business
schedule
rather
than
an
auxiliary
schedule.
The
business
schedule
is
the
primary
schedule
that
is
included
in
an
offering.
An
auxiliary
schedule
is
used
to
define
common
schedule
periods
that
can
then
be
included
in
one
or
more
business
schedules,
and
is
useful
for
defining
periods
that
are
common
to
all
business
schedules
in
your
enterprise,
such
as
maintenance
times
or
holidays.
4.
Optionally
include
one
or
more
existing
auxiliary
schedules
in
the
business
schedule.
Initially
the
table
of
included
auxiliary
schedules
is
empty
for
a
new
business
schedule.
Click
Add
to
select
auxiliary
schedules
from
a
table
of
existing
schedules,
and
add
them
to
the
business
schedule
definition.
If
the
auxiliary
schedule
is
not
in
the
table,
you
can
do
one
of
the
following
tasks:
v
Cancel
the
Add
process
and
continue
with
creation
of
the
business
schedule.
After
the
business
schedule
is
created,
create
the
auxiliary
schedules
and
then
from
the
Manage
Schedules
page
change
the
business
schedule
to
add
auxiliary
schedules.
v
Cancel
the
Add
process,
then
back
out
of
this
business
schedule
creation
process
and
change
the
schedule
type
from
business
schedule
to
auxiliary
schedule,
create
the
auxiliary
schedules,
then
create
the
business
schedule
and
include
the
auxiliary
schedules.
v
Cancel
the
Add
process,
cancel
the
business
schedule
creation
process
and
use
the
Create
Schedule
wizard
to
create
auxiliary
schedules
before
creating
business
schedules.
After
adding
one
or
more
auxiliary
schedules
to
the
business
schedule,
you
can
continue
to
add
auxiliary
schedules,
remove
them
from
the
Included
Auxiliary
Schedules
table,
or
move
them
up
and
down
in
the
table,
relative
to
each
other.
The
order
of
the
periods
that
are
listed
in
the
auxiliary
schedules
take
22
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
precedence
from
top
to
bottom
in
the
table,
with
periods
at
the
top
of
the
list
taking
precedence
over
periods
further
down
the
list.
All
periods
in
auxiliary
schedules
take
precedence
over
any
periods
defined
in
the
business
schedule.
See
“Managing
Overlapping
Periods”
on
page
29
for
more
information
on
the
order
of
schedule
periods
in
business
and
auxiliary
schedules,
and
how
they
affect
the
overall
schedule
states
applied
to
the
offering.
5.
Define
schedule
periods
for
the
business
schedule.
You
can
first
set
a
default
schedule
state
that
is
in
effect
for
time
periods
when
no
other
period
is
defined.
Then
you
can
create
schedule
periods
and
add
them
to
the
Periods
table
for
the
business
schedule.
Each
unique
period
that
you
define
includes
the
following
information:
v
The
schedule
state,
such
as
Critical,
Peak,
Prime,
Standard,
Low
Impact,
Off
Hours,
and
No
Service
(maintenance
downtime).
v
The
time
zone
of
the
start
and
end
times
for
the
period
v
The
start
and
end
times
for
the
period
v
The
frequency
at
which
the
schedule
period
is
repeated
(only
once
on
a
specific
date,
or
daily,
weekly,
or
monthly
at
specific
intervals
that
you
can
configure)
See
“Creating
Periods”
for
more
information
on
creating
periods
for
your
business
schedule.
After
creating
the
periods
for
your
business
schedule,
you
can
view,
change,
or
delete
them
in
the
Periods
table,
and
you
can
move
them
up
and
down
in
the
table
relative
to
each
other.
The
order
of
the
periods
that
are
listed
in
the
Periods
table
take
precedence
from
top
to
bottom
in
the
table,
with
periods
at
the
top
of
the
list
taking
precedence
over
periods
further
down
the
list.
If
you
have
auxiliary
schedules
included
in
this
business
schedule,
all
periods
in
the
auxiliary
schedules
take
precedence
over
any
periods
defined
in
this
Periods
table.
See
“Managing
Overlapping
Periods”
on
page
29
for
more
information
on
the
order
of
schedule
periods
in
business
and
auxiliary
schedules,
and
how
they
affect
the
overall
schedule
states
applied
to
the
offering.
Creating
Periods
A
business
schedule
segments
the
hours
of
business
operation
into
distinct
periods
of
time,
each
of
which
has
a
specific
start
and
stop
time.
During
certain
business
hours,
for
example,
Monday
through
Friday
from
09:00
to
16:59,
you
might
have
resources
for
which
you
need
to
guarantee
levels
of
service
at
a
higher
level
than
at
other
times,
such
as
off
shift
hours,
weekends,
or
company
holidays.
This
is
illustrated
in
Figure
7,
which
shows
a
single,
peak
period
repeating
each
day
from
Monday
through
Friday,
during
the
business
hours
of
9:00
to
16:59.
These
varying
levels
of
service
can
be
expressed
as
one
or
more
schedule
states,
such
as
Critical,
Peak,
Prime,
Standard,
Low
Impact,
Off
Hours,
or
No
Service
(maintenance
times,
for
which
service
levels
are
not
measured).
Use
IBM
Tivoli
Service
Level
Advisor
to
create
one
or
more
periods
in
a
business
or
auxiliary
schedule
and
associate
one
of
these
schedule
states
with
each
defined
time
period.
Figure
7.
A
weekly
business
schedule
with
a
recurring
peak
schedule
period.
Chapter
3.
Creating
and
Managing
Schedules
23
Later,
when
you
include
this
business
schedule
in
an
offering,
you
can
configure
each
unique
schedule
state
in
the
business
schedule
(and
auxiliary
schedules
if
you
choose
to
include
them
in
the
business
schedule)
and
associate
a
unique
breach
value
that
represents
the
level
of
service
for
that
schedule
state.
For
example,
in
Figure
7
on
page
23,
you
can
assign
the
schedule
period
to
the
Peak
schedule
state,
and
then
configure
a
breach
value
for
this
schedule
state
that
represents
the
preferred
level
of
service
(for
example,
98%
availability).
Suppose
that
outside
of
this
peak
schedule
period,
the
demand
on
this
particular
resource
is
not
as
great,
and
the
level
of
service
does
not
have
to
be
maintained
at
such
a
high
level.
You
might
create
another
schedule
period,
from
17:00
to
22:59,
and
assign
a
schedule
state
of
Low
Impact
to
this
period,
as
shown
in
Figure
8.
You
might
create
a
period
for
No
Service
time,
when
maintenance
is
performed
on
the
resource
and
you
do
not
want
to
measure
service
levels
during
that
time.
Continuing
with
the
previous
example,
you
might
define
Saturdays
from
12:00
to
17:59
as
a
period
with
a
No
Service
schedule
state,
as
shown
in
Figure
9
on
page
25.
For
periods
assigned
to
the
No
Service
schedule
state,
any
violations
or
trends
that
occur
during
that
period
are
not
evaluated
or
counted
against
the
service
level
agreement.
A
default
state
is
also
specified
for
the
business
schedule,
which
enables
you
to
associate
every
segment
of
the
business
schedule
with
a
specific
schedule
state,
without
having
to
create
a
specific
period
to
cover
every
moment
in
time
in
the
schedule.
Continuing
with
the
previous
example,
you
might
specify
the
default
state
as
Off
Hours,
as
shown
in
Figure
9
on
page
25
This
period
could
be
configured
with
a
breach
value
representing
a
lower
level
of
service.
Figure
8.
A
second
schedule
period
is
defined
for
times
when
resource
service
levels
are
not
as
critical.
24
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
The
overall
business
schedule,
as
shown
at
the
bottom
of
Figure
9,
is
a
composite
of
the
various
schedule
periods
in
the
business
schedule.
At
any
time
in
the
schedule,
one
of
the
schedule
states
is
in
effect.
If
a
violation
or
trend
occurs
at
any
time
in
this
schedule,
it
is
evaluated
against
the
breach
value
that
was
configured
for
the
schedule
state
at
that
time.
For
example,
suppose
your
availability
service
level
for
the
monitored
resource
is
specified
according
to
Table
1:
Table
1.
Example
of
specifying
breach
values
for
higher
availability
percentage
during
peak
periods,
and
less
demanding
availability
levels
during
non-peak
periods.
Metric
Peak
Low
Impact
Off
Hours
No
Service
Availability
98%
95%
90%
N/A
The
breach
values
are
configured
for
these
availability
percentages
for
each
of
the
schedule
periods
during
offering
creation
(see
“Configuring
Service
Level
Objectives”
on
page
43).
Figure
9.
The
default
schedule
state
of
Off
Hours
is
added,
along
with
a
No
Service
period
to
complete
the
business
schedule.
Chapter
3.
Creating
and
Managing
Schedules
25
Now,
suppose
that
an
SLA
is
created
to
manage
the
availability
of
this
resource,
using
this
schedule
in
an
offering.
Some
time
after
the
SLA
is
submitted,
the
availability
of
this
resource
drops
from
an
average
of
99.5%
to
96%,
on
a
Tuesday
at
14:00.
Assuming
that
the
monitoring
application
measures
this
availability
and
writes
the
data
to
the
warehouse
database,
the
evaluation
results
determine
that
this
measurement
occurred
during
the
Peak
schedule
state.
The
measured
value
of
96%
is
compared
to
the
breach
value
of
98%,
resulting
in
a
violation
of
the
SLA,
as
shown
in
Figure
10.
If
this
measurement
had
occurred
on
Tuesday
at
19:30,
the
evaluation
would
determine
that
the
measurement
occurred
during
the
Low
Impact
schedule
state,
and
the
measurement
value
of
96%
would
be
compared
to
the
breach
value
of
95%.
In
this
case
no
violation
is
reported,
because
the
measurement
value
was
acceptable
during
this
schedule
state.
Similarly,
had
the
measurement
occurred
during
the
Off
Hours
schedule
state,
no
violation
would
be
reported.
Any
measurements
that
occurred
during
the
No
Service
schedule
state
are
not
evaluated.
Defining
Schedule
States
When
you
create
a
new
schedule,
there
are
no
periods
initially
defined
in
the
Periods
table.
All
time
in
the
schedule
is
initially
assigned
to
the
Critical
default
schedule
state.
There
are
several
schedule
states
that
you
can
use
to
distinguish
your
business
operations.
The
following
list
shows
the
default
names
for
these
schedule
states:
v
Critical
v
Peak
v
Prime
v
Standard
v
Low
Impact
v
Off
Hours
v
No
Service
Figure
10.
The
measured
availability
percentage
violates
during
the
Peak
schedule
state
but
causes
no
violation
during
the
Low
Impact
schedule
state.
26
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
For
example,
suppose
that
your
business
conducts
peak
operations
on
weekdays
from
9:00
to
16:59
and
does
not
provide
service
on
Sundays.
You
can
define
three
periods
in
your
schedule
as
shown
in
the
following
example:
v
Peak,
defined
between
09:00
and
16:59,
Monday
through
Friday
v
No
service,
defined
as
all
day
Sunday
v
Off
hours,
all
other
time
during
the
week
except
peak
and
no
service
times.
Using
peak,
off
hours,
and
no
service,
and
any
of
the
other
period
states
in
different
combinations,
you
can
define
any
number
of
business
operations,
each
of
which
might
have
a
different
level
of
service
as
defined
by
its
schedule
and
periods.
For
example,
you
could
create
a
premium
service,
with
a
schedule
that
defines
all
day,
every
day
as
peak
or
critical
hours.
You
can
use
any
or
all
of
these
states
depending
on
your
schedule
requirements.
You
can
define
a
higher
expected
level
of
service
during
a
peak
schedule
period
than
during
the
standard
schedule
period.
You
can
define
as
many
different
schedule
periods
as
you
like.
For
example,
you
can
define
one
peak
period
for
every
Monday
between
the
hours
of
09:00
and
16:59,
and
another
peak
period
for
every
second
Friday
of
the
month
between
06:00
and
17:59.
Similarly,
you
can
define
multiple
periods
for
any
of
the
other
schedule
states
as
well.
During
the
no
service
state,
monitored
metric
data
continues
to
be
collected,
but
is
not
evaluated.
Therefore,
violations
or
trends
toward
violations
that
occur
during
scheduled
maintenance
hours
do
not
count
against
your
SLAs.
Each
period
in
your
schedule
starts
and
ends
at
a
time
specified
by
you,
along
with
the
preferred
time
zone.
Specifying
Time
Zones
When
you
create
start
and
end
times
for
a
schedule
period,
you
also
indicate
the
time
zone
in
which
these
times
occur.
Usually
you
define
these
start
and
end
times
in
the
time
zone
where
the
SLM
Server
is
located.
Keep
in
mind,
however,
that
evaluations
are
performed
using
the
time
zone
that
is
specified
for
the
SLA,
which
can
be
a
different
time
zone
than
where
the
SLM
Server
is
located.
This
might
result
in
a
period
that
falls
within
two
consecutive
days,
or
a
period
that
occurs
on
a
different
day
in
the
time
zone
of
the
SLA.
For
example,
if
the
SLA
is
defined
such
that
evaluations
are
performed
in
the
Central
Standard
Time
zone,
and
you
specify
start
and
end
times
for
a
period
as
22:00
to
23:59
in
Central
Standard
Time,
the
actual
period
hours
in
the
schedule
is
evaluated
by
the
SLM
Server
between
22:00
and
23:59
Central
Standard
Time.
Suppose
instead
that
the
SLA
is
defined
such
that
daily
evaluations
are
performed
in
the
Eastern
Standard
Time
zone,
and
you
specify
the
same
start
and
end
times
as
above,
using
Central
Standard
Time.
The
SLM
Server
evaluates
data
for
this
time
period
using
the
equivalent
start
and
end
times
in
the
Eastern
Standard
Time
zone,
or
between
23:00
and
00:59
(the
next
day),
in
Eastern
Standard
Time.
This
results
in
a
time
period
spanning
more
than
one
day,
resulting
in
two
separate
evaluations
per
day,
one
between
23:00
and
23:59
EST
and
the
other
between
00:00
and
00:59
EST
the
following
day.
Consider
another
example,
as
illustrated
in
Figure
11
on
page
28,
which
shows
three
24-hour
days
(numbered
1-3),
with
each
day’s
schedule
including
periods
X,
Chapter
3.
Creating
and
Managing
Schedules
27
Y,
and
Z.
The
schedule
periods
for
the
business
schedule
are
all
defined
in
the
Eastern
Standard
Time
(EST)
time
zone,
while
the
SLA
is
defined
to
collect
data
in
Japan,
using
the
local
JPN
time
zone.
In
this
example,
evaluations
occur
at
14:00
EST
(04:00
JPN)
on
a
daily
basis,
with
evaluations
occurring
on
the
data
from
the
previous
full
day.
As
a
result
of
defining
the
periods
in
the
EST
time
zone,
the
following
evaluations
of
data
occur
within
the
three
periods
X,
Y,
and
Z:
v
Period
X
is
evaluated
correctly,
because
the
entire
period
is
included
in
the
same
day
for
both
EST
and
JPN
time
zones.
v
From
the
perspective
of
the
SLA
time
zone,
Period
Y
occurs
across
two
different
days,
and
the
SLM
Server
evaluates
the
data
occurring
in
the
early
half
of
Period
Y
for
its
day
1,
and
then
evaluate
the
data
occurring
in
the
second
half
of
Period
Y
for
its
day
2.
v
Period
Z
occurs
in
the
last
part
of
day
1
(EST)
but
in
the
first
part
of
day
2
(JPN).
The
SLM
Server
includes
evaluations
of
data
in
this
period
in
day
2.
From
this
example,
you
can
see
how
defining
periods
from
the
perspective
of
the
time
zone
defined
in
the
SLA
is
important
for
obtaining
expected
evaluation
Figure
11.
An
example
showing
a
business
schedule
defined
in
a
different
time
zone
from
the
time
zone
specified
in
the
SLA.
28
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
results.
This
example
shows
how
evaluations
can
be
affected
when
you
specify
a
time
zone
for
the
SLA
that
is
different
than
the
time
zones
of
the
schedule
periods
in
the
business
schedule
that
is
used
by
that
SLA.
It
is
a
better
practice
to
match
the
time
zones
of
the
schedule
periods
with
the
time
zone
of
the
SLA
that
uses
that
schedule.
This
might
result
in
not
being
able
to
reuse
the
schedule
with
other
SLAs
that
are
specified
in
different
time
zones,
but
having
time
zones
matched
between
schedule
periods
and
SLAs
is
easier
to
manage.
To
use
a
different
schedule,
you
need
to
create
another
offering.
Modifying
Time
Zone
Settings
You
might
want
to
change
the
time
zone
setting
in
any
of
the
following
cases:
v
Change
the
time
zone
for
a
schedule
period
from
the
default
value
to
one
matching
the
planned
SLA
time
zone.
v
Change
the
time
zone
for
the
start
time
of
an
SLA
from
the
default
value
during
a
Create
or
Create
Like
operation.
v
Change
the
association
of
a
time
zone
to
a
particular
user
of
SLM
Reports
using
scmd
report
addUser
or
scmd
report
changeUser
CLI
commands
Defining
Period
Frequency
The
frequency
of
the
defined
period
indicates
how
often
in
the
schedule
this
period
is
in
the
active
state.
You
can
define
the
frequency
of
the
period
to
be
any
of
the
following
options:
v
Occurring
one
time
on
a
particular
date,
specifying
the
month,
day,
and
year
v
Occurring
daily
at
the
same
start
and
end
time
each
day
v
Occurring
weekly,
so
you
can
select
one
or
more
specific
days
of
the
week
v
Occurring
monthly,
so
you
can
select,
for
example,
the
fifteenth
day
of
the
month,
or
on
a
day
interval,
such
as
the
second
Friday
of
every
month.
You
can
also
specify
one
or
more
months
during
the
year
for
when
this
period
is
active.
For
example,
to
define
the
Peak
period
for
the
example
in
Figure
7
on
page
23,
enter
a
start
time
of
09:00,
an
end
time
of
16:59,
and
then
select
a
Repeating
Frequency
of
Weekly,
and
when
the
days
of
the
week
are
displayed,
select
the
check
boxes
for
Monday,
Tuesday,
Wednesday,
Thursday,
and
Friday,
but
leave
Saturday
and
Sunday
cleared.
Managing
Overlapping
Periods
Because
schedule
periods
can
overlap,
the
order
in
which
schedule
periods
are
listed
in
the
Periods
table
is
important.
Consider
these
schedule
periods
defined
in
the
Periods
table
in
this
order:
Peak
Weekdays,
09:00
to
17:00
Standard
Weekdays,
all
day
No
Service
Every
day,
all
day
When
defined
periods
overlap
at
any
given
time,
priority
is
given
to
the
state
of
the
period
that
resides
closest
to
the
top
of
the
ordered
list
of
defined
periods
in
the
business
schedule.
The
first
schedule
period
to
match
a
specified
date
and
time
is
used.
In
this
example,
at
10:00
each
Monday,
all
three
periods
are
in
effect.
However,
because
the
Peak
period
is
at
the
top
of
the
list
of
periods,
Mondays
at
10:00
are
Chapter
3.
Creating
and
Managing
Schedules
29
considered
peak
times.
At
20:00
each
Wednesday,
the
Peak
period
is
no
longer
in
effect,
but
Standard
and
No
Service
periods
are
still
in
effect.
Because
the
Standard
period
is
higher
in
the
table
than
No
Service,
20:00
on
Wednesday
is
considered
to
be
standard
time.
On
Saturdays,
only
the
No
Service
period
is
in
effect,
so
weekends
are
considered
to
be
No
Service
times.
You
can
rearrange
the
order
of
the
periods
in
the
list
to
define
the
priority
that
suits
your
needs.
You
can
rearrange
the
order
of
the
periods
in
the
table
by
selecting
a
period
and
then
using
the
Move
Up
and
Move
Down
buttons.
Overlapping
Periods
in
Auxiliary
Schedules
If
you
have
included
one
or
more
auxiliary
schedules
in
your
business
schedule,
all
periods
in
the
auxiliary
schedules
take
precedence
over
any
period
defined
in
the
business
schedule.
This
is
the
equivalent
of
placing
the
periods
from
the
auxiliary
schedules
at
the
top
of
the
Periods
table,
above
all
of
the
periods
in
the
business
schedule.
Within
an
auxiliary
schedule,
you
can
move
schedule
periods
up
and
down
in
the
Periods
table
for
that
auxiliary
schedule.
Within
a
business
schedule,
if
more
than
one
auxiliary
schedule
is
included
in
the
Included
Auxiliary
Schedules
table,
you
can
move
auxiliary
schedules
up
and
down
in
the
list
relative
to
each
other.
The
periods
defined
in
the
auxiliary
schedule
at
the
top
of
the
table
take
precedence
over
other
auxiliary
schedule
periods
and
business
schedule
periods
that
reside
lower
in
the
table.
As
an
example
of
creating
a
business
schedule
with
one
or
more
associated
auxiliary
schedules,
suppose
you
are
creating
a
business
schedule,
Schedule
1,
which
has
associated
with
it
the
following
two
auxiliary
schedules:
v
Holiday
Schedule,
which
is
defined
as
an
auxiliary
schedule
and
has
two
periods
defined,
holiday1
and
holiday2.
v
Maintenance
Schedule,
which
is
defined
as
an
auxiliary
schedule
and
has
scheduled
maintenance
periods
defined
as
maint1
and
maint2.
The
business
schedule
Schedule
1
is
defined
with
three
periods,
period1,
period2,
and
period3.
Combined
with
the
auxiliary
schedules,
Schedule
1
is
then
defined
to
include
the
following
periods:
1.
Auxiliary
Schedules:
v
Holiday
Schedule
v
Maintenance
Schedule2.
Schedule
1
period1
3.
Schedule
1
period2
4.
Schedule
1
period3
The
auxiliary
schedules
are
listed
in
order
of
their
priority,
as
defined
in
the
Included
Auxiliary
Schedules
table
for
the
business
schedule.
You
can
move
auxiliary
schedules
up
and
down
in
this
table
to
change
the
priority.
When
Schedule
1
is
included
in
an
offering,
all
of
the
associated
schedule
periods
are
used
in
the
following
sequence
of
priority:
1.
holiday1
2.
holiday2
3.
maint1
4.
maint2
30
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
5.
period1
6.
period2
7.
period3
In
general,
the
following
sequential
order
shows
how
periods
are
used
in
a
schedule
with
one
or
more
auxiliary
schedules:
1.
Periods
in
the
first
auxiliary
schedule,
in
the
order
defined
in
that
schedule
2.
Periods
in
the
second
auxiliary
schedule,
in
the
order
defined
in
that
schedule
3.
Periods
in
subsequent
auxiliary
schedules,
in
the
order
defined
in
those
schedules
4.
Periods
of
this
business
schedule,
in
the
order
defined
in
the
schedule
5.
The
period
of
the
state
defined
as
active
during
unspecified
times
in
the
schedule
Customizing
Schedule
Preferences
Using
the
Customize
Schedules
task
in
the
portfolio,
you
can
set
certain
preferences
for
schedules
in
your
enterprise:
v
You
can
change
the
default
names
of
schedule
states
v
You
can
customize
the
definitions
of
fiscal
quarter
and
year
for
your
enterprise
Changing
Schedule
State
Names
You
can
change
the
names
of
one
or
more
default
schedule
states
to
more
closely
reflect
the
needs
of
your
enterprise
environment.
From
the
portfolio,
select
Customize
Schedules,
which
displays
the
window
shown
in
Figure
12
on
page
32:
Chapter
3.
Creating
and
Managing
Schedules
31
As
shown
in
Figure
12,
select
the
Schedule
States
tab
to
specify
new
label
names
for
the
various
schedule
states.
In
this
example,
the
default
label
Standard
is
replaced
with
Normal,
which
is
shown
in
the
Current
Label
column.
This
column
shows
the
label
name
that
is
actually
displayed
in
administrative
and
report
user
interface
screens.
Similarly,
the
default
label
Off
Hours
is
changed
to
Off
Peak.
Note
that
the
No
Service
state
cannot
be
renamed
because
its
only
use
is
in
specifying
periods
of
no
activity
or
scheduled
maintenance.
Though
you
can
rename
each
schedule
state,
the
relative
priority
remains
unchanged
(for
example,
the
Critical
state
remains
the
highest
priority
state,
even
after
changing
its
label
to
Crucial,
or
some
other
name).
Globally
changing
the
name
of
a
schedule
state
does
not
affect
the
operation
of
the
state
in
offerings
or
SLAs,
which
are
still
processed
and
evaluated
in
the
same
way.
If
schedule
state
names
are
modified,
they
are
not
translated.
The
new
label
name
appears
in
subsequent
displays
and
reports
in
the
language
in
which
it
was
entered,
even
if
displayed
in
a
different
locale.
If
a
default
state
name
is
not
overwritten,
the
default
name
is
translated.
Refer
to
the
information
in
the
Task
Assistant
for
specific
procedures
on
renaming
schedule
states.
Customizing
Your
Fiscal
Quarter
and
Year
If
your
enterprise
operates
under
a
fiscal
year
that
does
not
correspond
to
standard
calendar
time
periods,
you
can
customize
the
global
definition
of
quarter
and
year
for
your
enterprise
reports.
You
can
generate
reports
that
more
closely
reflect
the
fiscal
year
and
quarter
for
your
enterprise.
Figure
12.
Renaming
schedule
states
32
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
From
the
portfolio,
select
Customize
Schedules
and
then
select
the
Quarterly
Dates
tab,
which
displays
the
configuration
information
as
shown
in
Figure
13.
You
can
specify
the
starting
day
for
each
quarter,
or
the
first
day
of
the
fiscal
year.
If
you
define
the
start
of
the
fiscal
year,
this
is
also
the
start
date
of
the
first
quarter,
and
subsequent
quarters
are
configured
to
start
in
regular
three
month
intervals.
For
example,
if
you
specify
the
starting
date
of
your
fiscal
year
as
April
15,
the
subsequent
quarters
are
configured
to
start
on
July
15,
October
15,
and
January
15,
respectively.
Alternatively,
you
can
define
specific
start
dates
for
each
quarter.
You
can
also
restore
the
default
dates
back
to
standard
calendar
quarters,
with
the
fiscal
year
starting
on
January
1.
Note:
If
you
change
the
quarterly
information,
you
need
to
sign
on
to
SLM
Reports
again
for
the
new
quarterly
definitions
to
be
reflected
in
reports.
Reports
that
are
generated
display
the
actual
time
range
generated
by
these
year
and
quarter
definitions.
For
example,
if
the
first
quarter
starts
on
May
1,
then
a
year-to-date
report
is
for
the
period
from
May
1
of
the
previous
year
to
April
30
of
the
current
year.
Figure
13.
Customizing
fiscal
year
and
quarter
start
dates
Chapter
3.
Creating
and
Managing
Schedules
33
Defining
Compatible
Schedules
If
you
want
to
make
changes
to
a
schedule
that
is
associated
with
an
offering,
one
way
to
do
it
is
to
select
a
compatible
schedule
to
replace
the
existing
schedule
that
is
associated
with
the
offering.
A
compatible
schedule
is
a
schedule
that
has
(at
least)
the
same
schedule
states
as
the
original
schedule,
with
the
exception
of
the
No
Service
state.
Each
schedule
state
in
the
original
schedule
might
already
have
breach
values
set
for
each
SLA
that
is
based
on
this
offering,
and
these
schedule
states
and
breach
values
cannot
be
changed
when
you
replace
the
schedule.
You
can
create
a
compatible
schedule
by
using
the
Create
Like
function
under
Manage
Schedules,
creating
a
similar
schedule
to
the
original,
with
the
same
schedule
states.
You
can
then
modify
the
periods
for
each
schedule
state
in
the
compatible
schedule.
You
can
add
new
schedule
states
to
the
compatible
schedule,
but
because
each
schedule
state
in
the
compatible
schedule
is
already
associated
with
defined
breach
values,
but
you
cannot
delete
any
existing
schedule
states
from
the
compatible
schedule,
except
for
periods
in
the
No
Service
state.
The
No
Service
state
is
unique
because
this
state
has
no
breach
values
associated
with
it.
A
schedule
remains
compatible
as
long
as
it
includes
at
least
one
period
for
each
schedule
state
from
the
original
schedule.
When
you
have
completed
making
changes
to
the
compatible
schedule,
it
can
then
be
associated
with
the
changed
offering,
replacing
the
original
schedule.
Adding
a
Period
for
a
Single
Future
Date
In
addition
to
using
the
Create
Like
function
from
the
Manage
Schedules
page
to
create
a
similar
schedule
and,
in
effect,
indirectly
modify
the
schedule
periods
and
schedule
states
that
are
associated
with
an
offering,
you
can
also
use
a
CLI
command
to
add
a
period
to
a
schedule
for
a
single
future
date,
associated
with
a
schedule
state
that
is
already
defined
in
the
schedule.
Using
the
scmd
mem
addSingleScheduleState
command,
you
can
specify
the
schedule
that
you
want
to
affect,
the
start
and
end
hours
for
the
period,
the
single
date
in
the
future
on
which
the
period
is
in
effect,
and
the
associated
schedule
state
(and
its
breach
values)
to
be
applied.
You
might
want
to
add
a
schedule
period
to
your
schedule
for
a
single
future
date
if,
for
example,
you
needed
to
perform
unscheduled
maintenance
and
wanted
to
define
a
specific
No
Service
schedule
state
for
a
particular
date.
You
might
also
want
to
temporarily
modify
the
schedule
for
a
particular
date
to
react
to
some
external
event,
such
as
changing
the
effective
schedule
state
from
Standard
to
Peak
to
provide
a
temporary
higher
level
of
service.
You
must
associate
this
schedule
period
with
a
schedule
state
that
is
already
defined
in
the
schedule
and
associated
with
breach
values,
with
the
exception
of
the
No
Service
schedule
state
which
has
no
associated
breach
values.
If
your
existing
schedule
does
not
include
the
No
Service
state,
you
can
add
that
state
to
the
schedule
by
associating
it
to
the
new
single
date
schedule
period.
As
an
example,
suppose
that
you
have
a
schedule
named
MainSched,
defined
in
an
offering
that
has
the
following
schedule
periods
and
states
defined:
v
Critical
state:
Monday
through
Friday,
13:00
to
15:59
v
Standard
state:
Monday
through
Friday,
07:00
to
12:59
34
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
v
Off
Hours
state:
This
is
set
as
the
default
state,
in
effect
when
no
other
schedule
state
is
in
effect
v
No
Service
state:
Saturdays
from
10:00
to
13:59
for
weekly
planned
maintenance
Now
suppose
that
you
receive
an
announcement
that
the
entire
building
is
scheduled
to
be
powered
down
next
week
on
Tuesday,
April
19,
2005,
for
special
facilities
upgrade
work.
You
need
to
define
a
new
schedule
period
for
the
No
Service
schedule
state
on
that
day.
You
can
do
this
by
issuing
the
following
CLI
command
(after
initializing
the
SLM
environment):
scmd
mem
addSingleSchedulePeriod
-name
MainSched
-date
2005
04
19
-state
7
This
command
specifies
that
the
MainSched
schedule
is
to
be
modified
by
adding
a
new
schedule
period
to
be
in
effect
only
on
April
19,
2005.
Because
no
start
or
end
hours
were
specified,
the
default
values
of
00:00:00
to
23:59:59
are
applied
for
the
entire
day.
The
No
Service
schedule
state
is
associated
to
this
period
by
specifying
the
corresponding
value
of
7
for
the
-state
option.
Note
that
all
schedule
periods
that
are
added
or
removed
are
associated
with
the
time
zone
of
the
SLM
Server.
This
CLI
command
is
described
in
detail
in
the
Command
Reference.
Refer
also
to
the
scmd
mem
removeSingleSchedulePeriod
command
to
remove
these
periods
as
needed.
Managing
Schedules
From
the
Manage
Schedules
page,
you
can
create
new
business
and
auxiliary
schedules,
change
or
delete
existing
schedules
(if
they
have
not
already
been
included
in
an
offering;
check
the
In
Use
column
of
the
Schedules
table),
use
the
Create
Like
function
to
create
a
copy
of
an
existing
schedule
in
the
table
and
modify
it
to
create
a
new
schedule,
or
View
the
contents
of
a
schedule.
When
you
select
a
schedule
from
the
Schedules
table
and
click
View,
you
can
see
the
details
of
the
schedule,
though
you
cannot
change
them
at
this
time.
When
viewing
the
details
of
a
schedule,
you
might
see
an
additional
page
displayed,
showing
any
SLAs
that
are
associated
with
this
schedule
(by
the
process
of
including
the
business
schedule
in
an
offering,
and
then
including
the
offering
in
one
or
more
SLAs).
You
see
this
page
if
either
of
the
following
statements
is
true:
v
You
are
viewing
a
business
schedule
that
is
included
in
an
offering.
v
You
are
viewing
an
auxiliary
schedule
that
is
included
in
a
business
schedule,
which
in
turn
is
included
in
an
offering.
All
SLAs
that
are
associated
with
this
schedule
by
including
the
associated
offering
are
shown
in
the
Associated
SLAs
table.
If
the
schedule
is
included
in
an
offering,
but
the
offering
is
not
yet
included
in
an
SLA,
the
Associated
SLAs
table
is
still
displayed,
but
it
is
empty.
When
you
have
completed
viewing
the
schedule
details,
you
can
click
Change
from
the
Schedules
table
if
you
want
to
change
any
schedule
details.
When
you
select
a
schedule
from
the
Schedules
table,
if
it
is
not
already
included
in
an
offering,
and
if
you
have
the
proper
role
authority
that
permits
you
to
modify
schedules,
you
can
click
Change
and
modify
the
following
schedule
parameters:
v
You
can
rename
the
schedule
to
a
different
name.
Chapter
3.
Creating
and
Managing
Schedules
35
v
You
can
modify
the
text
description
of
the
schedule.
v
You
can
add
auxiliary
schedules
to
a
business
schedule.
v
You
can
delete
auxiliary
schedules
from
a
business
schedule.
v
If
you
have
multiple
auxiliary
schedules
included
in
the
business
schedule,
you
can
move
them
up
or
down
in
the
Included
Auxiliary
Schedules
table.
v
If
you
are
modifying
a
business
schedule,
you
can
select
a
different
schedule
state
as
the
default
state.
v
You
can
add
and
delete
periods,
view
the
details
of
existing
periods,
modify
existing
periods,
and
move
periods
up
and
down
in
the
Periods
table,
to
establish
the
precedence
when
one
or
more
periods
overlap.
v
When
modifying
a
period,
you
can
change
the
schedule
state,
start
and
end
time,
time
zone,
and
repeating
frequency.
v
When
modifying
time
zone
information
for
schedule
periods,
refer
to
“Modifying
Time
Zone
Settings”
on
page
29
for
more
information.
You
cannot
change
the
schedule
type
from
business
schedule
to
auxiliary
schedule,
or
from
auxiliary
schedule
to
business
schedule.
Refer
to
the
Task
Assistant
for
specific
procedures
to
create
and
manage
your
schedules
and
periods.
36
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
4.
Creating
and
Managing
Offerings
This
chapter
describes
the
process
of
creating
and
managing
offerings
by
using
the
SLM
Administration
Console.
An
offering
is
a
template
used
to
describe
a
service,
with
agreed
upon
service
levels,
that
forms
the
basis
for
the
service
level
agreement
(SLA)
in
which
it
is
ultimately
included.
Offerings
can
be
differentiated
to
provide
service
level
choices
to
customers,
such
as
Gold,
Silver,
and
Bronze
services,
or
any
other
naming
convention
that
suggests
a
unique
level
of
service.
An
offering
is
associated
with
a
business
schedule
that
is
defined
with
one
or
more
schedule
periods.
Each
schedule
period
is
associated
with
a
unique
schedule
state,
such
as
peak,
prime,
standard,
off
hours,
and
others,
and
each
of
these
states
can
be
configured
to
represent
a
unique
level
of
service
for
that
schedule
period.
As
a
result,
you
can
offer
a
wide
range
of
service
levels
in
your
offering,
while
also
providing
for
scheduled
outages
for
maintenance
or
other
downtime
activities.
See
Chapter
3,
“Creating
and
Managing
Schedules,”
on
page
19
for
more
information
about
schedules.
For
example,
suppose
that
you
want
to
track
and
manage
page-render
and
back-end
response
times
for
a
department
Web
site
in
your
enterprise,
with
the
following
service
level
objectives
(SLOs)
for
maximum
acceptable
response
times:
Table
2.
Example
of
specifying
faster
response
times
during
peak
periods,
and
less
demanding
response
times
during
non-peak
periods.
Response
time
Peak
Off
Hours
Page-render
5
seconds
10
seconds
Back-end
Processing
15
seconds
20
seconds
With
IBM
Tivoli
Service
Level
Advisor
you
can
define
the
business
schedule
for
peak
hours,
off
hours,
and
other
states,
and
to
define
the
service
level
objectives
for
page-render
and
back-end
processing
response
times,
including
all
of
that
information
in
an
offering.
The
offering
can
then
be
published,
making
it
available
for
inclusion
in
an
SLA
based
on
that
level
of
service.
The
portfolio
contains
three
tasks
related
to
offerings:
v
Create
Offering
is
for
creating
new
offerings.
v
Manage
Offerings
is
for
working
with
existing
offerings.
From
the
Manage
Offerings
page
you
can
also
create
new
offerings,
and
you
can
perform
the
following
additional
tasks:
–
Create
a
new
offering
from
a
copy
of
an
existing
offering.
–
Change
the
contents
of
an
offering.
–
Delete
an
offering.
–
View
the
contents
of
an
offering.
–
Publish
an
offering
that
is
in
the
Draft
state.
–
Withdraw
a
published
offering.v
Replace
Offering
is
a
task
related
to
managing
SLAs.
You
can
replace
an
offering
that
is
included
in
one
or
more
SLAs
with
another
offering.
This
is
discussed
in
more
detail
in
Chapter
7,
“Creating
and
Managing
SLAs,”
on
page
57.
©
Copyright
IBM
Corp.
2002,
2004
37
Creating
Offerings
You
can
create
a
new
offering
by
doing
any
of
the
following
tasks:
v
From
the
portfolio,
select
Create
Offering.
v
From
the
portfolio,
select
Manage
Offerings,
and
then
from
the
Manage
Offerings
page,
click
Create.
v
From
the
Manage
Offerings
page,
select
an
offering
from
the
Offerings
table
and
then
click
Create
Like
to
create
a
copy
of
the
selected
offering,
which
you
can
then
modify
as
needed.
This
method
reduces
the
amount
of
configuring
you
have
to
do
by
enabling
you
to
make
a
few
changes
to
the
copy
and
save
it
as
a
new
offering.
Create
a
new
offering
by
completing
the
following
basic
steps:
v
Enter
a
name
for
the
offering.
This
is
the
name
that
is
displayed
in
the
table
of
available
offerings
when
you
later
include
an
offering
in
an
SLA.
You
should
enter
a
name
that
is
meaningful
to
distinguish
this
offering
from
other
offerings,
perhaps
to
reflect
a
unique
level
of
service.
This
name
is
also
displayed
in
the
Offerings
table
on
the
Manage
Offerings
page,
which
contains
all
defined
offerings.
This
name
is
also
displayed
in
SLM
reports.
v
Optionally
enter
a
text
description
for
the
offering.
This
is
additional
information
that
is
displayed
in
the
Offerings
table
and
helps
describe
the
offering.
This
information
might
make
it
easier
during
the
SLA
creation
process
to
select
the
offering
that
provides
the
preferred
level
of
service
for
that
SLA.
This
description
is
also
displayed
in
SLM
reports.
v
Specify
the
type
of
SLA
for
which
this
offering
is
intended.
Valid
types
are
external,
internal,
and
outsourced.
This
is
discussed
in
more
detail
in
“Selecting
the
SLA
Type”
on
page
39.
v
If
you
specified
an
SLA
Type
of
either
external
or
internal,
you
can
optionally
select
one
or
more
SLAs
to
be
included
in
this
offering.
Later,
when
this
offering
is
itself
included
in
another
SLA,
this
SLA
that
includes
other
SLAs
is
referred
to
as
a
tiered
SLA.
Tiered
SLAs
are
useful
for
representing
service
level
agreements
that
depend
on
other
service
level
agreements
for
their
success.
For
example,
you
might
define
an
outsourced
SLA
between
your
IT
organization
and
an
outside
company
that
provides
core
network
services
to
your
IT
organization.
You
might
then
create
an
offering
that
includes
this
outsourced
SLA
as
part
of
the
level
of
service
that
you
provide
to
your
external
customers.
Later,
when
you
define
an
external
SLA
with
a
customer
that
uses
your
services,
you
associate
this
offering
with
the
external
SLA,
defining
a
dependency
between
the
outsourced
SLA
and
the
external
SLA,
and
creating
a
tiered
SLA
for
the
customer.
If
the
outsourced
SLA
experiences
a
violation,
that
condition
might
cause
a
corresponding
violation
in
the
external
SLA
with
the
customer.
Tiered
SLAs
are
discussed
in
more
detail
in
“Selecting
the
SLA
Type”
on
page
39.
v
Select
a
business
schedule
to
include
in
the
offering.
You
can
select
only
one
business
schedule
from
the
list
of
available
schedules
that
are
shown
in
the
Business
Schedules
table.
You
can
view
the
details
of
a
schedule
before
including
it
by
clicking
the
schedule
name
link
in
the
table.
Business
schedules
contain
one
or
more
schedule
periods,
each
of
which
is
associated
with
a
unique
schedule
state.
A
selected
business
schedule
might
contain
one
or
more
auxiliary
schedules
as
well,
each
of
which
contain
additional
schedule
periods
that
help
define
the
overall
business
operations
schedule.
Later
in
the
offering
creation
process,
you
configure
service
level
objectives
(SLOs)
by
associating
unique
breach
values
to
each
schedule
state
in
the
selected
38
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
schedule.
Be
sure
to
select
the
schedule
that
reflects
your
business
operations.
If
you
do
not
see
an
available
schedule
that
meets
your
needs,
you
can
create
a
new
schedule
and
add
it
to
the
Business
Schedules
table,
and
then
include
it
in
your
offering.
See
Chapter
3,
“Creating
and
Managing
Schedules,”
on
page
19
for
information
about
business
and
auxiliary
schedules.
v
Select
one
or
more
offering
components
to
add
to
the
offering.
This
is
described
in
“Adding
Offering
Components”
on
page
41.
v
For
each
offering
component,
you
can
configure
the
specific
service
level
objectives
that
give
this
offering
a
unique
level
of
service.
See
“Configuring
Service
Level
Objectives”
on
page
43.
v
You
can
save
a
draft
of
the
offering
and
continue
working
on
it
later,
or
you
can
publish
it
and
make
it
available
to
be
included
in
SLAs.
See
“Publishing
the
Offering”
on
page
50
for
details.
Selecting
the
SLA
Type
With
IBM
Tivoli
Service
Level
Advisor
you
can
define
SLAs
across
a
vast
array
of
resources
in
your
enterprise.
Many
of
these
SLAs
are
used
to
manage
levels
of
service
to
your
external
customers.
Other
SLAs
can
be
defined
to
track
the
internal
operation
of
a
resource
in
support
of
these
external
contracts.
In
other
cases,
you
may
be
the
consumer
of
services
from
other
providers,
including
those
that
can
process
SLAs.
To
help
distinguish
between
these
different
types
of
SLAs,
three
types
of
SLAs
are
defined:
External
SLA
Tracks
services
that
you
provide
to
your
external
customers.
Reports
are
available
to
your
customers,
showing
levels
of
service
that
are
being
provided.
In
this
type
of
SLA,
you
are
considered
to
be
the
provider
of
services
for
your
external
customer.
Internal
SLA
Tracks
the
internal
operation
of
your
computing
infrastructure.
Reports
generated
are
for
internal
use
only.
In
this
SLA,
you
are
considered
to
be
the
provider,
while
your
customer
can
also
be
your
own
organization
or
another
internal
group
ultimately
responsible
for
providing
services
to
an
external
customer.
Use
an
internal
SLA
to
monitor
your
own
internal
operations,
enabling
you
to
provide
services
to
your
external
customers
on
a
more
reliable
basis.
Outsourced
SLA
Tracks
services
provided
to
you
by
a
third
party.
For
this
type
of
SLA,
you
are
considered
to
be
the
customer,
not
the
provider.
You
might
want
to
define
an
outsourced
SLA
to
monitor
critical
services
that
are
provided
to
your
organization,
core
services
for
your
environment
that
you
use
to
provide
your
services
to
your
external
customers.
While
SLAs
can
be
created
to
support
one
of
these
types,
SLAs
are
increasingly
becoming
more
oriented
toward
end-to-end
and
structured
agreements,
with
a
single
SLA
made
up
of
internal,
external,
and
outsourced
layers.
For
example,
consider
the
environment
depicted
in
Figure
14
on
page
40.
Company
Y
provides
a
Web
hosting
service
for
Company
Z
that
includes
a
point-of-presence
(represented
by
the
circle),
Web
servers
(A,
B,
and
C),
and
a
back-end
database.
The
database
is
located
at
a
remote
site
(where
coordinated
backup
can
occur)
and
is
accessed
through
a
backbone
network
provided
by
Company
X.
Chapter
4.
Creating
and
Managing
Offerings
39
An
external
SLA
is
depicted
that
represents
Company
Z’s
access
to
the
entire
Web
hosting
service.
Within
Company
Y,
there
are
internal
SLAs
to
track
network
connectivity
between
the
point-of-presence
and
the
Web
servers,
and
to
track
the
availability
of
the
back-end
database.
Also
pictured
is
the
SLA
provided
by
Company
X,
that
assures
proper
operation
to
the
backbone
network
(for
which
Company
Y
is
a
consumer).
The
SLA
drawn
as
a
dotted
line
tracks
Company
Y’s
view
of
the
backbone
network,
and
serves
as
a
way
of
checking
the
consumed
SLA
from
Company
X.
This
is
the
outsourced
SLA.
You
might
have
internal
elements
of
your
enterprise
for
which
you
need
to
guarantee
service,
as
well
as
third
party
(outsourced)
providers
that
you
depend
on
to
provide
levels
of
service
to
your
customer
(external).
You
must
ensure
that
internal
objectives
can
be
met,
from
which
you
offer
external
guarantees
to
your
customers.
This
reliance
of
external
SLAs
on
internal
SLAs
(which
in
turn
might
be
dependent
on
outsourced
SLAs)
is
the
key
to
delivering
true
end-to-end
service
level
agreements.
Use
this
tiered
SLA
feature
of
IBM
Tivoli
Service
Level
Advisor
to
track
internal
objectives
against
external
commitments
that
depend
on
them.
When
you
initially
create
an
offering,
you
specify
the
type
of
SLA
for
which
this
offering
is
intended.
After
an
offering
is
published
and
included
in
an
SLA,
this
SLA
is
deployed
as
an
internal,
external,
or
outsourced
SLA,
depending
on
the
type
of
SLA
you
selected.
When
you
create
an
offering,
you
have
the
option
of
including
one
or
more
previously
deployed
SLAs
in
the
offering.
When
this
offering
is
then
included
in
a
new
SLA,
that
SLA
within
an
SLA
relationship
is
known
as
a
tiered
SLA,
which
provides
a
true
end-to-end
representation
of
the
overall
service
level
agreement.
Figure
14.
Showing
the
tiered
nature
of
internal,
external,
and
outsourced
SLAs.
40
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
When
you
create
a
tiered
SLA,
consider
the
following
information:
v
Offerings
defined
with
an
External
SLA
type
can
include
any
number
of
external,
internal,
or
outsourced
SLAs.
v
Offerings
defined
with
an
Internal
SLA
type
can
include
any
number
of
internal
or
outsourced
SLAs
(but
no
external
SLAs).
v
Offerings
defined
with
an
Outsourced
SLA
type
cannot
include
any
SLAs.
v
When
you
are
creating
several
SLAs
of
varying
types,
you
should
create
outsourced
SLAs
first,
followed
by
internal
SLAs
(which
might
be
associated
with
previously
created
internal
or
outsourced
SLAs),
and
then
by
external
SLAs
(which
might
be
associated
with
any
previously
created
SLA).
Adding
previously
deployed
SLAs
to
this
offering
is
accomplished
using
the
Include
SLAs
page
during
the
Create
Offering
process.
You
can
add
available
SLAs
to
the
Included
SLAs
table
to
include
them
in
your
offering.
See
the
Task
Assistant
for
details
on
selecting
previously
deployed
SLAs
for
inclusion
in
your
offering.
Adding
Offering
Components
The
Tivoli
Data
Warehouse
database
includes
many
different
types
of
monitoring
data.
Selecting
the
measurement
criteria
to
include
in
your
offering
is
made
easier
in
IBM
Tivoli
Service
Level
Advisor
by
selectively
narrowing
down
the
list
of
possible
offering
components,
filtering
on
multiple
levels
of
resource
types,
and,
where
necessary,
the
source
application
from
which
the
measurement
originated.
An
offering
component
is
a
collection
of
metrics
and
breach
values
that
defines
the
service
level
objectives
for
a
particular
resource
type.
For
each
resource
type
that
you
want
to
include
in
an
offering,
you
create
an
offering
component,
which
involves
completing
the
following
steps:
v
Select
the
resource
type
from
the
list
of
available
resource
types
in
the
SLM
Database.
v
Select
one
or
more
metrics
that
are
applicable
for
the
selected
resource
type.
v
For
each
metric
that
you
select,
configure
breach
values
for
each
schedule
state
in
the
associated
business
schedule
that
was
included
in
the
overall
offering.
You
can
also
configure
the
frequency
of
when
evaluations
are
performed
on
each
metric,
as
well
as
other
advanced
settings
such
as
enabling
intermediate
evaluations,
configuring
trend
analysis
frequency,
or
enabling
logging
of
missing
data
points.
During
the
Create
Offering
process
the
Include
Offering
Components
page
is
displayed,
which
shows
the
Included
Offering
Components
table.
When
you
first
create
a
new
offering,
this
table
is
empty.
You
must
add
and
configure
one
or
more
offering
components
for
this
offering,
which
are
then
listed
in
this
table.
All
of
the
offering
components
that
you
add
to
this
table
are
included
in
the
published
offering.
Click
Add
to
add
a
new
offering
component
to
the
Included
Offering
Components
table.
For
example,
consider
the
requirement
to
create
an
offering
for
a
Web
application,
where
the
customer
is
interested
in
the
following
metrics,
as
shown
in
Table
3
on
page
42:
Chapter
4.
Creating
and
Managing
Offerings
41
Table
3.
Customer
metrics
for
a
Web
application
Metric
Breach
Values
Peak
Off
Hours
Page
Render
Response
Time
Minimum
0.100
seconds
0.100
seconds
Maximum
0.200
seconds
0.300
seconds
Average
0.140
seconds
0.200
seconds
Backend
Service
Response
Time
Minimum
0.015
seconds
0.015
seconds
Maximum
0.050
seconds
0.075
seconds
Average
0.025
seconds
0.050
seconds
Percent
of
Transaction
Success
for
Page
Render
Time
Minimum
95%
90%
Maximum
100%
100%
Average
97%
95%
This
table
is
referred
to
in
the
sections
that
follow.
Selecting
the
Resource
Type
Using
the
Select
Resource
Type
page,
you
can
refine
the
selection
list
of
available
offering
components
by
selecting
one
of
the
resource
types
from
the
selection
tree
that
is
displayed.
The
resource
type
specifies
the
type
of
enterprise
resource
against
which
the
SLO
is
applied.
Examples
of
resource
types
include
firewalls,
servers,
ports,
routers,
and
endpoints.
Selecting
one
of
these
parent
resource
types
expands
the
tree
view
to
display
available
child
resource
types
that
help
you
to
narrow
the
selection
further.
Depending
on
the
resource
type
that
you
selected
from
the
Resource
Type
Tree
in
the
previous
section,
there
might
be
measurements
in
the
Tivoli
Data
Warehouse
database
for
that
resource
type
that
come
from
more
than
one
measurement
source.
The
measurement
source
specifies
the
source
application
from
which
the
measurement
first
originated.
This
information
is
kept
in
the
SLM
Database,
which
is
checked
for
each
resource
type
you
select.
If
it
is
determined
that
the
selected
resource
type
has
measurements
in
the
database
from
more
than
one
measurement
source,
you
can
further
refine
your
search
to
only
select
from
resource
types
that
come
from
a
specific
measurement
source.
Because
the
Tivoli
Data
Warehouse
database
contains
measurements
from
multiple
performance
and
availability
monitoring
applications,
you
select
a
measurement
source
to
reduce
the
list
of
available
metrics
to
just
those
originating
from
that
source
application.
For
our
example
in
Table
3,
we
want
resource
types
for
Tivoli
Web
Transaction
Performance
Endpoints.
Selecting
this
resource
type
in
the
Resource
Type
Tree
displays
the
available
resource
types
in
the
Available
Resource
Types
table.
Select
the
Tivoli
Web
Transaction
Performance
Transaction
Node
resource
type,
and
click
Next
to
continue.
Including
Metrics
After
you
have
narrowed
your
list
of
available
offering
components
by
resource
type,
you
can
select
the
metrics
to
be
added
to
the
offering
component.
The
Include
Metrics
page
is
displayed,
and
for
a
new
offering
the
Included
Metrics
table
is
initially
empty.
You
can
click
Add
to
display
a
Metrics
table,
containing
a
list
of
the
available
metrics
that
are
associated
with
your
selected
resource
type.
42
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
You
can
only
select
one
metric
at
a
time,
and
you
must
configure
the
metric
and
add
it
to
the
Included
Metrics
table
before
selecting
additional
metrics.
Note
that
you
are
not
creating
new
metrics,
but
are
selecting
from
existing
metrics
to
add
to
the
offering.
For
our
example,
the
following
available
metrics
are
related
to
the
Tivoli
Web
Transaction
Performance
Transaction
Node
resource
type:
v
Page
Render
Time
v
Round
Trip
Time
v
Service
Time
(Backend
Service
Response
Time)
v
Transaction
Success
for
Page
Render
Time
v
Transaction
Success
for
Round
Trip
Time
v
Transaction
Success
for
Service
Time
For
this
example,
from
the
Metrics
table,
select
the
Page
Render
Time
metric,
and
then
proceed
on
to
configure
the
service
level
objectives
for
this
metric.
Configuring
Service
Level
Objectives
Configuring
the
service
level
objectives
for
each
metric
to
be
added
to
the
offering
component
includes
doing
the
following
tasks:
v
Define
breach
values
for
at
least
one
schedule
state
(except
for
the
No
Service
state,
which
does
not
have
breach
values)
in
the
included
business
schedule.
v
Configure
the
frequency
at
which
you
want
IBM
Tivoli
Service
Level
Advisor
to
evaluate
this
metric.
v
Optionally
configure
advanced
settings.
After
you
finish
configuring
the
service
level
objectives
for
the
selected
metric,
you
are
returned
to
the
Included
Metrics
table.
Click
Add
to
select
another
available
metric,
and
repeat
the
steps
to
configure
the
service
level
objectives
for
this
and
additional
metrics
as
needed.
When
you
have
finished
configuring
all
of
the
metrics,
you
are
prompted
for
the
name
and
optional
description
to
be
given
to
this
offering
component.
This
name
is
displayed
during
the
SLA
creation
process
for
further
customization.
When
you
finish
creating
this
offering
component,
you
return
to
the
Include
Offering
Components
page,
where
the
offering
components
you
created
are
displayed
in
the
Included
Offering
Components
table.
You
can
continue
to
create
new
offering
components
to
be
added
to
this
offering,
following
the
same
process
of
filtering
on
component
types
and
measurement
sources
and
configuring
selected
metrics.
Defining
Breach
Values
After
you
select
a
metric
for
your
offering
component,
the
Define
Breach
Values
page
is
displayed.
It
shows
the
Breach
Values
table
and
the
expected
input
fields
for
you
to
enter
breach
values
for
each
unique
schedule
state
in
the
business
schedule.
Here
is
where
you
associate
specific
breach
values
that
distinguish
one
schedule
state
from
another.
Note
that
schedule
states
from
any
auxiliary
schedules
that
are
part
of
the
overall
business
schedule
are
also
represented
in
the
Breach
Values
table.
Specify
the
breach
values
for
each
metric,
which
might
include
minimum,
maximum,
average,
or
total
values
that
correspond
with
the
aggregated
data
coming
from
the
Tivoli
Data
Warehouse,
for
peak,
prime,
standard,
and
other
Chapter
4.
Creating
and
Managing
Offerings
43
schedule
state
periods.
The
raw
measurement
data
that
originates
from
the
source
applications
is
stored
as
summarized
data
in
the
Tivoli
Data
Warehouse
and
stored
as
an
aggregate
quantity
for
that
collection
period.
For
example,
raw
measurements
that
are
taken
by
the
source
application
at
a
frequency
of
once
every
hour
might
be
summarized
in
the
data
warehouse
on
a
daily
basis,
and
stored
as
one
data
point
containing
the
minimum,
maximum,
and
average
or
total
values
during
that
24-hour
period.
Some
metrics
have
minimum,
maximum
and
average
values,
while
others
might
only
include
a
single
(total)
value.
This
aggregated
data
is
evaluated
against
the
appropriate
breach
values
defined
for
peak
and
other
periods
to
determine
if
service
levels
are
being
maintained.
The
breach
value
entered
for
total
is
compared
to
the
sum
of
all
hourly
values
reported
over
the
entire
evaluation
period
(for
example,
day
or
week).
The
breach
value
entered
for
average
is
compared
to
the
average
of
all
hourly
values
reported
over
the
entire
evaluation
period
(for
example,
day
or
week).
The
breach
value
for
minimum
or
maximum
is
compared
to
the
lowest
or
highest
single
hourly
value
reported
during
the
evaluation
period.
For
our
example,
the
values
from
Table
3
on
page
42
are
entered
for
the
Page-Render
Time
metric,
specifying
the
minimum,
maximum,
and
average
values.
An
additional
field,
Violation
Condition,
is
set
to
detect
a
violation
if
the
actual
average
is
greater
than
the
supplied
average.
Configuring
SLO
Evaluation
Frequency
After
defining
the
breach
values
for
each
schedule
state
in
the
business
schedule,
configure
the
SLO
evaluation
frequency
for
the
metric
by
doing
the
following
tasks:
v
Indicate
whether
or
not
these
metrics
should
be
considered
for
internal
use
only.
There
might
be
metrics
that
you
wish
to
reserve
for
internal
use
only
and
not
show
them
on
external
reports
to
the
customer.
Selecting
the
Internal
use
only
box
causes
the
results
data
associated
with
this
metric
to
be
excluded
from
reports
accessed
by
users
with
external
view
authority.
By
default
this
box
is
cleared
to
include
this
metric
in
external
customer
reports.
See
the
Administrator’s
Guide
and
SLM
Reports
documents
for
related
information
on
authorizing
users
to
view
results
data
in
reports.
v
Specify
the
frequency
for
the
service
level
objective
(SLO)
evaluation.
This
specifies
how
often
the
measurement
data
associated
with
this
service
level
objective
is
evaluated
to
assure
the
level
of
service.
You
can
select
a
frequency
of
Daily,
Weekly,
or
Monthly
evaluations.
Most
typical
source
applications
write
measurement
data
to
the
Tivoli
Data
Warehouse
database
as
often
as
once
per
day.
You
might
also
have
one
or
more
source
applications
that
write
measurement
data
more
than
once
per
day,
for
example,
every
hour,
or
every
four
hours.
In
this
case,
if
your
SLM
Administrator
has
enabled
additional
evaluation
frequencies
to
perform
evaluations
more
than
once
per
day,
you
see
the
following
additional
frequency
options:
–
Every
Hour
–
Every
Two
Hours
–
Every
Three
Hours
–
Every
Four
Hours
–
Every
Six
Hours
–
Every
Eight
Hours
–
Every
Twelve
Hours
44
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
You
should
consult
with
your
SLM
Administrator
to
verify
that
the
measurement
data
in
which
you
are
interested
is
being
written
to
the
central
data
warehouse
at
the
preferred
frequency,
and
that
the
Process
ETL
is
scheduled
to
run
at
the
preferred
frequency.
Configuring
SLO
Evaluation
frequency:
Be
sure
to
configure
SLO
evaluation
frequency
equal
to
or
greater
than
the
frequency
at
which
measurement
data
is
written
to
Tivoli
Data
Warehouse
by
the
source
ETL,
otherwise
the
evaluation
results
are
not
useful.
For
example,
if
your
source
ETL
is
writing
data
once
per
day
to
the
central
data
warehouse,
configure
your
SLO
evaluation
frequency
for
daily,
weekly,
or
monthly
evaluations,
but
not
hourly.
Do
the
following
steps
if
you
need
to
enable
additional
evaluation
frequencies:
1.
If
you
are
currently
in
the
process
of
creating
an
offering
and
are
attempting
to
add
a
new
metric,
click
Cancel
to
cancel
this
operation
and
return
to
the
Include
Metrics
page.
2.
On
the
computer
where
the
SLM
Server
is
located,
open
a
command
prompt
window,
and
navigate
to
<TSLA_Dir>,
the
directory
where
IBM
Tivoli
Service
Level
Advisor
was
installed
(for
example,
C:\TSLA)
3.
Initialize
the
CLI
command
environment
by
issuing
the
following
command:
slmenv
4.
Issue
the
following
command
to
enable
additional
evaluation
frequency
settings:
scmd
mem
showHourlyFrequencyIntervals
enable
See
the
Command
Reference
document
for
additional
information
about
this
and
other
CLI
commands.
5.
Return
to
the
SLM
Administrative
Console
and
click
Add
to
restart
the
Include
Metrics
process.
When
you
return
to
the
Evaluation
Frequency
selection,
you
see
the
additional
frequency
selections.
6.
Select
the
evaluation
frequency
and
then
continue
as
usual
to
complete
the
offering
creation
process.
If
you
select
an
evaluation
frequency
to
have
evaluations
occur
more
than
once
per
day,
you
cannot
perform
intermediate
evaluations.
See
“Configuring
Advanced
Metric
Settings”
on
page
46
for
more
information.
The
actual
evaluation
takes
place
automatically
when
the
Process
ETL
completes
its
operations
of
moving
the
most
recent
measurement
data
from
the
data
warehouse
into
the
SLM
Measurement
Data
Mart,
on
a
day
when
the
daily,
weekly,
or
monthly
frequency
interval
is
met
(or,
in
the
case
of
any
of
the
hourly
evaluations,
on
the
hourly
frequency).
As
you
select
the
evaluation
frequency,
keep
in
mind
how
evaluations
are
performed
with
respect
to
how
your
business
schedules
and
periods
are
defined.
For
example,
consider
a
business
schedule
with
a
period
defined
between
the
hours
of
09:00
and
13:00.
If
you
specify
evaluations
to
occur
every
four
hours,
the
actual
evaluations
occurs
for
the
following
intervals
in
a
single
day:
–
00:00
to
03:59
–
04:00
to
07:59
–
08:00
to
11:59
–
12:00
to
15:59
–
16:00
to
19:59
–
20:00
to
23:59
If
a
violation
occurs
in
the
defined
business
schedule
period
and
exists
for
the
entire
4
hours
between
09:00
and
13:00,
the
violation
is
reported
twice:
the
first
time
during
the
evaluation
of
08:00
to
11:59,
and
the
second
time
during
the
Chapter
4.
Creating
and
Managing
Offerings
45
evaluation
of
12:00
to
15:59.
You
might
want
to
modify
your
business
schedule
period
definitions
or
select
a
different
evaluation
frequency.
Configuring
Advanced
Metric
Settings
In
addition
to
defining
the
breach
values
and
specifying
the
SLO
evaluation
frequency,
you
can
optionally
configure
some
additional
parameters
by
selecting
the
Configure
advanced
metric
settings
check
box.
The
Advanced
Metric
Settings
page
is
displayed,
and
you
can
configure
the
following
advanced
settings:
v
Intermediate
Evaluations
v
Frequency
of
Trend
Analysis
v
Logging
messages
for
missing
data
Intermediate
Evaluations:
Part
of
the
standard
process
for
configuring
service
level
objectives
includes
specifying
the
frequency
at
which
SLO
evaluations
are
performed
(see
“Configuring
SLO
Evaluation
Frequency”
on
page
44).
Depending
on
the
SLO
evaluation
frequency
that
you
specified,
you
might
also
be
able
to
obtain
intermediate
evaluations,
multiple
additional
evaluations
that
occur
during
the
SLO
evaluation
period.
For
example,
if
you
specified
an
SLO
evaluation
frequency
of
Monthly,
on
the
day
of
the
month
when
the
SLO
evaluation
interval
expires,
the
SLO
evaluation
is
performed.
During
that
month,
you
could
also
enable
intermediate
evaluations
to
occur
on
a
daily
basis
(or,
in
some
cases,
on
an
hourly
basis
if
hourly
frequencies
are
enabled),
and
be
able
to
view
daily
(or
hourly)
information
in
reports,
in
addition
to
the
report
at
the
end
of
the
month
when
the
SLO
evaluation
is
performed.
In
the
Advanced
Metric
Settings
page,
the
option
to
enable
intermediate
evaluations
and
the
available
frequency
selections
are
defined
in
Table
4.
Table
4.
Conditions
for
intermediate
evaluations
SLO
evaluation
frequency
setting
Hourly
evaluations
Available
choices
for
intermediate
evaluation
frequency
Comments
Monthly
Enabled
Daily
or
Every
Hour
Weekly
intermediate
evaluations
are
not
allowed
because
weeks
do
not
always
end
on
a
month-end
boundary
Not
enabled
Daily
Weekly
Enabled
Daily
or
Every
Hour
Not
enabled
Daily
Daily
Enabled
Hourly
Not
enabled
Not
Available
Hourly
(meaning
any
of
the
available
hourly
frequency
selections)
Enabled
Not
Available
The
intermediate
evaluation
frequency
is
not
supported
for
SLO
evaluation
frequencies
of
more
than
once
daily.
Not
enabled
Not
Available
It
is
important
to
note
that
intermediate
evaluations
are
only
performed
on
completed
evaluation
intervals.
For
example,
suppose
you
have
configured
SLO
evaluations
to
occur
monthly,
and
have
enabled
intermediate
evaluations
to
occur
46
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
on
a
daily
frequency.
Suppose
also
that
the
Process
ETL
is
scheduled
to
move
measurement
data
from
Tivoli
Data
Warehouse
to
the
SLM
Measurement
Data
Mart
every
day
at
14:00.
On
the
fourth
day
of
the
month,
when
the
Process
ETL
has
completed,
intermediate
evaluations
are
performed
only
on
measurement
data
for
the
first
three
(complete)
days.
Measurements
that
were
collected
for
the
fourth
(current)
day
up
to
14:00
are
not
evaluated,
because
the
fourth
day
has
not
yet
completed.
Measurements
obtained
during
the
fourth
day
is
evaluated
after
the
Process
ETL
runs
again
at
14:00
on
the
fifth
(next)
day
of
the
month.
Because
intermediate
evaluations
are
performed
many
more
times
than
typical
SLO
evaluations,
you
might
experience
degraded
performance
of
the
SLM
Server
when
intermediate
evaluations
are
enabled.
Results
of
intermediate
evaluations
are
available
in
SLM
reports,
but
violations
are
not
detected
as
a
result
of
intermediate
evaluations,
and
are
therefore
not
escalated
through
the
configured
escalation
channels.
Trends,
however,
are
detected
and
are
escalated
as
a
result
of
intermediate
evaluations.
See
SLM
Reports
for
more
information
about
results
from
intermediate
evaluations
in
reports.
Trend
Analysis:
This
specifies
how
often
the
service
level
objective
measurement
data
is
analyzed
for
trends
that
might
indicate
a
service
level
violation
is
imminent.
This
analysis
takes
place
automatically
when
the
Process
ETL
completes
its
operations
of
moving
the
most
recent
measurement
data
from
the
data
warehouse
into
the
SLM
Measurement
Data
Mart,
on
a
day
when
the
daily,
weekly,
or
monthly
frequency
interval
(or
hourly
frequency
interval,
if
enabled)
is
met.
Note
that
trend
analysis
can
occur
at
a
different
frequency
than
SLO
evaluations.
If
you
enabled
intermediate
evaluations,
you
cannot
select
the
frequency
for
SLO
trend
analysis.
The
frequency
for
SLO
trend
analysis
is
automatically
set
to
the
same
frequency
as
for
intermediate
evaluations.
If
the
SLO
evaluation
frequency
and
the
trend
analysis
frequency
settings
are
not
the
same,
you
can
also
select
one
of
the
following
options
for
performing
trend
analysis:
v
Continuous
trend
evaluation,
which
is
the
default
setting,
and
is
used
for
historical
trending
across
multiple
SLO
evaluation
intervals.
The
trend
evaluation
period
is
based
solely
on
the
specified
trend
frequency
(for
example,
with
a
daily
trend
frequency,
the
third
day
of
the
month
is
evaluated
from
00:00
to
23:59
on
that
day).
Results
of
each
trend
evaluation
are
added
to
the
trend
summary
and
continue
into
subsequent
SLO
evaluation
intervals.
You
can
obtain
trending
information
across
multiple
days
or
months,
for
example,
when
you
have
SLO
evaluations
occurring
on
a
monthly
basis.
v
Current
evaluation
period
only,
which
causes
the
trend
evaluation
results
to
be
reset
at
the
completion
of
each
SLO
evaluation
interval.
The
trend
evaluation
period
is
based
on
the
trend
frequency
chosen
and
the
SLO
evaluation
period.
Each
trend
evaluation
period
occurs
from
the
start
of
the
SLO
evaluation
period
to
the
end
of
the
most
recent
trend
evaluation
period
(for
example,
if
you
have
a
monthly
SLO
evaluation
period
with
a
daily
trend
frequency,
the
third
day
of
the
month
evaluates
from
00:00
on
Day
1
(the
start
of
the
monthly
SLO
evaluation
period)
to
23:59
on
Day
3
(the
end
of
the
most
recent,
or
current,
trend
evaluation
period).
If
the
SLO
evaluation
frequency
and
the
trend
analysis
frequency
are
the
same,
this
option
is
not
available,
and
only
continuous
trend
evaluation
is
performed.
Chapter
4.
Creating
and
Managing
Offerings
47
Because
trends
are
reset
for
each
new
evaluation
period,
and
because
a
trend
needs
at
least
30
data
points
before
an
analysis
can
be
performed,
be
careful
not
to
specify
the
duration
of
schedule
periods
so
short
that
a
trend
is
prevented
from
ever
being
detected.
Offerings
that
specify
the
Current
evaluation
period
only
option
with
weekly
evaluations
should
include
schedules
whose
periods
are
at
least
8
hours
or
greater.
For
example,
suppose
you
define
a
4
hour
schedule
period,
from
10:00
to
14:00,
and
the
source
ETL
sets
a
sample
count
of
1
for
each
hourly
data
point.
An
SLA
with
a
weekly
evaluation
using
the
Current
evaluation
period
only
option
can
never
have
a
trend
issued
against
it
because
the
maximum
number
of
data
points
is
28
(4
data
points
per
day
for
7
days).
This
is
not
a
problem
for
the
Continuous
trend
evaluation
option
because
the
trend
is
not
reset
for
the
next
week,
and
data
points
from
day
8
would
provide
more
than
the
minimum
30
points
needed
for
trend
analysis.
Missing
Data:
You
might
have
certain
source
applications
that
collect
hourly
polling
data
to
verify
availability
of
a
resource,
or
you
might
have
certain
monitoring
source
applications
that
collect
hourly
response
time
data.
For
these
situations,
you
expect
the
measurement
data
that
is
obtained
from
the
warehouse
database
to
contain
a
data
point
for
each
hourly
interval,
except
for
No
Service
times,
as
governed
by
the
business
schedule.
Typically
other
source
applications
might
provide
measurement
data
only
once
per
day,
or
combine
multiple
daily
measurements
into
a
single
data
point
that
is
written
to
the
warehouse
to
represent
the
results
for
that
day.
The
database
might
have
many
hourly
intervals
where
no
data
point
is
expected.
If
you
set
the
SLO
evaluation
frequency
to
be
less
frequent
than
Every
Hour,
and
the
metric
is
of
an
appropriate
type,
then
the
Missing
Data
checkbox
is
displayed
on
the
Advanced
Metric
Settings
page.
To
distinguish
between
the
cases
where
missing
data
is
an
error
condition
instead
of
an
expected
occurrence,
select
the
Missing
Data
check
box.
This
indicates
to
IBM
Tivoli
Service
Level
Advisor
that
when
evaluations
are
performed,
any
in-service
hour
without
a
data
point
should
be
reported
as
missing
data,
and
logged
as
an
error
condition
in
the
message
log.
Note:
This
checkbox
is
displayed
on
this
page
only
if
it
is
appropriate
for
the
selected
metric
and
evaluation
frequency.
In
the
case
where
data
points
from
multiple
resources
are
being
reported,
such
as
when
a
dynamic
or
static
resource
list
is
used,
if
one
or
more
resources
report
multiple
data
points
in
the
same
hour,
they
are
combined
into
a
single
data
point.
As
long
as
at
least
one
resource
reports
data,
the
hour
is
considered
to
have
data.
Only
if
no
resources
report
any
data
for
a
given
hour
is
that
hour
considered
to
have
a
missing
data
condition.
When
missing
data
is
considered
to
be
an
error
condition,
it
is
most
likely
being
caused
by
an
incorrect
ETL
process.
You
should
consult
the
message
log
for
details
on
the
missing
data,
and
verify
that
the
source
application
ETL
is
correctly
writing
expected
data
into
the
warehouse
database.
The
message
log
contains
detailed
information
on
every
missing
data
point,
and
the
most
recent
message
contains
the
most
recent
updated
information.
Considerations
for
Specifying
the
Frequency
of
Evaluations
and
Trend
Analyses
The
time
at
which
the
Process
ETL
runs
is
not
under
the
control
of
IBM
Tivoli
Service
Level
Advisor.
This
time
is
separately
scheduled
in
the
Data
Warehouse
48
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Center
of
the
Tivoli
Data
Warehouse
control
server,
typically
managed
by
a
warehouse
administrator.
The
following
general
sequence
of
events
must
occur
for
successful
data
collection
and
transfer:
1.
Source
applications
complete
their
collection
of
measurement
data
for
the
day.
Typically
this
might
occur
right
up
until
23:59
for
that
day.
2.
At
any
time
after
the
source
applications
complete
their
data
collection
(typically
after
00:00
of
the
next
day),
the
corresponding
source
ETLs
are
then
run
according
to
their
scheduled
start
times,
to
write
the
collected
data
to
Tivoli
Data
Warehouse.
Time
should
be
allowed
for
the
source
ETLs
to
complete
their
processing
and
write
all
collected
data
to
Tivoli
Data
Warehouse
before
running
the
Process
ETL.
3.
After
the
source
ETLs
have
completed
their
processing,
the
Process
ETL
for
IBM
Tivoli
Service
Level
Advisor
is
run
according
to
its
scheduled
start
time
to
transfer
data
from
the
central
data
warehouse
into
the
SLM
Measurement
Data
Mart.
The
warehouse
administrator
should
determine
how
long
it
takes
for
the
source
ETLs
to
complete
processing
and
schedule
the
Process
ETL
accordingly.
4.
After
the
Process
ETL
completes
the
transfer
of
data
to
IBM
Tivoli
Service
Level
Advisor,
evaluation
and
trend
analysis
are
started
automatically
on
the
day
when
the
daily,
weekly,
or
monthly
interval
is
reached
(or,
for
hourly
SLO
evaluations,
after
the
hourly
interval
completes).
When
specifying
the
frequency
for
when
your
metric
data
is
evaluated,
consider
the
following
information:
v
Information
can
be
loaded
into
the
Tivoli
Data
Warehouse
database
on
schedules
that
make
sense
for
the
source
applications
producing
the
data.
Target
applications,
such
as
IBM
Tivoli
Service
Level
Advisor,
are
free
to
extract
the
data
(possibly
multiple
times)
as
needed
to
perform
their
analysis.
v
IBM
Tivoli
Service
Level
Advisor
cannot
directly
access
data
from
the
Tivoli
Data
Warehouse
database.
The
Registration
ETL
and
Process
ETL
handle
moving
the
data
from
the
data
warehouse
to
the
IBM
Tivoli
Service
Level
Advisor
databases
on
independent
schedules
designed
to
alleviate
contention
over
the
data
warehouse.
v
The
Registration
ETL
is
typically
run
when
IBM
Tivoli
Service
Level
Advisor
is
first
installed,
on
demand
when
the
source
application
filtering
criteria
changes
(see
the
Administrator’s
Guide
document
for
more
information
on
enabling
data
collection
for
specific
applications),
or
on
a
schedule
set
by
the
warehouse
administrator.
v
The
SLM
Measurement
Data
Mart
serves
as
the
data
source
for
the
evaluation
and
reporting
of
SLA
conformance.
It
is
loaded
by
the
Process
ETL,
which
is
run
either
explicitly
or
on
a
schedule
maintained
by
the
warehouse
administrator.
Typically
the
Process
ETL
is
run
once
per
day
during
off
hours,
but
might
be
scheduled
to
run
more
often
than
once
per
day
if
hourly
evaluations
are
to
be
performed.
To
obtain
the
earliest
possible
notification
of
violations
or
trends,
the
Process
ETL
should
be
scheduled
to
run
after
midnight
on
the
preferred
day,
or,
for
hourly
SLO
evaluation
frequencies,
soon
after
the
completion
of
the
SLO
evaluation
interval.
v
In
any
environment,
but
especially
global
environments
that
span
time
zones,
you
must
make
sure
that
the
IBM
Tivoli
Service
Level
Advisor
Process
ETL
(that
is,
the
ETL
process
that
loads
data
into
the
SLM
Measurement
Data
Mart)
is
scheduled
to
run
after
all
source
application
ETLs
(that
is,
those
ETLs
that
can
Chapter
4.
Creating
and
Managing
Offerings
49
load
data
that
is
to
be
evaluated
over
a
certain
24-hour
period)
have
completed
their
processing.
If
your
installation
spans
multiple
time
zones,
consider
the
following
issues:
–
Some
source
application
ETLs
only
roll
up
data
for
completed
24
hour
days.
For
example,
if
this
type
of
source
ETL
is
run
at
06:00
on
the
15th
of
the
month,
it
only
rolls
up
data
through
midnight
of
the
previous
day.
Running
the
ETL
a
second
time
later
on
the
same
day
does
not
roll
up
any
additional
data
for
that
application.
This
type
of
source
ETL
must
run
in
the
same
time
zone
or
a
later
time
zone
than
the
time
zone
of
the
SLA.
–
Because
your
SLM
Server
is
installed
in
a
particular
time
zone,
when
it
runs
its
evaluation
at
midnight
it
might
miss
data
that
is
loaded
by
source
ETLs
in
time
zones
where
midnight
has
not
yet
occurred.
For
example,
suppose
your
SLM
Server
is
installed
in
New
York
(Eastern
time
zone),
but
you
have
applications
in
California
that
load
data
into
the
central
data
warehouse
at
midnight
(Pacific
time
zone,
three
hours
later).
If
IBM
Tivoli
Service
Level
Advisor
evaluates
SLAs
at
midnight
Eastern
time,
it
does
not
include
the
data
loaded
from
the
applications
in
the
Pacific
time
zone.
To
resolve
this
problem,
run
the
Process
ETL
in
New
York
(for
example,
at
04:00
EST,
or
01:00
Pacific
time)
after
the
source
ETLs
run
in
California
at
midnight
Pacific
time.v
For
weekly
evaluations,
the
start
of
the
week
can
occur
on
a
Saturday,
Sunday,
or
Monday,
depending
on
the
locale
(not
the
time
zone)
of
the
SLM
Server.
v
If
you
specify
an
evaluation
frequency
of
more
often
than
once
per
day
(for
example,
hourly,
or
every
2,
3,
4,
6,
8,
or
12
hours),
you
cannot
select
the
Advanced
Metric
Setting
to
perform
intermediate
evaluations.
v
If
you
have
a
variety
of
source
applications
that
are
writing
measurement
data
to
the
central
data
warehouse
on
different
intervals,
you
need
to
be
careful
when
scheduling
the
target
Registration
and
Process
ETLs.
For
example,
suppose
you
have
two
source
applications,
one
that
writes
data
to
the
central
data
warehouse
once
per
day,
and
the
other
that
writes
data
to
the
central
data
warehouse
every
4
hours,
or
6
times
per
day.
Suppose
that
you
want
to
schedule
your
Process
ETL
to
evaluate
data
starting
at
04:00
and
perform
evaluations
every
4
hours
from
that
time
forward.
You
would
then
schedule
the
Registration
ETL
to
run
prior
to
04:00
(for
example,
03:45).
Both
of
the
source
applications
should
be
scheduled
such
that
they
complete
writing
their
data
to
the
central
data
warehouse
between
midnight
(00:00)
and
03:45,
before
the
Registration
ETL
is
run.
This
ensures
that
all
measurement
data
for
the
previous
day
is
in
the
central
data
warehouse
before
the
Registration
ETL
and
Process
ETL
are
run,
and
prevents
missing
data
from
being
reported.
Publishing
the
Offering
After
you
finish
creating
offering
components
and
including
them
in
your
offering,
you
are
presented
with
a
confirmation
dialog,
which
lists
the
offering
name
and
description,
the
SLA
type,
the
selected
business
schedule
to
be
applied,
the
list
of
offering
components
that
you
created
and
configured,
and
any
SLAs
that
you
selected
to
add
to
the
offering.
At
this
time
you
can
save
the
offering
as
a
draft
to
be
continued
at
a
later
time,
or
you
can
publish
the
offering
and
make
it
available
for
inclusion
in
an
SLA.
If
you
save
the
offering
as
a
draft,
you
can
return
later
to
the
Manage
Offerings
page
and
select
the
draft
offering
to
continue
your
work.
If
you
choose
to
publish
the
offering,
it
is
added
to
the
list
of
published
offerings
that
are
available
for
selection
when
creating
SLAs.
See
Chapter
7,
“Creating
and
50
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Managing
SLAs,”
on
page
57
for
more
information
on
associating
your
published
offering
with
customers
and
resources
in
your
enterprise
to
create
the
SLA.
Managing
Offerings
The
Offerings
table
displays
all
of
the
available
offerings
that
have
previously
been
defined.
You
can
work
with
these
offerings
or
you
can
create
a
new
offering
and
add
it
to
the
table.
The
name
of
each
offering
must
be
unique,
and
should
suggest
a
distinct
level
of
service
to
differentiate
offerings
from
each
other.
The
Offerings
table
also
shows
the
state
of
the
offering,
which
is
one
of
the
following
values:
Draft
This
state
signifies
that
the
offering
is
being
developed
and
is
not
yet
ready
to
be
included
in
an
SLA.
Published
This
state
signifies
that
the
offering
is
available
to
customers
to
be
included
in
an
SLA.
Withdrawn
This
state
signifies
that
the
offering
had
been
published
some
time
in
the
past,
but
is
no
longer
available
for
inclusion
in
an
SLA.
The
Offerings
table
also
shows
the
number
of
SLAs
that
have
included
the
offering.
This
is
useful
if
you
want
to
delete
an
offering
from
the
table,
because
you
can
see
if
any
SLAs
are
still
using
the
offering.
You
can
only
remove
an
offering
if
it
is
not
included
in
any
SLAs.
See
the
online
user
assistance
in
the
Task
Assistant
for
information
on
tasks
that
you
can
perform
using
the
Manage
Offerings
dialog.
After
an
offering
is
published
and
made
available
to
be
included
in
SLAs,
you
can
still
modify
certain
parts
of
the
offering.
These
changes,
however,
affect
all
SLAs
that
include
this
offering,
so
you
must
have
a
clear
understanding
of
the
effect
that
a
change
in
the
offering
has
on
associated
customer
SLAs.
When
you
select
an
offering
from
the
Offerings
table
and
attempt
to
change
it,
the
Associated
SLAs
page
displays
a
list
of
associated
SLAs
that
are
affected
by
a
change
to
this
offering
change.
Before
your
selected
offering
changes
can
be
processed,
any
SLAs
that
are
based
on
the
offering
must
be
in
the
Canceled
or
Complete
state.
The
wizard
displays
a
page
showing
a
list
of
all
SLAs
that
are
incomplete
or
in
use
by
someone
else.
You
need
to
work
with
these
SLAs
until
they
are
all
in
the
Complete
or
Canceled
state.
You
can
make
the
following
changes
to
a
published
offering:
v
You
can
modify
the
name
of
the
offering.
v
You
can
modify
the
optional
text
description
of
the
offering.
v
You
can
add
one
or
more
SLAs
to
the
offering,
so
that
when
the
offering
is
included
in
an
SLA,
that
SLA
becomes
a
tiered
SLA.
Only
the
SLAs
that
are
compatible
with
the
SLA
type
specified
for
the
offering
are
available
in
the
Available
SLAs
table.
v
You
can
remove
existing
SLAs
from
the
offering.
v
You
can
select
a
different,
compatible
business
schedule
(one
that
has
the
same
schedule
states
as
the
existing
business
schedule)
to
associate
with
the
offering,
replacing
the
currently
associated
schedule,
with
certain
restrictions
(see
“Defining
Compatible
Schedules”
on
page
34).
Chapter
4.
Creating
and
Managing
Offerings
51
You
cannot
make
the
following
changes
to
a
published
offering:
v
You
cannot
change
the
SLA
type
for
which
this
offering
was
intended.
v
You
cannot
change,
add,
or
remove
offering
components.
For
more
information
on
changing
offerings,
refer
to
the
Task
Assistant.
52
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
5.
Creating
and
Managing
Realms
This
chapter
describes
the
process
of
creating
and
managing
realms
by
using
the
SLM
Administration
Console.
Before
you
can
complete
the
creation
of
a
customer
and
use
that
customer
information
to
create
your
service
level
agreement
(SLA),
you
must
define
one
or
more
realms
to
serve
as
a
way
to
organize
and
segment
your
customers
into
groups
that
make
sense
for
your
enterprise.
Customers
in
the
same
or
different
organizations,
companies,
geographic
regions,
and
so
on,
can
be
grouped
into
realms
that
segregate
one
customer’s
data
and
reports
from
another.
For
example,
you
might
create
a
realm
for
all
customers
in
the
United
States,
and
another
realm
for
customers
in
Europe.
You
might
also
create
a
realm
for
customers
in
a
particular
line
of
business
within
your
organization,
or
other
grouping
that
makes
sense
for
your
enterprise.
Customers
can
be
associated
with
more
than
one
realm,
if
desired.
IBM
Tivoli
Service
Level
Advisor
enables
you
to
define
one
or
more
realms
and
later
associate
them
with
customers
in
the
process
of
creating
an
SLA.
The
portfolio
contains
two
tasks
related
to
realms:
v
Create
Realm
is
for
creating
new
realms.
v
Manage
Realms
is
for
working
with
existing
realms.
From
the
Manage
Realms
page
you
can
also
create
new
realms,
and
you
can
perform
the
following
additional
tasks:
–
View
the
contents
of
a
realm.
–
Change
the
contents
of
a
realm.
–
Delete
a
realm.
Creating
Realms
You
can
create
a
new
realm
by
doing
any
of
the
following
tasks:
v
From
the
portfolio,
click
Create
Realm.
v
From
the
portfolio,
click
Manage
Realms,
and
then
from
the
Manage
Realms
page,
click
Create.
v
While
creating
a
customer,
you
can
create
a
new
realm
if
the
preferred
one
is
not
in
the
table
of
existing
realms
(see
Chapter
6,
“Creating
and
Managing
Customers,”
on
page
55).
Create
a
new
realm
by
completing
the
following
basic
steps:
v
Type
a
name
for
the
realm.
This
is
the
name
that
is
displayed
in
the
table
of
available
realms
when
you
later
associate
a
realm
with
a
customer.
You
should
type
a
name
that
is
meaningful
to
distinguish
this
realm
from
other
realms.
This
name
is
also
displayed
in
the
Realms
table
on
the
Manage
Realms
page,
which
contains
all
defined
realms.
v
Optionally,
type
a
text
description
for
the
realm.
This
is
additional
information
that
is
displayed
in
the
Realms
table
and
helps
describe
the
realm
in
more
detail.
This
information
might
make
it
easier
during
the
customer
creation
process
to
select
the
realm
to
include
in
the
customer
definition.
©
Copyright
IBM
Corp.
2002,
2004
53
Managing
Realms
From
the
Manage
Realms
page,
you
can
create
new
realms,
change
or
delete
existing
realms
(if
they
have
not
already
been
associated
with
a
customer),
or
view
the
contents
of
a
realm.
When
you
select
a
realm
from
the
Realms
table
and
click
View,
you
can
see
the
name
and
text
description
for
the
realm,
though
you
cannot
change
them
at
this
time.
When
you
have
completed
viewing
the
realm
details,
you
can
click
Change
from
the
Realms
table
if
you
want
to
change
any
realm
details.
When
you
select
a
realm
from
the
Realms
table,
if
it
is
not
already
associated
with
a
customer,
you
can
click
Change
and
modify
the
following
realm
parameters:
v
You
can
rename
the
realm
to
a
different
name.
v
You
can
modify
the
text
description
of
the
realm.
You
can
delete
a
realm
from
the
Realms
table
if
it
not
already
associated
with
a
customer.
The
Number
of
Customers
column
in
the
Realms
table
indicates
how
many
customers
are
associated
with
this
realm.
If
this
number
is
0,
you
can
click
Delete
to
delete
the
realm.
Refer
to
the
Task
Assistant
for
specific
procedures
to
create
and
manage
your
realms.
54
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
6.
Creating
and
Managing
Customers
This
chapter
describes
the
process
of
creating
and
managing
customers
by
using
the
SLM
Administration
Console.
Before
you
can
complete
the
creation
of
a
service
level
agreement
(SLA),
you
must
create
a
customer
and
associate
it
with
the
SLA
as
the
party
with
whom
you
are
agreeing
to
provide
levels
of
service.
Customers
might
typically
be
represented
as
organization
or
company
names
of
customers
who
depend
on
the
services
that
your
organization
provides.
Customers
are
defined
as
being
associated
with
one
or
more
realms,
or
customer
groups.
For
example,
customers
located
in
the
United
States
might
be
segmented
into
one
or
more
geographically
oriented
realms,
with
such
names
as
West
Coast
and
East
Coast,
or
certain
regions,
such
as
Southwest.
Organizational
realms
that
represent
division,
departments,
or
other
segments
of
a
company
can
be
thought
of
as
a
realm.
A
bank
might
have
a
Loan
Business
Unit,
and
a
Brokerage
Business
Unit,
each
of
which
defined
as
a
realm
with
one
or
more
associated
customers.
The
portfolio
contains
two
tasks
related
to
customers:
v
Create
Customer
is
for
creating
new
customers.
v
Manage
Customers
is
for
working
with
existing
customers.
From
the
Manage
Customers
page
you
can
also
create
new
customers,
and
you
can
perform
the
following
additional
tasks:
–
Create
a
new
customer
from
a
copy
of
an
existing
customer.
–
View
the
details
of
a
customer.
–
Change
the
details
of
a
customer.
–
Delete
a
customer.
Creating
Customers
You
can
create
a
new
customer
by
doing
any
of
the
following
tasks:
v
From
the
portfolio,
click
Create
Customer.
v
From
the
portfolio,
select
Manage
Customers,
and
then
from
the
Manage
Customers
page,
click
Create.
v
While
creating
an
SLA,
you
can
create
a
new
customer
if
the
preferred
one
is
not
in
the
table
of
existing
customers
(see
Chapter
7,
“Creating
and
Managing
SLAs,”
on
page
57).
Create
a
new
customer
by
completing
the
following
basic
steps:
v
Type
a
name
for
the
customer.
This
is
the
name
that
is
displayed
in
the
table
of
available
customers
when
you
later
associate
a
customer
with
an
SLA.
You
should
type
a
name
that
is
meaningful
to
distinguish
this
customer
from
other
customers.
This
name
is
also
displayed
in
the
Customers
table
on
the
Manage
Customers
page,
which
contains
all
defined
customers.
v
Optionally,
type
a
text
description
for
the
customer.
This
is
additional
information
that
is
displayed
in
the
Customers
table
and
helps
describe
the
customer
in
more
detail.
This
information
might
make
it
easier
during
the
SLA
creation
process
to
select
the
customer
to
include
in
the
SLA
definition.
©
Copyright
IBM
Corp.
2002,
2004
55
v
Select
at
least
one
realm
to
associate
with
this
customer.
The
Include
Realms
page
is
displayed,
and
for
a
new
customer
the
Included
Realms
table
is
initially
empty.
You
can
click
Add
to
display
a
Realms
table,
containing
a
list
of
the
available
realms
that
you
can
associate
with
the
customer.
Select
one
or
more
realms
from
the
Realms
table
to
be
included
in
your
customer
definition.
You
can
view
the
details
of
a
realm
before
including
it
by
clicking
the
realm
name
link
in
the
table.
If
you
do
not
see
an
available
realm
that
meets
your
needs,
you
can
create
a
new
realm
and
add
it
to
the
Realms
table,
and
then
include
it
in
your
customer
definition.
See
Chapter
5,
“Creating
and
Managing
Realms,”
on
page
53
for
information
about
realms.
Managing
Customers
From
the
Manage
Customers
page,
you
can
create
new
customers,
change
or
delete
existing
customers,
or
view
the
details
of
a
customer
definition.
When
you
select
a
customer
from
the
Customers
table
and
click
View,
you
can
see
the
name
and
text
description
for
the
customer,
and
the
realms
that
are
associated
with
the
customer,
though
you
cannot
change
them
at
this
time.
When
you
select
a
customer
from
the
Customers
table,
you
can
click
Change
and
modify
the
following
customer
parameters:
v
You
can
rename
the
customer
to
a
different
name.
v
You
can
modify
the
text
description
of
the
customer.
v
You
can
add
new
realms
to
the
customer.
v
You
can
remove
existing
realms
from
the
customer.
You
can
delete
a
customer
from
the
Customers
table
if
it
not
already
associated
with
an
SLA.
Select
the
customer
from
the
Customers
table,
and
if
the
Delete
button
is
enabled,
you
can
click
it
to
delete
the
customer.
Refer
to
the
Task
Assistant
for
specific
procedures
to
create
and
manage
your
customers.
56
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
7.
Creating
and
Managing
SLAs
This
chapter
describes
the
process
of
creating
and
managing
service
level
agreements
(SLAs)
by
using
the
SLM
Administration
Console.
An
SLA
is
an
agreement
between
your
enterprise
and
your
customers
on
expected
levels
of
service
for
services
provided
by
your
enterprise.
The
SLA
is
an
association
between
a
specific
customer,
an
offering
that
represents
a
specific
level
of
service,
and
a
resource
or
set
of
resources
that
is
monitored
and
managed
to
adhere
to
the
preferred
level
of
service.
The
schedules
and
offerings,
customers,
and
realms
that
were
defined
in
previous
chapters
are
combined
when
you
create
a
service
level
agreement.
The
SLA
includes
the
following
items:
v
Customer
information,
including
name,
description,
and
associated
realms
v
An
offering,
which
includes:
–
A
business
schedule
that
defines
peak,
prime,
standard,
and
other
schedule
state
hours,
and
which
might
optionally
include
one
or
more
auxiliary
schedules
defining
unique
or
infrequent
schedules
for
company
holidays,
common
maintenance
times
and
other
uses.
–
One
or
more
service
level
objectives,
configured
for
this
particular
offering
with
specific
metrics
that
are
evaluated
and
analyzed
on
a
regular
basis
for
violations
or
trends
toward
violations
of
the
SLA.
–
Optionally,
one
or
more
previously
defined
and
deployed
SLAs
that,
when
included
in
this
SLA,
create
a
multi-tiered
hierarchy
of
internal,
external,
and
outsourced
service
level
agreements
to
represent
a
true
end
to
end
view
of
services
provided
to
the
customer.v
Information
about
the
particular
resources
that
are
to
be
reported
on,
such
as
a
particular
server,
or
all
routers
on
the
third
floor
of
building
A,
or
a
particular
Web
site.
This
can
be
a
specific
resource
or
discrete
list
of
resources,
or
it
could
consist
of
a
dynamic
list
of
resources
that
meet
certain
filtering
criteria,
with
the
list
changing
over
time
as
compatible
resources
are
added
or
removed
from
your
enterprise.
The
portfolio
contains
the
following
tasks
related
to
SLAs:
v
Create
SLA
is
for
creating
new
service
level
agreements.
v
Manage
SLAs
is
for
working
with
existing
service
level
agreements.
From
the
Manage
SLAs
page
you
can
also
create
new
SLAs,
and
you
can
perform
the
following
additional
tasks:
–
Create
a
new
SLA
from
a
copy
of
an
existing
SLA.
–
View
the
contents
of
an
SLA,
and
view
certain
details
about
the
SLA,
including
information
on
violations
and
trends,
and
the
current
SLA
state.
–
Change
the
contents
of
an
SLA.
–
Delete
a
canceled
SLA
or
an
SLA
that
failed
to
be
deployed
or
changed.
–
Cancel
a
completed
SLA.
–
Resubmit
a
canceled
SLA
or
an
SLA
that
failed
to
complete
successfully.
–
Add
remarks
to
an
SLA
for
tracking
purposes.v
Use
Manage
Violations
to
adjudicate
violations
that
are
reported
against
an
SLA,
by
excluding
a
violation
or
by
reinstating
a
violation
that
is
excluded.
This
©
Copyright
IBM
Corp.
2002,
2004
57
is
typically
done
after
negotiation
with
the
customer
to
determine
if
reported
violations
are
valid
for
the
SLA,
or
if
they
can
be
excluded
due
to
special
circumstances.
v
Use
Replace
Resource
to
replace
a
resource
in
a
completed
SLA.
v
Use
Replace
Offering
to
replace
an
offering
that
is
included
in
an
SLA
with
another,
compatible,
offering.
If
your
user
name
is
assigned
to
either
the
SLA
Specialist,
the
SLA
Adjudicator,
or
the
SLM
Administrator
role,
these
tasks
are
available
in
your
portfolio.
Creating
SLAs
You
can
create
a
new
SLA
by
doing
any
of
the
following
tasks:
v
From
the
portfolio,
click
Create
SLA.
v
From
the
portfolio,
click
Manage
SLAs,
and
then
from
the
Manage
SLAs
page,
click
Create.
v
From
the
Manage
SLAs
page,
select
an
SLA
from
the
SLAs
table
and
then
click
Create
Like
to
create
a
copy
of
the
selected
SLA,
which
you
can
then
modify
as
needed.
This
method
reduces
the
amount
of
configuring
you
have
to
do,
because
you
can
make
just
a
few
changes
to
the
copy
and
save
it
as
a
new
SLA.
Create
a
new
SLA
by
completing
the
following
basic
steps:
v
Optionally,
type
a
name
for
the
SLA.
This
is
the
name
that
is
displayed
in
the
SLAs
table
on
the
Manage
SLAs
page.
You
should
type
a
name
that
is
meaningful
to
distinguish
this
SLA
from
other
SLAs.
If
you
do
not
specify
a
name,
the
SLA
ID
number
that
is
automatically
generated
for
each
SLA
is
used.
v
Optionally
type
a
text
description
for
the
SLA.
This
is
additional
information
that
is
displayed
in
the
SLA
table
and
helps
describe
the
SLA.
This
information
might
make
it
easier
to
select
the
preferred
SLA
to
perform
additional
functions.
v
Select
a
customer
to
associate
with
this
SLA.
You
can
select
only
one
customer
from
the
list
of
available
customers
that
are
shown
in
the
Customers
table.
You
can
view
the
details
of
a
customer
before
including
it
by
clicking
the
customer
name
link
in
the
table.
Customers
contain
one
or
more
realms,
each
of
which
is
used
to
group
customers
by
common
traits,
such
as
geography
or
organization,
according
to
the
needs
of
your
enterprise.
If
you
do
not
see
the
preferred
customer
name
in
the
Customers
table,
you
can
create
a
new
customer
and
add
it
to
the
Customers
table,
and
then
include
it
in
your
SLA.
See
Chapter
6,
“Creating
and
Managing
Customers,”
on
page
55
for
information
about
creating
customers.
v
Select
an
offering
to
be
associated
with
the
SLA.
You
can
select
only
one
offering
from
the
list
of
available
published
offerings
that
are
shown
in
the
Offerings
table
in
the
Select
Offerings
page.
You
can
view
the
details
of
an
offering
before
including
it
by
clicking
the
offering
name
link
in
the
table.
If
the
selected
offering
has
already
been
included
in
one
or
more
other
SLAs,
you
are
shown
that
information
as
well.
Some
offerings
might
include
other
SLAs
that
are
already
defined.
When
you
include
an
offering
that
also
includes
one
or
more
SLAs,
this
SLA
within
an
SLA
hierarchy
creates
a
tiered
SLA
that
you
can
use
to
represent
an
end
to
end
view
of
the
level
of
service
provided
to
your
customer,
reflecting
not
only
the
service
level
agreement
of
the
parent,
or
top
level
SLA,
but
the
underlying
SLAs
on
which
this
agreement
also
depends.
See
Chapter
4,
“Creating
and
Managing
Offerings,”
on
page
37
for
more
information
about
including
SLAs
within
offerings.
58
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
v
Depending
on
the
offering
that
you
have
selected,
you
are
then
prompted
to
include
the
resources
that
you
want
to
evaluate
for
the
selected
level
of
service,
for
each
offering
component
that
is
included
in
the
offering.
In
the
table
of
contents
for
the
Add
Resources
to
page
in
the
work
area
of
the
SLM
Administration
Console,
you
see
an
entry
for
each
offering
component
that
is
included
in
the
selected
offering.
For
example,
if
you
selected
an
offering
that
included
offering
components
named
IP
Host
and
Tivoli
Web
Transaction
Performance
Transaction
Node,
you
see
two
entries
in
the
table
of
contents,
Add
Resources
to
IP
Host
and
Add
Resources
to
Tivoli
Web
Transaction
Performance
Transaction
Node.
For
each
offering
component,
the
Included
Resources
table
is
displayed,
and
for
a
new
SLA
this
table
is
initially
empty.
Click
Add
to
create
a
dynamic
or
static
list
of
resources
to
be
evaluated
for
this
SLA.
A
dynamic
resource
list
is
a
list
of
resources
that
is
created
at
the
time
of
the
evaluation
based
on
some
filtering
criteria
that
you
establish.
The
list
is
created
each
time
an
evaluation
is
performed,
and
the
evaluation
is
performed
only
on
the
resources
that
match
the
filtering
criteria.
The
results
for
all
resources
are
included
together
in
a
single
evaluation.
This
means
that,
over
time,
you
can
add
and
remove
resources
from
your
enterprise
and,
as
long
as
the
resources
adhere
to
the
filtering
criteria,
these
resources
are
included
or
removed
from
the
evaluation.
If
a
new
resource
that
matches
the
filter
criteria
becomes
available,
then
the
next
time
that
metrics
are
evaluated,
that
new
resource
is
automatically
added
to
the
list.
This
is
useful
when,
for
example,
you
want
to
evaluate
metrics
against
all
of
the
company
machines
in
a
geographic
region,
such
as
city,
and
you
specify
a
filtering
criteria
for
Name,
containing
the
following
string:
*.city.company.com
You
can
also
preview
a
list
of
resources
that
currently
match
the
established
filter
criteria,
to
verify
the
filtering
is
configured
as
desired,
and
modify
it
if
needed,
before
continuing.
You
must
specify
at
least
one
resource
filter
for
a
dynamic
resource
list.
The
resulting
dynamic
list
is
added
to
the
Included
Resources
table.
A
static
resource
list
is
a
list
of
resources
that
is
created
once
when
the
SLA
is
created,
and
does
not
change
dynamically.
Each
time
an
evaluation
is
performed,
all
resources
in
the
list
are
evaluated,
and
each
resource
is
included
in
its
own
evaluation.
When
creating
the
static
resource
list,
you
have
the
option
of
using
filtering
criteria
to
define
the
selection
list.
If
you
do
not
specify
any
filtering
criteria,
all
resources
that
are
valid
for
the
selected
offering
component
are
made
available
for
selection
in
the
Resources
table.
You
can
specify
one
or
more
component
attributes
to
filter,
such
as
IP
Address,
and
a
value
for
each
attribute,
such
as
192.10.2.81.
All
resources
that
match
the
characteristics
of
the
selected
attributes
are
available
for
inclusion
in
the
offering
component.
If
no
matching
resources
are
found,
you
can
delete
filters
or
create
new
ones
with
different
attribute
values.
Select
one
or
more
of
these
reseources
to
add
them
to
the
Included
Resources
table.
Repeat
this
selection
of
resources
for
each
offering
component
in
the
offering.
Offering
components
with
availability
metrics:
When
assigning
resources
to
an
offering
component
that
contains
the
Availability
metric,
extra
care
must
be
taken
to
ensure
that
only
those
resources
monitored
by
your
source
application
for
availability
data
are
selected.
If
additional
resources
for
which
no
availability
data
exists
are
included,
then
either
the
results
of
the
Availability
evaluation
are
incorrect
because
the
absence
of
data
assumes
100%
availability,
or
evaluations
are
not
performed
because
missing
data
is
considered
to
be
an
error
condition.
Be
sure
to
verify
that
your
source
application
is
monitoring
all
of
the
resources
that
you
are
assigning
to
the
offering
component.
Chapter
7.
Creating
and
Managing
SLAs
59
v
Select
an
SLA
start
date.
The
default
is
the
day
that
the
SLA
is
created,
but
you
can
set
it
to
a
date
in
the
past
if
you
have
data
in
the
SLM
Database
and
SLM
Measurement
Data
Mart
for
the
date
period
that
you
want
to
evaluate
(this
might,
for
example,
be
useful
to
help
you
determine
proper
breach
values
to
specify
for
future
SLAs).
You
can
also
specify
a
date
in
the
future
if
you
do
not
want
to
activate
the
SLA
right
away.
If
you
select
a
start
date
in
the
past:
Keep
in
mind
the
following
considerations:
–
If
you
submit
an
SLA
with
a
start
date
in
the
past,
evaluations
are
performed
immediately.
–
Make
sure
that
historic
data
is
available.
Before
submitting
an
SLA
with
a
start
date
in
the
past,
verify
that
the
Registration
and
Process
ETLs
were
run
to
populate
the
SLM
Database
and
the
SLM
Measurement
Data
Mart
with
data
for
the
date
period
of
interest.
–
If
you
add
a
new
source
application
and
enable
it
for
data
collection
in
IBM
Tivoli
Service
Level
Advisor,
run
the
ETLs
first
to
obtain
historical
data
from
the
central
data
warehouse
before
submitting
an
SLA
with
a
start
date
in
the
past.
–
To
ensure
that
date
values
are
displayed
and
handled
properly,
start
dates
with
a
year
earlier
than
1970
are
not
permitted.
If
you
enter
a
date
earlier
than
1970,
an
error
message
is
displayed.
–
Depending
on
the
value
that
is
specified
for
the
start
date
and
the
complexity
of
the
SLA,
the
results
might
take
some
time
to
process
before
they
are
available
for
viewing
in
SLM
reports.
In
addition,
this
extra
processing
might
make
the
SLM
Server
machine
very
busy,
so
submit
this
SLA
at
times
other
than
when
ETL
or
evaluation
operations
are
typically
active.
–
During
the
processing
of
historical
data
for
an
SLA
with
a
start
date
in
the
past,
if
there
are
any
violations
or
trends
found,
they
are
not
escalated.
You
need
to
view
the
reports
to
see
the
results
of
these
evaluations.
Depending
on
the
frequency
of
evaluation
that
was
established
in
the
offering
that
is
included
in
the
SLA,
the
date
of
the
first
evaluation
is
calculated
and
displayed
along
with
this
SLA
start
date.
You
can
change
the
start
date
field
and
then
recalculate
the
first
evaluation
dates.
If
you
select
a
start
date
in
the
future:
Evaluations
are
performed
at
the
end
of
the
first
full
evaluation
interval
that
occurs
after
the
future
start
date.
For
example,
if
you
specify
an
SLO
evaluation
frequency
of
Monthly
and
you
submit
an
SLA
on
January
8,
2005,
with
an
SLA
start
date
of
March
16,
2005,
the
first
evaluation
is
performed
for
the
monthly
interval
of
April
1,
2005
to
April
30,
2005.
The
data
for
this
evaluation
is
not
available
until
after
May
1,
2005.
v
Select
the
time
zone.
You
can
either
use
the
default
time
zone
associated
with
the
SLM
Server,
or
you
can
specify
a
different
time
zone.
When
selecting
a
time
zone
other
than
the
default
value,
verify
the
following
information:
–
The
source
application
ETLs
are
scheduled
to
run
after
midnight
in
that
time
zone.
–
The
time
zones
of
the
business
schedule
periods
and
the
resultant
mapping
of
the
schedule
periods
on
the
selected
SLA
time
zone
result
in
correct
evaluations.
Submitting
the
SLA
After
you
complete
the
selection
of
customers
and
offerings
and
have
associated
all
preferred
offering
components
with
the
resources,
you
are
ready
to
submit
the
SLA.
60
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
You
receive
a
confirmation
dialog
that
contains
a
summary
of
your
choices
for
review.
Submitting
the
SLA
means
that
the
SLOs
in
the
offering
are
now
agreed
upon
by
the
offering
provider
and
the
customer.
This
agreement
is
the
SLA
that
is
analyzed
and
validated.
IBM
Tivoli
Service
Level
Advisor
then
deploys
the
SLA
and
adds
it
to
the
SLAs
table.
You
can
see
the
SLA
listed
on
the
Manage
SLAs
page
with
the
deployment
state
of
the
SLA
shown.
After
the
SLA
is
deployed
successfully,
it
is
in
the
Complete
state.
Once
an
SLA
is
in
effect,
its
objectives
are
actively
analyzed
and
validated.
The
results
are
stored
and
made
available
for
reporting
(see
the
SLM
Reports
document
for
information
on
available
reports).
Submitting
SLAs
and
Performing
Evaluations
When
you
submit
an
SLA,
the
date
that
the
Process
ETL
was
last
run
(that
caused
an
evaluation
to
be
performed)
is
recorded
for
comparison
to
any
evaluations
of
metric
data
that
are
currently
scheduled
to
be
performed.
Any
violations
that
are
discovered
from
the
start
of
the
SLA
to
the
date
of
the
last
Process
ETL
run
are
recorded
but
not
escalated.
If
you
do
not
change
the
start
date
of
the
SLA,
the
start
time
for
the
SLA
is
00:00
of
the
day
that
the
SLA
is
submitted.
For
example,
suppose
that
you
submit
an
SLA
on
Tuesday,
April
5,
at
13:00
(for
this
discussion,
assume
also
that
evaluations
are
configured
to
occur
in
the
same
time
zone
where
the
SLM
Server
is
located).
If
you
do
not
change
the
start
date
for
this
SLA,
it
is
considered
to
have
started
at
00:00
on
Tuesday,
April
5,
or
13
hours
earlier
on
the
same
day.
If
a
violation
of
that
SLA
occurs
(that
is,
the
metric
results
exceed
some
breach
value
specified
in
the
SLA)
anytime
after
00:00
on
April
5,
it
is
evaluated
as
a
violation
even
if
it
occurred
prior
to
the
original
submission
time
of
13:00.
As
another
example,
suppose
that
you
submit
the
SLA
on
Tuesday,
April
5,
at
13:00,
but
set
the
start
date
to
a
future
date,
to
Monday,
April
11.
If
a
violation
of
that
SLA
occurs
on
or
after
April
5
but
before
April
11,
it
is
not
discovered,
because
no
evaluations
take
place
between
April
5
and
April
11.
If
the
violation
occurs
after
10:00
on
April
11,
however,
it
is
evaluated
and
escalated
as
usual.
Managing
SLAs
The
SLAs
table
displays
all
previously
submitted
SLAs,
along
with
their
deployment
state
and
SLA
state.
You
can
work
with
these
SLAs
or
you
can
create
a
new
SLA
and
add
it
to
the
table.
IBM
Tivoli
Service
Level
Advisor
also
assigns
an
SLA
ID
number
to
each
newly
created
SLA.
When
you
create
the
SLA
you
can
optionally
specify
a
text
name
to
serve
as
the
SLA
name,
giving
it
a
more
meaningful
name
that
is
relevant
to
your
enterprise.
The
SLA
ID
number
is
still
kept
as
part
of
the
SLA,
and
serves
as
the
default
SLA
identifier
if
you
do
not
specify
another
name.
Other
information,
such
as
the
customer
name
and
the
selected
offering,
are
also
listed.
All
columns
in
the
table
can
be
sorted
using
the
table
sorting
functions
provided
in
the
SLM
Administrative
Console
as
well.
SLA
States
The
SLA
state
shown
in
the
SLAs
table
gives
an
indication
as
to
whether
or
not
the
levels
of
service
specified
in
the
SLA
are
being
maintained.
The
SLA
state
is
based
on
the
occurrence
of
trends
and
violations
over
the
past
31
days.
The
SLA
state
can
have
the
following
values:
Chapter
7.
Creating
and
Managing
SLAs
61
Steady
The
service
levels
agreed
upon
in
the
SLA
are
being
met.
No
violations
or
trends
toward
potential
violations
are
reported.
Violation
The
SLA
is
violated,
as
one
or
more
metrics
have
failed
the
evaluation.
Trend
A
trend
toward
a
potential
violation
of
an
SLA
is
detected
from
an
analysis
of
the
data.
Trend_and_Violation
Both
a
violation
and
a
trend
are
detected.
None
An
SLA
whose
deployment
state
is
not
Complete
(it
could
be
either
Submitted,
Deploy
Failed,
or
Cancelled)
If
an
SLA
is
changed
by
deleting
a
resource
from
the
SLA,
and
a
violation
or
trend
is
detected
against
that
resource,
the
SLA
state
of
the
SLA
is
still
shown
as
Trend
or
Violation,
even
after
the
resource
is
removed.
Deployment
States
The
Deployment
State
displayed
in
the
SLAs
table
gives
an
indication
of
the
health
of
the
SLA.
After
an
SLA
is
submitted,
it
is
processed
by
IBM
Tivoli
Service
Level
Advisor
and
goes
through
several
deployment
states
as
it
is
being
deployed.
If
existing
SLAs
are
changed
or
canceled,
they
too
pass
through
several
states
as
they
are
being
processed.
The
SLA
state
can
have
any
of
the
following
values:
Deploying
The
SLA
is
in
the
process
of
being
deployed.
Changing
The
SLA
is
in
the
process
of
being
changed.
Canceling
The
SLA
is
in
the
process
of
being
canceled.
Complete
The
SLA
is
complete.
The
SLA
was
either
deployed
successfully
or
changed
successfully
(note
that
this
does
not
imply
that
historical
evaluations
are
completed;
they
might
still
be
in
process).
Cancelled
The
SLA
is
canceled.
Deploy
Failed
The
SLA
was
not
deployed
successfully
(see
the
note
below).
Change
Failed
The
SLA
was
not
changed
successfully
(see
the
note
below).
Cancel
Failed
The
SLA
was
not
canceled
successfully
(see
the
note
below).
Rejected
The
SLA
is
rejected.
It
is
only
rejected
if
it
has
the
same
SLA
ID
number
as
another
SLA
being
processed.
Typically
this
should
not
occur.
Submitted
The
initial
state
when
an
SLA
is
created.
Cancel
Submitted
A
request
to
cancel
an
SLA
was
submitted.
62
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Change
Submitted
The
request
to
change
the
SLA
was
submitted.
An
SLA
in
the
Deploy
Failed,
Change
Failed,
or
Cancel
Failed
deployment
state
might
be
the
result
of
the
metric
evaluation
manager
component
of
IBM
Tivoli
Service
Level
Advisor
being
unavailable.
Have
your
SLM
Administrator
restart
this
component,
then
resubmit
the
SLA.
Viewing
SLA
Details
You
can
use
the
View
or
Details
functions
in
the
Manage
SLAs
page
to
view
additional
information
about
the
SLA.
The
View
function
displays
the
basic
definition
of
the
SLA,
showing
the
same
information
as
when
it
was
originally
created,
including
name
and
description,
customer
name,
associated
offering
name,
and
resources.
The
Details
function
provides
additional
information
about
the
SLA,
including
a
summary
of
violations
and
trends
that
are
reported
against
the
SLA
over
a
specified
time
range,
and
the
details
of
the
deployment
state.
Any
remarks
that
are
recorded
are
also
displayed,
and
a
list
of
offerings
that
include
the
SLA
is
also
shown.
See
the
Task
Assistant
for
more
information
about
these
functions.
Changing
SLAs
After
an
SLA
is
submitted,
you
can
still
make
changes
to
certain
parts
of
the
SLA
if
it
is
in
the
Complete
state:
v
You
can
change
the
name
or
description
of
the
SLA.
v
You
can
add
to
or
remove
from
the
Included
Resources
table
one
or
more
resources
for
each
offering
component.
v
You
can
choose
an
alternate
name
for
a
resource
that
has
an
alias
(not
all
resources
have
aliases).
You
cannot
change
the
following
parts
of
an
SLA:
v
You
cannot
change
the
customer
name
information.
v
You
cannot
directly
change
the
offering
that
is
included
in
the
SLA,
though
you
can
replace
the
offering
with
another,
compatible,
offering
(see
“Replacing
an
Offering”
on
page
65).
v
You
cannot
change
the
SLA
start
date
or
time
zone
information.
Changing
a
Tiered
SLA
If
you
have
a
tiered
SLA
(an
SLA
that
is
associated
with
an
offering
that
includes
one
or
more
other
SLAs),
changes
made
to
that
tiered
SLA
can
affect
one
or
more
associated
SLAs.
For
example,
suppose
you
have
defined
the
following
set
of
offerings
and
SLAs:
v
SLA1
is
associated
with
Offering1.
v
SLA2
is
associated
with
Offering2.
v
SLA3
is
associated
with
Offering3.
v
A
fourth
offering,
Offering4,
includes
SLA1,
SLA2,
and
SLA3.
v
SLA4
is
created
and
associated
with
Offering
4,
making
SLA4
a
tiered
SLA.
Chapter
7.
Creating
and
Managing
SLAs
63
Now,
suppose
that
you
cancel
SLA2.
You
receive
a
confirmation
message
warning
you
that
SLA2
is
part
of
a
tiered
SLA.
If
you
choose
to
continue,
SLA2
is
canceled,
but
SLA2
also
remains
defined
as
part
of
Offering4
until
you
explicitly
remove
it
using
the
Change
function
in
the
Manage
Offerings
page.
Trends
or
violations
that
are
evaluated
against
SLA2
are
no
longer
included
in
the
overall
results
for
SLA4.
If,
at
some
later
time,
you
resubmit
SLA2
(see
“Canceling
an
SLA”),
it
is
restored
to
its
active
state,
and
violations
and
trends
are
evaluated
as
they
were
before
SLA2
was
first
canceled.
Canceling
an
SLA
To
cancel
an
SLA,
use
the
Cancel
SLA
function
under
the
Manage
SLAs
task.
Canceling
an
SLA
stops
further
evaluations
from
occurring
for
this
SLA.
Existing
results,
trend
and
violation
data
are
still
kept
in
the
SLM
Database
for
report
generation.
Resubmitting
an
SLA
To
reactivate
an
SLA
that
is
canceled,
use
the
Resubmit
function
under
the
Manage
SLAs
task.
The
SLA
is
resubmitted
and
processed
as
usual.
With
this
function
you
can
redeploy
an
SLA
without
having
to
create
a
new
one.
If
the
SLA
has
a
start
date
in
the
past,
and
if
any
previous
results
are
detected,
additional
historic
evaluations
are
not
performed.
Deleting
an
SLA
If
you
no
longer
want
an
SLA
defined
to
evaluate
data,
and
if
you
no
longer
want
to
keep
any
evaluation
results
associated
with
the
SLA,
you
can
delete
the
SLA,
but
with
the
following
limitations:
v
You
can
only
delete
an
SLA
with
a
deployment
state
of
Canceled
or
Deploy
Failed.
v
If
there
are
trends
or
violations
associated
with
a
canceled
SLA,
you
are
asked
to
confirm
that
these
violations
or
trends
can
be
deleted
for
the
SLA.
v
Deleting
an
SLA
causes
all
data
for
this
SLA
to
be
removed
from
the
SLM
Database,
and
for
the
SLA
to
be
removed
from
the
list
of
managed
SLAs.
This
SLA
is
not
included
in
future
SLM
reports.
For
assistance
with
deleting
SLAs
that
do
not
meet
these
limitations,
contact
IBM
Customer
Support.
Refer
to
the
Task
Assistant
for
more
information
about
deleting
SLAs.
Adding
Remarks
to
an
SLA
You
can
use
the
Add
Remarks
function
of
the
Manage
SLAs
page
to
add
text
comments
in
a
running
log
that
accompanies
the
SLA.
This
might
be
useful
to
track
changes
that
are
made
with
this
SLA,
or
to
add
remarks
for
other
users
as
needed.
Each
remark
that
is
made
is
appended
after
previous
remarks.
These
remarks
are
displayed
in
the
Remarks
tab
when
you
use
the
Details
function
for
the
SLA.
64
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Replacing
a
Resource
There
might
be
times
when
you
want
to
change
the
resource
that
is
associated
with
one
or
more
SLAs.
You
might
need
to
change
a
resource
because
it
has
changed
within
a
source
application,
or
a
new
or
different
resource
is
put
in
place
in
your
enterprise
to
perform
the
function
of
the
old
resource.
You
can
use
the
Replace
Resource
function
in
the
portfolio
to
search
for
the
existence
of
a
particular
resource
name
and
selectively
replace
it
with
the
new
resource
name
in
one
or
more
SLAs.
If
you
do
not
already
know
the
exact
name
of
the
resource
in
question,
you
can
use
the
Browse
function
to
help
you
locate
the
preferred
name.
A
table
of
all
SLAs
that
contain
the
specified
resource
name
is
displayed.
Specify
the
new
resource
name,
or
use
the
Browse
function
to
find
it,
and
then
select
one
or
more
SLAs
in
the
table
for
which
you
want
the
resource
changed.
After
the
request
is
submitted,
you
can
refresh
the
table
and
monitor
the
SLA
states
for
completeness.
When
resource
names
are
displayed
in
a
table
column,
they
are
underlined
because
the
name
is
an
HTML
link
to
open
a
View
window.
If
a
resource
name
includes
underscore
characters
or
blank
spaces,
they
might
be
difficult
to
see
because
the
HTML
link
underline
masks
the
underscore
characters
and
blank
spaces
in
the
names.
Instead
of
typing
the
resource
name
manually,
you
might
find
it
easier
to
click
on
the
resource
name
link
to
display
the
View
Resource
notebook
page,
and
then
copy
and
paste
the
name
from
the
notebook
page
to
the
Resource
Name
field.
When
a
resource
is
replaced
in
the
middle
of
an
evaluation
interval,
only
measurements
for
the
new
resource
are
included
during
the
evaluation
of
the
interval.
See
the
Task
Assistant
for
details
on
finding
and
replacing
resource
names
in
your
SLAs
using
the
Replace
Resource
function.
Replacing
an
Offering
You
can
associate
a
different
offering
with
an
SLA
after
it
is
submitted.
The
new
offering
can
include
different
metrics
or
breach
values
without
invalidating
the
existing
SLA
definition.
A
different
schedule
can
also
be
associated
with
the
new
offering.
The
new
offering
must
be
compatible
with
the
old
offering,
meaning
that
it
must
have
the
same
offering
components
as
the
previous
offering,
because
of
the
specific
resources
already
defined
in
the
SLA
that
are
associated
with
the
offering
components.
You
can
use
either
the
Create
Offering
task
in
the
portfolio
to
create
a
new
offering
or
use
the
Create
Like
function
on
the
Manage
Offerings
page
to
create
a
copy
of
the
existing
offering,
then
make
the
changes
and
save
it
as
a
new
offering.
Use
the
Replace
Offering
task
in
the
portfolio
to
replace
the
existing
offering
with
the
new
offering.
You
specify
the
existing
offering
to
replace,
and
a
list
of
compatible
offerings
is
shown,
including
any
new
compatible
offerings
that
you
have
created.
Select
the
offering
to
replace
the
current
one.
A
list
of
SLAs
that
are
affected
by
this
change
are
then
shown.
Complete
the
selections
to
replace
the
offering.
See
the
Task
Assistant
for
details
on
replacing
offerings.
Chapter
7.
Creating
and
Managing
SLAs
65
Managing
Violations
You
can
use
the
Manage
Violations
task
in
the
portfolio
to
adjudicate
violations
against
your
SLA,
choosing
to
exclude
a
violation
if
it
is
determined
that
it
is
not
valid,
or
reinstate
a
violation
if
it
was
previously
excluded.
This
action
is
usually
performed
after
negotiating
with
the
customer
and
agreeing
that
a
violation
that
was
reported
is
not
valid.
Adjudicating
violations
is
discussed
further
in
Chapter
8,
“Evaluations
and
Trend
Analysis,”
on
page
67.
66
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
8.
Evaluations
and
Trend
Analysis
After
you
create
schedules,
offerings,
customers,
and
realms
and
associate
them
with
appropriate
resources
to
create
a
service
level
agreement
(SLA),
you
submit
the
SLA
to
IBM
Tivoli
Service
Level
Advisor
for
deployment.
The
SLA
is
then
processed
and
activated
on
the
start
date
that
you
specified.
After
the
SLA
is
successfully
deployed,
IBM
Tivoli
Service
Level
Advisor
begins
evaluating
measurement
data
that
is
transferred
from
Tivoli
Data
Warehouse
to
the
SLM
Measurement
Data
Mart
by
the
Process
ETL.
SLAs
that
are
submitted
to
IBM
Tivoli
Service
Level
Advisor
include
schedule
information
that
determines
how
often
evaluations
and
trend
analyses
are
performed,
typically
on
a
daily,
weekly,
monthly
interval,
or
multiple
times
per
day
if
optional
hourly
evaluation
frequencies
are
enabled
(see
“Configuring
SLO
Evaluation
Frequency”
on
page
44
for
more
information
on
enabling
optional
hourly
evaluation
frequencies).
This
type
of
evaluation
is
referred
to
as
an
SLO
evaluation,
because
it
performs
the
evaluation
for
the
service
level
objectives
defined
in
the
SLA
for
the
entire
evaluation
period
(hour,
day,
week,
or
month).
In
addition
to
SLO
evaluations,
you
can
optionally
perform
intermediate
evaluations,
which
occur
more
frequently
within
the
SLO
evaluation
period.
For
example,
you
can
define
a
monthly
SLO
evaluation
that
performs
evaluation
and
trend
analysis
for
the
entire
month,
along
with
daily
intermediate
evaluations
that
perform
a
separate
evaluation
during
each
day
of
the
month.
Intermediate
evaluations
must
occur
at
a
higher
frequency
than
SLO
evaluations.
For
example,
if
you
have
daily
SLO
evaluations,
you
can
only
configure
intermediate
evaluations
that
occur
multiple
times
per
day,
such
as
every
hour,
or
every
four
hours
(or
other
available
hourly
frequencies).
See
“Configuring
Advanced
Metric
Settings”
on
page
46
for
more
information
on
defining
intermediate
evaluations.
The
time
at
which
these
evaluations
are
performed
is
tied
to
the
completion
of
the
Process
ETL
in
moving
the
latest
metric
data
from
Tivoli
Data
Warehouse
into
the
SLM
Measurement
Data
Mart
(see
“Considerations
for
Specifying
the
Frequency
of
Evaluations
and
Trend
Analyses”
on
page
48
for
more
information
on
the
relationship
between
running
the
Process
ETL
and
performing
evaluations
and
trend
analyses).
Typically,
the
Process
ETL
is
scheduled
to
run
daily,
usually
during
times
when
the
additional
processing
by
the
SLM
Server
does
not
impact
other
business
operations.
The
Process
ETL
is
usually
scheduled
to
run
after
midnight
of
the
previous
day,
and
after
all
source
applications
complete
transferring
their
measurement
data
into
the
central
data
warehouse
of
Tivoli
Data
Warehouse.
Even
though
the
Process
ETL
might
be
scheduled
to
run
on
a
daily
basis,
SLO
evaluations
are
not
performed
until
the
end
of
the
SLO
evaluation
period.
For
example,
if
an
SLO
evaluation
frequency
is
specified
as
Monthly,
an
evaluation
is
not
performed
until
the
end
of
the
month,
even
though
the
Process
ETL
is
transferring
data
to
the
SLM
Measurement
Data
Mart
on
a
daily
basis
(other
SLAs
might
also
be
defined
to
evaluate
on
a
daily
or
weekly
basis
as
well,
so
evaluations
might
still
be
taking
place
for
some
SLAs
and
not
for
others).
For
intermediate
evaluations
or
for
SLO
evaluations
that
occur
multiple
times
per
day
(such
as
every
four
hours),
the
Process
ETL
must
be
scheduled
to
transfer
data
more
frequently
as
well
(it
is
assumed
that
source
application
ETLs
are
also
configured
and
scheduled
to
write
data
into
Tivoli
Data
Warehouse
more
frequently).
©
Copyright
IBM
Corp.
2002,
2004
67
After
the
intermediate
or
SLO
evaluation
period
is
complete,
and
after
the
next
run
of
the
Process
ETL,
evaluations
are
automatically
started
by
pulling
the
appropriate
data
from
the
SLM
Measurement
Data
Mart
and
analyzing
the
collected
measurement
data
against
the
breach
values
defined
in
the
SLA.
IBM
Tivoli
Service
Level
Advisor
looks
for
violations
of
the
agreed
upon
levels
of
service,
or
trends
toward
a
potential
future
violation,
and
stores
the
results
of
this
analysis
in
the
SLM
Database.
If
appropriate,
notifications
of
violations
or
trends
are
sent
according
to
how
they
were
configured
(see
Chapter
9,
“Event
Escalation
and
Notification,”
on
page
77),
and
these
evaluation
results
are
then
available
in
SLM
reports
(see
SLM
Reports
for
more
information
on
displaying
reports
from
the
results
of
evaluations).
This
process
is
illustrated
in
Figure
1
on
page
2.
After
viewing
reports
of
the
evaluation
results
on
the
SLM
Reports
Console,
you
might
want
to
adjudicate
certain
violations
by
excluding
them
from
a
report
if
they
are
determined
to
be
not
valid
for
an
SLA,
or
reinstating
a
violation
that
was
previously
excluded.
This
is
usually
done
after
negotiating
with
your
customer
to
determine
if
reported
violations
are
valid
for
the
SLA.
From
the
SLM
Administrative
Console
use
the
Manage
Violations
task
in
the
portfolio
to
display
violations
in
the
database
and
select
them
to
be
excluded
or
reinstated.
See
“Adjudicating
Evaluation
Results”
on
page
73
for
more
information
about
adjudicating
violations.
Introducing
Metric
Evaluators
Evaluations
and
trend
analyses
are
performed
differently
depending
on
the
specific
metrics
that
are
selected
for
inclusion
in
an
offering
that
is
associated
with
the
SLA.
Metrics
are
evaluated
by
comparing
the
collected
measurement
data
against
established
breach
values,
and
they
are
handled
differently
depending
on
the
type
of
metric
evaluator
that
is
used
to
perform
the
evaluation.
The
metric
evaluators
used
by
IBM
Tivoli
Service
Level
Advisor
include
the
following
types:
v
Type
A
-
Minimum,
Maximum,
Average
v
Type
A
-
Transaction
Success
v
Type
B
-
Total
v
Type
B1
and
B2
-
Problem
Management
v
Type
C
-
Availability
Metrics
that
are
defined
for
various
source
applications
that
collect
measurement
data
to
write
to
Tivoli
Data
Warehouse
fall
into
one
of
the
above
metric
evaluator
types.
Each
of
these
metric
types
are
described
in
further
detail
in
Appendix
A,
“Introducing
Metric
Evaluators,”
on
page
81,
and
in
Appendix
B,
“Validating
Data
Points
Using
Metric
Evaluators,”
on
page
91.
Retrying
an
Evaluation
Occasionally,
the
SLA
evaluation
process
automatically
retries
an
evaluation
if
the
first
attempt
is
not
successful,
due
to
loss
of
a
database
connection,
missing
data,
or
other
problems
(see
the
Troubleshooting
document
for
more
information
on
problems
related
to
data
retrieval
and
recovering
from
unsuccessful
evaluations).
Depending
on
when
the
original
evaluation
took
place,
an
automatic
retry
is
started
at
one
of
the
following
times:
01:00
GMT,
07:00
GMT,
13:00
GMT,
or
19:00
GMT.
If
the
evaluation
is
still
unsuccessful,
the
evaluation
is
retried
in
6-hour
intervals
for
the
following
specified
number
of
retries:
68
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
v
For
daily
evaluations:
up
to
three
retries,
repeated
every
6
hours
v
For
weekly
evaluations:
up
to
25
retries,
repeated
every
6
hours
v
For
monthly
evaluations:
up
to
85
retries,
repeated
every
6
hours
For
example,
suppose
that
an
SLA
is
evaluated
on
a
daily
basis,
at
03:00
GMT.
If
a
retry
is
needed,
it
is
automatically
started
at
the
next
available
time,
or
07:00
GMT,
and
is
automatically
repeated
up
to
two
more
times,
at
13:00
GMT
and
19:00
GMT.
If
this
is
a
weekly
evaluation,
up
to
25
retries
are
performed,
4
per
day,
every
6
hours
at
the
specified
times.
The
hour
of
the
day
that
the
retry
occurs
depends
on
the
time
zone
of
the
SLM
Server.
For
example,
if
the
time
zone
of
an
SLM
Server
is
set
to
the
EDT
time
zone
(Eastern
Day
Light
Savings),
a
retry
occurs
at
the
following
times:
v
03:00
EDT
(equivalent
to
07:00
GMT)
v
09:00
EDT
(13:00
GMT)
v
15:00
EDT
(19:00
GMT)
v
21:00
EDT
(01:00
GMT)
When
an
evaluation
needs
to
be
automatically
retried,
it
is
placed
in
the
active
retry
state.
If
the
reevaluation
is
still
not
successful
after
the
maximum
number
of
retries,
the
state
is
changed
to
the
stopped
retry
state.
If
the
SLM
Server
is
restarted,
evaluations
in
the
active
retry
state
are
attempted
once
and
then
moved
to
the
stopped
retry
state
if
they
are
unsuccessful.
Use
the
scmd
mem
showRetrys
command
to
display
entries
in
both
the
active
retry
and
stopped
retry
states.
See
the
Command
Reference
for
more
information
about
this
CLI
command.
If
data
for
a
particular
evaluation
interval
arrives
after
the
evaluation
is
run,
that
data
is
not
included
in
the
evaluation,
unless
a
later
reevaluation
is
performed
for
that
interval.
Evaluations
are
performed
only
on
the
data
that
is
available
at
the
time
the
evaluation
is
run.
The
evaluation
is
not
held
up
indefinitely
until
all
of
the
data
arrives,
so
it
is
important
to
schedule
the
running
of
the
source
ETLs
(and
the
Registration
and
Process
ETLs)
to
occur
after
midnight
on
any
given
day,
so
that
the
evaluation
and
trend
analysis
includes
data
for
the
entire
previous
day
(00:00
to
23:59),
and
produces
the
earliest
possible
notification
of
violations
and
trends
for
that
evaluation
period.
To
avoid
missing
data
conditions,
the
ETLs
should
be
run
after
midnight
with
respect
to
the
SLA
associated
with
the
western-most
time
zone.
Analyzing
Trends
IBM
Tivoli
Service
Level
Advisor
uses
a
linear
algorithm
and
an
exponential
stress
detection
algorithm
to
analyze
existing
measurement
data
and
to
predict
trends
toward
future
violations.
You
do
not
have
to
decide
which
algorithm
best
suits
the
data
in
your
environment,
or
choose
between
these
two
algorithms.
Both
algorithms
are
active
and
evaluate
the
same
data
for
trends
according
to
their
methods
of
evaluation.
The
exponential
stress
detection
algorithm
is
designed
to
monitor
data
for
signs
of
oncoming
stress
to
a
resource
in
the
enterprise
that
might
result
in
a
violation.
Due
to
the
iterative
estimations
and
calculations
used
by
the
exponential
stress
detection
algorithm,
no
graphical
trend
line
associated
with
the
exponential
stress
detection
algorithm
is
displayed
with
graph
data.
Trend
lines
that
are
displayed
on
graphs
are
associated
with
the
linear
algorithm
only.
See
the
SLM
Reports
document
for
information
on
displaying
graphs
and
trend
lines.
Chapter
8.
Evaluations
and
Trend
Analysis
69
A
minimum
of
30
sample
data
points
is
required
for
trend
prediction.
The
trending
algorithms
use
the
current
measurement
value
based
on
a
minimum
of
30
sample
data
points,
and
they
compute
the
predicted
value
over
the
next
two
subsequent
evaluation
periods.
By
default,
the
algorithms
use
two
future
time
periods
to
detect
a
trend.
You
can
set
the
number
of
time
periods
to
use
for
either
linear,
exponential
stress
detection,
or
both
types
of
algorithms
using
the
scmd
mem
trending
command.
See
the
Command
Reference
document
for
details
on
this
command.
If
the
predicted
value
approaches
the
breach
value
defined
in
the
offering
component
of
the
SLA,
and
if
the
value
is
predicted
to
exceed
the
breach
value
by
either
the
linear
or
the
exponential
stress
detection
algorithm,
then
a
trend
detection
event
is
reported.
If
there
is
an
outstanding
trend
detection
event,
and
the
current
evaluation
value
is
significantly
away
from
the
breach
value
defined
in
the
SLO,
a
trend
cancel
event
is
reported.
However,
if
a
violation
occurs
after
the
trend
detection
event,
a
trend
cancel
event
is
never
reported.
In
rare
cases
it
might
be
possible
for
trends
to
be
detected
by
both
algorithms.
This
is
expected
to
occur
only
if
the
data
first
approaches
the
breach
value
in
a
linear
fashion,
but
then
changes
to
fit
the
exponential
stress
detection
algorithm.
This
might
also
occur
if
the
data
values
are
consistently
within
10%
to
20%
of
the
breach
value.
Trend
events
include
a
type
field
that
displays
which
breach
value
(minimum,
maximum,
average,
or
total)
is
trending
toward
a
potential
violation.
When
a
trend
cancel
is
received,
it
is
correlated
with
previous
trends
that
were
detected
that
have
matching
metric
name,
schedule
state,
order
element
instance,
and
component
name.
The
corresponding
trend
detection
events
are
closed
if
all
of
the
associated
breach
value
types
for
minimum,
maximum,
average,
or
total
trends
are
canceled.
For
example,
suppose
that
the
breach
values
for
the
Metric
Response
Time
for
the
Critical
schedule
state
in
an
offering
component
named
Web
Server
1
is
defined
to
the
following
specifications:
v
Average
breach
value
is
59
milliseconds.
v
Maximum
breach
value
is
110
milliseconds.
If
the
breach
values
are
evaluated
against
totals,
the
maximum
breach
value
is
evaluated
against
the
highest
single
value
reported
during
the
evaluation
period.
The
SLA
is
configured
to
have
trend
evaluations
performed
daily.
The
following
example
illustrates
how
a
trend
is
detected
and
canceled,
using
the
linear
algorithm
(though
the
exponential
stress
detection
algorithm
is
also
used
to
analyze
the
same
data,
it
is
not
included
in
this
sample
discussion)
:
Trend
Analysis
Date
Average
Measured
Data
Maximum
Measured
Data
Predicted
Average
Value
Predicted
Maximum
Value
Violation
Detected?
Trend
Detected?
01Feb2005
10ms
20ms
No
No
02Feb2005
20ms
30ms
No
No
03Feb2005
30ms
40ms
50ms
will
occur
on
05Feb2005
60ms
will
occur
on
05Feb2005
No
No
70
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Trend
Analysis
Date
Average
Measured
Data
Maximum
Measured
Data
Predicted
Average
Value
Predicted
Maximum
Value
Violation
Detected?
Trend
Detected?
04Feb2005
40ms
50ms
60ms
will
occur
on
06Feb2005
70ms
will
occur
on
06Feb2005
No
Yes
(at
this
time
it
is
predicted
that
the
Average
value
will
exceed
the
59ms
average
breach
value
on
06Feb2005)
05Feb2005
40ms
30ms
Below
average
breach
value,
but
not
low
enough
to
cancel
the
trend
40ms
will
occur
on
07Feb2005
No
Yes
(maintain
previously
detected
trend
on
Average)
06Feb2005
10ms
30ms
Well
below
the
average
breach
value,
enough
to
cancel
the
trend
45ms
will
occur
on
08Feb2005
No
Canceled
(Average)
On
03Feb2005,
the
trend
analysis
predicts
that
in
the
next
two
trending
evaluation
periods,
05Feb2005
will
have
a
average
value
of
50
ms.
Because
the
predicted
value
is
less
than
the
average
breach
value
of
59
ms,
even
though
the
values
to
date
are
increasing
toward
the
breach
value,
no
trend
is
detected
or
reported.
On
04Feb2005,
the
trend
analysis
predicts
that
in
the
next
two
trending
evaluation
periods,
starting
on
06Feb2005,
the
average
value
is
60
ms.
Because
the
predicted
value
is
increasing
toward
the
average
breach
value,
and
because
the
average
predicted
value
exceeds
the
breach
value
of
59
ms,
the
trend
is
detected
with
projected
date
of
06Feb2005.
However,
suppose
the
actual
measurement
data
drops
to
10
ms
on
06Feb2005,
which
is
moving
away
from
the
breach
value.
A
trend
canceled
event
is
reported
for
the
average
type
SLO.
Consider
the
events
that
occurred
in
the
following
sequence:
1.
The
trend
analysis
detected
a
trend
toward
a
violation
on
04Feb2005
with
a
projected
date
and
time
of
2/6/05
09:09:07
EST
for
the
average
breach
value
of
59ms.
2.
If
the
trend
continues
at
the
predicted
rate,
the
trend
analysis
also
detects
a
trend
toward
a
violation
with
a
projected
date
of
2/10/05
09:09:07
EST
for
the
maximum
breach
value
of
90ms.
3.
The
actual
measured
data
on
05Feb2005
slowed
the
upward
climb
of
the
predicted
trend
calculation,
but
not
quite
enough
to
cancel
the
trend
prediction.
Chapter
8.
Evaluations
and
Trend
Analysis
71
4.
On
06Feb2005,
the
actual
measured
data
of
10ms
caused
the
calculation
of
the
trend
to
be
significantly
less
than
the
breach
value,
enough
for
the
trend
canceled
to
be
issued
for
the
average
type
value.
Note:
The
trend
is
not
canceled
for
the
ResponseTime
metric
in
the
Critical
schedule
state,
because
the
Maximum
type
value
is
still
trending
toward
violation.
5.
The
trend
canceled
was
received
for
the
maximum
breach
value.
At
this
point
both
the
average
and
maximum
trends
are
canceled,
so
the
overall
trend
for
the
Response
Time
metric
is
canceled
for
the
Critical
schedule
state.
A
trend
cancellation
event
is
escalated
using
the
configured
event
escalation
methods.
For
escalation
using
Tivoli
Enterprise
Console,
this
trend
correlation
action
is
effective
only
if
you
apply
the
sample
Tivoli
Enterprise
Console
rule
file,
slm.rls,
as
described
in
the
installation
process
(see
Chapter
5
in
Getting
Started
for
more
information).
Caution
Regarding
Trend
Tracking
Information
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.
Evaluating
Historical
Data
As
part
of
the
process
of
creating
an
SLA,
you
specify
the
start
date
for
when
the
SLA
becomes
active.
By
default,
this
date
is
set
to
the
date
that
the
SLA
is
submitted,
so
that
future
measurement
data
is
evaluated
against
the
SLA
from
that
date
forward.
However,
you
might
have
historical
measurement
data
that
was
written
to
the
central
data
warehouse
before
the
SLA
was
created
(or
even
before
IBM
Tivoli
Service
Level
Advisor
was
installed
into
your
environment).
You
might
want
to
evaluate
that
data
for
predictive
planning
purposes,
for
example,
to
determine
the
proper
breach
value
settings
that
should
be
used
in
the
SLA
based
on
past
experience.
Using
the
starting
date
value
for
the
SLA,
you
set
the
start
date
for
the
SLA
to
a
date
in
the
past,
and
when
you
submit
the
SLA,
evaluations
are
immediately
performed
on
the
historical
data
from
that
date
forward.
The
start
time
for
the
SLA
is
00:00:00
(in
the
time
zone
specified
for
the
SLA)
on
the
date
specified.
See
“Creating
SLAs”
on
page
58
for
more
information
on
setting
the
SLA
start
date,
and
special
considerations
to
keep
in
mind
when
specifying
a
start
date
in
the
past.
When
evaluating
historical
data,
keep
in
mind
the
following
limitations:
v
You
cannot
change
the
value
for
the
SLA
start
date
during
a
Change
operation
on
an
SLA.
If
this
were
allowed,
it
would
require
deleting
all
of
the
results,
trends,
and
violations
for
the
SLA
and
running
the
evaluations
again
with
the
changed
date.
To
effectively
change
the
start
date
of
an
SLA,
delete
the
SLA
and
submit
a
new
one
with
a
different
start
date.
v
Historical
evaluations
are
performed
only
from
the
start
date
of
the
SLA
up
to
the
date
when
the
Process
ETL
was
last
run.
v
No
escalation
events
are
generated
for
evaluation
periods
that
occur
after
the
SLA
start
date
and
before
the
date
that
the
SLA
was
created.
v
Evaluations
of
historical
data
can
only
be
run
on
data
that
is
in
the
SLM
Measurement
Data
Mart.
You
must
ensure
that
data
is
in
the
database
for
the
72
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
historical
evaluation.
Keep
in
mind
that
aged
data
might
have
already
been
purged
from
the
SLM
Measurement
Data
Mart.
v
The
historical
evaluation
is
only
run
one
time
for
the
life
of
the
SLA.
Resubmitting
an
SLA
does
not
cause
historic
evaluations
to
be
performed.
v
If
an
evaluation
of
historical
data
is
in
process
for
an
SLA,
any
standard
evaluations
that
would
be
started
by
completion
of
the
Process
ETL
are
blocked
from
starting
until
the
historical
evaluation
completes.
v
If
a
standard
evaluation
or
a
reevaluation
is
currently
taking
place
at
the
time
that
the
SLA
with
a
start
date
in
the
past
is
submitted,
the
historic
evaluation
is
blocked
from
completing
until
the
sandard
evaluation
completes.
See
the
scmd
mem
skipHistoricSLAs
command
in
the
Command
Reference
for
additional
information
about
managing
SLAs
with
a
start
date
in
the
past.
Adjudicating
Evaluation
Results
After
performing
evaluations
and
viewing
the
resulting
reports
in
the
SLM
Reports
Console,
you
might
find
that,
based
on
some
additional
information
about
your
environment
operations,
such
as
a
justifiable
outage
on
a
resource,
some
metric
data
might
not
be
valid
or
accurate,
resulting
in
an
inaccurate
SLM
report.
Use
the
Manage
Violations
task
in
the
portfolio
of
the
SLM
Administration
Console
to
exclude
one
or
more
violations
from
being
considered
in
SLM
reports.
Usually
this
is
done
after
negotiating
and
agreeing
with
your
customer
to
exclude
the
violation,
resulting
in
a
reversal
of
a
reported
SLA
violation.
When
you
exclude
a
violation
using
the
Manage
Violations
task,
you
can
include
a
text
description
explaining
the
reason
for
the
adjudication
for
tracking
purposes.
Subsequent
SLM
reports
do
not
include
the
adjudicated
violation,
unless
an
option
is
selected
to
display
excluded
violations
in
the
report.
A
special
icon
is
displayed
in
the
report
next
to
the
actual
value
of
the
excluded
violation,
and
clicking
this
link
displays
the
details
of
the
excluded
violation.
See
SLM
Reports
for
more
information
about
how
excluded
violations
are
displayed
in
reports.
You
can
also
reinstate
a
violation
that
has
been
previously
excluded,
using
the
Manage
Violations
task
in
the
portfolio.
You
can
display
violations
in
the
table,
and
select
one
or
more
violations
to
exclude
or
reinstate.
The
result
is
reflected
in
reports
the
next
time
they
are
displayed
or
refreshed.
Performing
Reevaluations
There
might
be
times
when
not
all
of
the
expected
measurement
data
is
available
for
evaluation,
or
if
some
data
arrives
too
late
to
be
included
in
the
scheduled
evaluation.
These
problems
might
be
caused
by
incorrect
scheduling
of
when
source
ETLs
write
data
into
the
central
data
warehouse,
or
when
target
ETLs
extract
the
data,
or
other
problems
that
might
arise
(such
as
power
outages,
resources
unavailable,
or
connections
lost).
In
these
cases
you
might
need
to
perform
a
reevaluation
to
include
the
missing
or
late
arriving
data
in
the
final
results
that
are
displayed
in
reports.
Use
the
scmd
mem
reEval
command
to
perform
reevaluations.
See
the
Command
Reference
for
a
complete
description
of
the
use
of
this
command
to
reevaluate
your
data.
Chapter
8.
Evaluations
and
Trend
Analysis
73
Unique
Evaluation
Examples
This
section
illustrates
a
few
unique
situations
that
you
might
encounter
when
IBM
Tivoli
Service
Level
Advisor
evaluates
measurement
data.
Receiving
more
violations
and
results
than
expected
The
following
scenario
illustrates
one
example
of
defining
a
schedule
such
that
the
schedule
definition
and
the
specified
evaluation
frequency
combine
to
produce
more
violations
than
expected
.
Consider
a
simple
business
schedule
that
is
defined
with
a
Peak
schedule
state
associated
with
a
period
from
09:00
to
12:59,
and
the
rest
of
the
time
is
assigned
to
the
default
state
of
No
Service.
Hourly
evaluations
are
enabled,
and
an
evaluation
frequency
of
every
4
hours
is
selected.
Because
the
evaluation
frequency
is
specified
as
every
4
hours,
evaluations
are
performed
for
the
following
intervals
during
the
24-hour
day:
v
00:00
to
03:59
v
04:00
to
07:59
v
08:00
to
11:59
v
12:00
to
15:59
v
16:00
to
19:59
v
20:00
to
23:59
For
the
Peak
schedule
state
defined
between
09:00
and
12:59,
two
separate
evaluations
are
performed,
the
first
for
measurement
data
from
09:00
to
11:59,
and
the
second
for
measurement
data
between
12:00
and
12:59.
If
a
violation
of
the
Peak
schedule
state
occurred
for
the
entire
period
between
09:00
and
12:59,
two
evaluation
results
and
two
separate
violations
are
generated,
with
notifications
sent
out
each
time.
Though
this
might
not
be
the
intended
result
(you
might
expect
a
single
violation
to
be
reported
for
the
single
4-hour
period),
because
the
defined
schedule
period
overlaps
two
evaluation
periods,
the
evaluations
produce
two
sets
of
results.
Mixing
of
daily
and
hourly
evaluation
intervals
When
you
schedule
the
Process
ETL
to
run
more
than
once
per
day,
you
should
make
sure
that
all
source
applications
write
their
data
to
the
central
data
warehouse
after
midnight,
and
that
they
complete
their
processing
before
the
first
scheduled
run
of
the
Process
target
ETL,
otherwise
data
can
be
lost.
For
example,
consider
two
source
applications
that
have
ETLs
writing
data
to
the
central
data
warehouse.
ETL
A
writes
data
once
per
day,
and
ETL
B
writes
data
every
4
hours
(6
times
per
day).
The
Process
ETL
must
be
scheduled
to
run
at
the
higher
frequency
(every
4
hours)
to
accommodate
the
measurement
data
being
written
by
ETL
B
at
the
higher
frequency.
Suppose
that
the
Process
ETL
is
scheduled
to
run
at
04:00
(and
every
four
hours
after
that).
Even
though
ETL
A
only
needs
to
be
run
once
per
day,
care
should
be
taken
to
make
sure
that
ETL
A
is
scheduled
to
run
between
midnight
and
when
the
Process
ETL
first
runs
(sometime
before
04:00).
Otherwise
daily
evaluation
data
can
be
lost
for
the
first
evaluation.
74
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Trending
an
Imminent
Violation
Usually
a
trend
analysis
evaluates
the
latest
measurement
data
and
compare
it
to
breach
values,
and
if
it
detects
a
trend
toward
a
potential
violation
in
the
near
future,
a
notification
is
issued,
enabling
support
personnel
to
take
corrective
action
before
the
violation
actually
occurs.
There
is
a
special
case
where,
due
to
the
evaluation
frequency,
the
measurement
data
collected,
and
the
timing
of
the
actual
analysis,
a
trend
might
predict
an
imminent
violation
to
occur
within
the
current
evaluation
period,
when
in
fact
it
is
known
from
the
actual
measurement
data
that
no
violation
occurred.
Consider
a
scenario
with
the
following
characteristics:
v
The
SLO
evaluation
frequency
is
specified
as
Daily.
v
The
trend
analysis
frequency
is
specified
as
Daily,
using
continuous
trend
evaluation.
v
The
business
schedule
is
defined
for
a
Peak
schedule
state
from
08:00
to
15:59
(8
hours).
v
The
breach
value
assigned
to
this
schedule
state
is
42.
v
For
each
day,
one
measurement
data
point
is
collected
each
hour,
giving
8
data
points
per
day
during
the
Peak
schedule
period.
v
Over
a
period
of
days,
the
following
actual
measurement
data
is
collected:
–
Day
0:
No
measurement
data
during
the
Peak
period
–
Day
1:
All
8
data
points
report
an
actual
value
of
10.
–
Day
2:
All
8
data
points
report
an
actual
value
of
20.
–
Day
3:
All
8
data
points
report
an
actual
value
of
30.
–
Day
4:
All
8
data
points
report
an
actual
value
of
40.
–
Day
5:
All
8
data
points
report
an
actual
value
of
50
(and
a
violation
occurs
here
because
this
exceeds
the
breach
value
of
42).
Now,
even
though
daily
trend
analysis
is
specified,
IBM
Tivoli
Service
Level
Advisor
requires
a
minimum
of
30
data
points
in
order
to
perform
a
valid
analysis.
As
each
day
is
only
collecting
8
data
points,
the
trend
analysis
cannot
occur
until
Day
4,
when
the
data
collected
for
Day
1
through
Day
4
totals
32
data
points.
The
trend
analysis
therefore
takes
place
on
Day
4.
The
trend
analysis
predicts
a
linear
trend
with
a
projected
violation
of
the
breach
value
on
Day
4.
This
occurs
because
the
analysis
uses
the
middle
of
each
evaluation
period
as
the
single
time
that
produced
that
evaluation
value.
In
this
case,
the
middle
of
the
day
is
used
to
indicate
when
the
daily
value
occurred.
This
causes
the
analysis
to
project
a
violation
of
the
breach
value
(42)
later
in
Day
4.
However,
on
Day
4
the
daily
SLO
evaluation
that
takes
place
for
all
of
the
data
in
Day
4
shows
that
no
violation
occurred
(because
all
measured
values
were
at
40,
still
below
the
breach
value).
This
is
a
case
where
the
date
and
time
of
the
projected
violation
occurs
before
the
date
and
time
when
the
trend
was
detected.
It
is
possible
that
this
scenario
might
also
occur
as
a
result
of
historical
evaluations.
Note
that
an
actual
violation
does
occur
on
Day
5,
with
actual
values
exceeding
the
breach
value.
Because
of
this,
the
trend
notification
for
the
predicted
violation
on
Day
4
is
still
issued,
otherwise
you
would
have
no
prior
notification
of
the
real
violation
occurring
on
Day
5.
Chapter
8.
Evaluations
and
Trend
Analysis
75
When
the
projected
violation
date
for
an
active
trend
occurs
earlier
than
the
detection
date,
this
condition
is
displayed
in
SLM
reports
with
a
special
imminent
violation
icon
in
the
Breach
Value
column
of
the
Trend
report.
See
SLM
Reports
for
an
example
of
this
icon
in
a
Trend
report.
76
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Chapter
9.
Event
Escalation
and
Notification
IBM
Tivoli
Service
Level
Advisor
provides
event
escalation,
the
ability
to
send
notifications
of
service
level
agreement
(SLA)
events
occurring
as
a
result
of
the
evaluation
and
trend
analysis
of
the
measurement
data
from
Tivoli
Data
Warehouse.
When
a
violation
or
a
trend
toward
a
violation
of
an
SLA
is
detected,
IBM
Tivoli
Service
Level
Advisor
creates
an
external
notification
of
the
event.
When
support
personnel
are
notified
of
service
level
violations
or
trends
toward
future
violations,
they
can
take
immediate
corrective
action
to
decrease
outage
times
and
improve
their
ability
to
guarantee
levels
of
service.
In
addition
to
the
typical
event
escalation
functions
provided
by
IBM
Tivoli
Service
Level
Advisor,
you
can
also
configure
an
event
notification
to
be
generated
whenever
a
specific
IBM
Tivoli
Service
Level
Advisor
message
is
logged,
using
the
scmd
log
handler
eventWatcher
CLI
command.
See
“Escalating
Messages”
on
page
80
for
more
information.
Event
notifications
can
take
any
of
the
following
forms:
v
message
v
Tivoli
Enterprise
Console
event
v
SNMP
trap
You
can
configure
the
methods
for
notification
when
IBM
Tivoli
Service
Level
Advisor
is
first
installed
(see
the
Getting
Started
document
for
more
information),
and
this
configuration
can
be
modified
any
time
after
installation
using
command
line
interface
(CLI)
commands
(see
the
Command
Reference
document
for
more
information).
Event
Notification
The
JavaMail
API
version
1.2
is
included
with
IBM
Tivoli
Service
Level
Advisor
and
used
to
send
messages.
When
a
violation
or
trend
is
detected,
an
automated
message
can
be
sent
similar
to
the
following
example:
v
For
a
violation:
To:
Joe
Problem
Technician
CC:
Jane
IT
Administrator
Subject:
SLA
Violation
NOTICE:A
metric
violation
has
been
detected.
The
details
are
as
follows:
Customer
Name:
Joe
Sales
Rep
SLA
Number:1996
SLA
Name:
Gold
Service
Other
Affected
SLAs:
None
Schedule
State:
Peak
Resource:Web
Server
1
Metric
Violated:Availability
Units:
Percent
Evaluation
End
Date:
8/30/02
10:59:40
AM
EDT
Violation
Details:
©
Copyright
IBM
Corp.
2002,
2004
77
Minimum:
breach
value=99,
metric
value=95.90
v
For
a
trend
toward
a
future
violation:
To:
Joe
Problem
Technician
CC:
Jane
IT
Administrator
Subject:
SLA
Trend
NOTICE:A
trend
toward
a
potential
metric
violation
has
been
detected.
The
details
are
as
follows:
Customer
Name:Joe
Sales
Rep
SLA
Number:1996
SLA
Name:
Gold
Service
Other
Affected
SLAs:
None
Schedule
State:Peak
Resource:Web
Server
1
Metric
Predicted
to
be
Exceeded:Availability
Units:
Percent
Trend
Prediction:
Minimium:
breach
value=300.0,
projected
date=7/16/02
9:09:07
AM
EST
Analysis
Period:
7/9/02
10:59:53
AM
EDT
to
7/23/02
10:59:53
AM
EDT
Total
Samples:
70
At
installation
time,
the
SMTP
server
name,
addresses
and
the
text
of
the
message
can
be
configured.
You
can
also
configure
these
parameters
after
installation
using
the
scmd
escalate
customize
command.
See
the
Command
Reference
document
for
details
on
the
variables
that
you
can
include
in
your
messages.
applications
must
support
UTF-8
encoding:
All
messages
sent
by
the
event
notification
system
are
encoded
using
UTF-8.
Be
certain
that
the
application
used
to
read
these
messages
is
capable
of
supporting
UTF-8
encoding.
The
nature
of
sending
might
cause
the
message
to
travel
across
several
servers
before
finally
reaching
its
destination.
Because
of
this,
there
is
no
way
to
verify
an
address
that
you
specify.
You
should
test
your
configuration
with
the
scmd
escalate
test
CLI
command.
The
only
error
path
that
can
be
checked
is
if
the
SMTP
server
is
not
responding.
If
there
are
problems
communicating
with
the
SMTP
server,
a
message
is
logged.
See
the
Troubleshooting
document
for
additional
information
on
problems
with
message
content
and
verifying
your
notification
method.
Including
HTML
Link
in
Event
Notification
To
access
the
SLM
Report
details
from
the
regarding
the
SLA
in
which
a
violation,
trend,
or
trend
canceled
is
detected,
you
can
optionally
include
the
HTML
link
in
the
message.
See
the
description
of
scmd
escalate
customize
in
the
Command
Reference
document
for
details
on
customizing
the
message
content
to
include
the
HTML
link.
After
the
inclusion
of
the
HTML
link
in
the
message
is
enabled,
subsequent
e-mails
on
violation,
trend,
and
trend
cancelled
events
have
text
similar
to
the
following
example
appended
to
the
content:
Click
on
the
link
to
view
the
details:
http://myMachine.raleigh.ibm.com:80/SLMReport/opCustReportDetail.jsp?&fmail=
78
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
y&fcon=1000.Tivoli+Systems.Gold+Service&fco=1000&fcu=
Tivoli+Systems&fslatype=0&fsd=r30d
You
can
click
the
link
to
browse
the
report
detail
of
the
SLA.
If
you
do
not
have
an
active
report
session
established
already,
a
dialog
window
is
displayed
for
you
to
sign
on.
Tivoli
Enterprise
Console
Event
Notification
The
Tivoli
Enterprise
Console
server
uses
rules
to
specify
and
control
responses
to
events
throughout
your
enterprise.
Tivoli
Enterprise
Console
rules
can
be
set
up
to
take
appropriate
actions
when
a
new
violation
event
or
trend
event
is
received,
such
as
sending
an
e-mail,
paging
someone,
displaying
a
message
on
a
desktop,
or
taking
predetermined
corrective
actions.
A
sample
rule
set
is
provided
to
close
trend
detection
events.
When
a
cancelation
trend
is
received,
it
is
correlated
with
previous
trend
detection
events
that
have
matching
metric
name,
schedule
state,
SLA
ID,
and
component
name,
and
actions
are
taken
to
close
these
events.
Refer
to
the
Tivoli
Enterprise
Console
Rule
Builder’s
Guide
for
guidelines
on
writing
rules.
Five
different
types
of
classes
are
defined
in
the
SLM
Event
Class
Definitions
File,
SLM.baroc:
SLA-Base-Event
Inherits
the
Tivoli
Enterprise
Console
Base
Event,
EVENT,
and
defines
the
attributes
common
to
the
SLA-Violation-Event,
SLA-Trend-Event,
and
SLA-Trend-Cancel-Event
class
types
SLA-Violation-Event
Defines
additional
attributes
of
the
Violation
event
SLA-Trend-Event
Defines
additional
attributes
of
the
Trend
event
SLA-Trend-Cancel-Event
Defines
any
additional
attribute
for
trend
correlation
purposes
SLM-Application-Event
Defines
attributes
for
posting
the
error
message
of
an
application
problem
The
SLM.baroc
file
can
be
located
in
the
<SLM_Install_Dir>/escalate
directory,
where
<SLM_Install_Dir>
is
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed.
A
sample
rule
set,
called
slm.rls,
is
provided
to
close
trend
detection
events.
When
a
cancelation
trend
is
received,
it
is
correlated
with
previous
trend
detection
events
that
have
matching
metric
name,
schedule
state,
SLA
ID,
component
name,
and
trending
method,
and
actions
are
taken
to
close
these
events.
SNMP
Trap
Event
Notification
The
SNMP
traps
constructed
by
the
escalation
interface
are
based
on
SNMP
V1.
Four
types
of
SLA
events
are
defined
in
the
slm.mib
MIB
definition
file:
v
Violation
event
v
Trend
event
v
Trend
cancelled
event
Chapter
9.
Event
Escalation
and
Notification
79
v
Application
event
The
MIB
file
can
be
located
in
the
<SLM_Install_Dir>/escalate
directory,
where
<SLM_Install_Dir>
is
the
directory
where
IBM
Tivoli
Service
Level
Advisor
is
installed.
Date
fields
in
the
events
are
formatted
using
DateAndTime,
which
is
specified
in
RFC
2579.
A
projected
date
without
a
value
is
represented
by
all
0s.
For
example,
00000000+00
signifies
that
the
trend
has
never
happened.
SNMP
traps
are
sent
using
UDP
which
is
a
connectionless
protocol.
Therefore,
there
is
no
way
to
determine
if
a
trap
actually
makes
it
to
its
destination.
The
only
error
that
can
be
generated
is
if
the
SNMP
API
is
unable
to
open
a
socket
on
the
local
host,
otherwise
it
is
assumed
that
everything
worked
successfully.
Be
sure
to
perform
a
test
with
the
CLI
to
make
sure
that
there
is
connectivity
between
IBM
Tivoli
Service
Level
Advisor
and
the
trap
daemon.
The
test
traps
are
not
stored
in
the
SLM
Database.
Application
Event
Escalation
Application
events
are
escalated
to
provide
notification
about
application
errors
using
the
supported
event
escalation
methods.
If
you
have
configured
one
or
more
event
escalation
methods
for
typical
event
notification,
these
same
methods
are
used
for
application
event
notification.
For
example,
the
Registration
and
Process
ETLs
can
escalate
an
event
when
the
ETL
has
not
been
run
in
several
days.
The
following
message
is
escalated
via
e-mail,
SNMP,
and
Tivoli
Enterprise
Console
notification
methods:
DYKET1003W
The
ETL
process
’DYK_m05_Populate_Registration_Datamart_Process’
has
not
run
in
5
days.
Escalating
Messages
You
can
be
notified
when
any
message
is
issued
by
IBM
Tivoli
Service
Level
Advisor,
through
the
normal
escalation
and
notification
methods
(e-mail,
SNMP
trap,
or
Tivoli
Enterprise
Console
event).
For
example,
you
can
be
notified
whenever
an
evaluation
results
in
an
unexpected
missing
data
condition,
when
the
DYKME9064W
message
is
issued.
You
can
specify
which
messages
you
want
to
watch
for
by
using
the
scmd
log
handler
CLI
command
and
specifying
the
escalateMessages
key,
similar
to
the
following
example:
scmd
log
handler
eventWatcher
-set
escalateMessages=DYKME9064W
DYKME9037E
In
this
example,
an
application
event
is
generated
and
a
notification
is
sent
if
either
of
the
two
messages,
DYKME9064W,
or
DYKME9037E,
are
issued.
The
entire
message
is
sent
as
part
of
the
escalation
text.
See
the
Command
Reference
document
for
more
information
on
the
scmd
log
handler
command
and
other
CLI
commands,
and
see
the
Messages
document
for
more
information
on
messages
issued
by
IBM
Tivoli
Service
Level
Advisor.
80
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Appendix
A.
Introducing
Metric
Evaluators
This
appendix
describes
each
category
of
metric
evaluator
and
how
it
is
used
to
derive
SLA
information
from
various
source
applications.
The
analysis
of
a
Service
Level
Agreement
by
IBM
Tivoli
Service
Level
Advisor
is
performed
through
the
use
of
one
or
more
metric
evaluators.
A
metric
evaluator
is
a
generalized
analytical
algorithm
that
evaluates
a
particular
category
of
metric
data
against
an
SLO.
Metric
evaluators
are
classified
by
how
they
process
data
and
the
end
result
that
they
produce.
There
are
four
major
categories
of
metric
evaluators:
v
Availability
v
Performance
v
Utilization
v
Incident
and
Change
Request
Each
metric
has
its
own
unique
characteristics
regarding
how
it
performs
an
evaluation.
This
section
describes
how
each
metric
category
is
evaluated,
including
examples
where
appropriate.
At
the
end
of
each
section
the
internal
metric
evaluator
type
that
handles
the
metric
calculation
is
specified
(for
example,
Metric
Evaluator
Type:
Type
A).
Further
descriptions
of
these
metric
evaluator
types
is
in
Appendix
B,
“Validating
Data
Points
Using
Metric
Evaluators,”
on
page
91.
Availability
Availability,
determining
whether
a
resource
or
service
can
be
accessed,
is
one
of
the
most
important
measurements
to
include
in
an
SLA.
Whether
the
measurement
is
made
from
the
viewpoint
of
a
customer
(which
is
most
appropriate
for
a
service)
or
made
by
a
basic
monitoring
program
(which
is
common
for
servers
and
peripheral
devices),
ensuring
that
the
appropriate
availability
metrics
are
inserted
into
an
SLA
is
critical
to
measuring
the
downtime
of
an
IT
infrastructure.
Typically,
availability
is
represented
in
management
applications
as
a
state
indicating
whether
the
resource
is
available
or
unavailable.
This
information
is
maintained
only
for
the
current
status
of
the
element,
and
the
value
is
stored
in
a
single,
non-numeric
variable.
Availability
information
is
represented
in
the
central
data
warehouse
in
one
of
3
ways:
v
Percent
of
Time
in
State
v
State
Transitions
v
Transaction
Availability
Percent
of
Time
in
State
One
of
the
most
straightforward,
but
least
flexible,
ways
that
availability
information
is
recorded
in
the
central
data
warehouse
is,
for
each
polling
or
summarization
period,
the
percentage
of
time
that
the
resource
exists
in
each
state.
For
example,
if
a
resource
is
continuously
available,
then
you
could
record
that
the
element
was
in
the
available
state
100%
of
the
time.
If
the
resource
is
offline
for
6
minutes
out
of
an
hour,
then
it
was
in
the
available
state
for
90%
of
the
hour,
and
in
the
unavailable
state
for
10%
of
the
hour.
An
SLA
can
be
written
against
this
metric
to
calculate
the
percentage
of
unavailable
time
for
the
resource
per
day,
week,
or
month
excluding
any
hours
that
are
declared
to
be
in
the
No
Service
state.
For
hours
in
which
there
is
no
data
recorded
for
a
state,
a
value
of
0%
is
assumed.
For
hours
that
fall
into
the
No
Service
category,
that
time
is
ignored
in
the
calculation.
If
©
Copyright
IBM
Corp.
2002,
2004
81
availability
is
recorded
every
hour
and
10
of
the
24
hourly
periods
show
100%
availability,
10
show
100%
unavailability,
and
4
hours
from
12:00
a.m.
to
4:00
a.m.
are
No
Service,
then
the
availability
percentage
for
the
20
in-service
hours
of
the
day
is
calculated
as:
(10
Available
hours
X
100
%)/(20
total
hours)
=
1000/20
=
50
%
Available
per
day
Metric
Evaluator
Type:
Type
A
State
Transitions
Another
way
that
availability
data
is
represented
in
the
central
data
warehouse
is
by
recording
actual
state
transitions
that
represent
the
various
states
(for
example,
from
the
unavailable
state
to
the
available
state).
A
common
set
of
states
is
used
to
record
the
state
transition
information.
Table
5
defines
the
common
state
transitions.
A
resource
must
transition
from
one
state
immediately
into
the
next
to
have
a
continuous
transition.
If
there
is
a
gap
of
more
than
600
ms
between
any
two
consecutive
states,
then
the
transitions
are
considered
separately.
Table
5.
Common
state
transitions
State
name
Meaning
Available
The
resource
was
available
to
do
work.
Degraded
The
resource
was
available
to
do
work,
but
there
was
a
problem
that
made
it
impossible
for
the
element
to
function
correctly
(such
as
when
performance
was
degraded).
Unavailable
The
resource
was
not
available
to
do
work.
Repairing
A
problem
was
found
with
the
resource
and
was
repaired
during
this
time.
Unknown
or
Unmanaged
It
is
not
known
whether
the
resource
was
available
or
unavailable.
The
start
time
(MSMT_ST),
common
state
measurement
name
(MSMTTYP_NM),
and
duration
(MSMT_TOT_VAL)
of
the
transition
are
recorded
in
the
measurement
table
in
the
central
data
warehouse.
For
example,
suppose
the
hard
drive
of
a
server
becomes
unusable
and
is
offline
for
6
minutes
from
9:15
a.m.
to
9:21
a.m.,
and
a
measurement
is
recorded
showing
that
the
hard
drive
was
in
the
unavailable
state
starting
at
9:15
for
6
minutes.
Also,
suppose
that
a
technician
repairs
the
hard
drive
and
brings
the
server
back
on-line
65
minutes
later.
Finally,
suppose
that
the
same
problem
occurs
again
five
days
later.
The
transitions
shown
in
Table
6
are
recorded
in
the
measurement
table
in
the
central
data
warehouse
to
represent
these
outages.
Table
6.
Transitions
recorded
in
the
central
data
warehouse
Start
time
Measurement
name
Total
value
12/21/2003
9:15:00
EST
Unavailable
6
minutes
12/21/2003
9:21:00
EST
Repairing
65
minutes
12/26/2003
9:17:99
EST
Unavailable
3
minutes
12/26/2003
9:20:00
EST
Repairing
35
minutes
IBM
Tivoli
Service
Level
Advisor
adds
the
following
derived
metrics
to
each
component
that
has
a
measurement
group
of
TRANS
for
inclusion
in
an
SLA:
Number
of
Outages
The
total
number
of
outages
per
evaluation
period
is
calculated
by
82
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
considering
the
time
from
the
beginning
of
the
unavailable
state
to
the
end
of
the
repairing
state,
removing
any
No
Service
time
based
on
the
business
schedule.
For
this
example,
over
the
weekly
evaluation
period
from
21Dec2003
to
27Dec2003,
there
are
two
outages.
The
outage
on
21Dec2003
is
a
total
of
71
minutes
long
and
the
outage
on
26Dec2003
is
a
total
of
40
minutes
long.
The
total
number
of
outages
over
the
week
is
2.
Time
to
Repair
The
average
and
maximum
time
to
repair
per
evaluation
period
(day,
week,
or
month)
is
derived
from
the
number
of
outages
by
doing
the
following
steps:
1.
Each
unique
outage
over
the
evaluation
period
is
calculated
using
the
methodology
described
for
Number
of
Outages.
2.
The
average
or
maximum
result
value
is
calculated
across
all
outages
discovered
in
the
evaluation
period.
For
this
example,
the
average
and
maximum
time
to
repair
for
the
weekly
evaluation
period
of
21Dec2003
to
27Dec2003
is:
Average:
(71
+
40)/2
=
55.5
minutes
Maximum:
71
minutes
(the
outage
on
26Dec2003)
There
is
a
priority
assigned
to
each
schedule
state.
This
priority
is
used
only
when
evaluating
availability
metrics
such
as
Time
to
Repair
and
Number
of
Outages.
If
the
outage
transition
for
a
resource
spans
periods
of
two
different
schedule
states,
the
metric
is
reported
only
for
the
schedule
state
with
the
higher
priority.
In
the
example
data,
if
9:00
a.m.
to
10:00
a.m.
has
a
schedule
state
of
Critical,
and
10:00
a.m.
to
11:00
a.m.
has
a
schedule
state
of
Peak,
then
the
average
Time
To
Repair
of
55.5
minutes
is
reported
against
the
Critical
period,
and
is
not
reported
at
all
for
the
Peak
period.
Similarly,
two
outages
are
reported
for
Critical
and
none
for
Peak.
This
prevents
a
single
actual
outage
of
a
resource
from
being
counted
more
than
once
against
multiple
schedule
periods.
Percent
Available
The
percent
available
per
evaluation
period
is
also
derived
from
the
number
of
outages.
After
all
of
the
outages
are
determined,
the
percent
available
for
the
evaluation
period
is
calculated
by
dividing
the
remaining
available
time
by
the
total
evaluation
period
time.
For
the
previous
example,
over
the
weekly
evaluation
period
of
21Dec2003
to
27Dec2003
(equivalently
10080
minutes),
the
availability
of
the
server
is
calculated
as
(10080-111)/10080
or
98.9%
available
for
the
week.
The
total
evaluation
period
time
excludes
any
No
Service
time
periods
defined
in
the
business
schedule
and
any
unknown
or
unmanaged
periods.
For
example,
suppose
that
the
time
period
from
24Dec2003
to
25Dec2003
(2
full
days)
is
defined
as
a
No
Service
period
in
the
business
schedule.
After
including
this
time
duration
into
the
calculation,
the
resulting
percent
available
is
calculated
as
(total
possible
evaluation
period
time
–
No
Service
time
–
outage
time)
/
(total
evaluation
period
time
–
No
Service
time)
=
(10080-336-111)/(10080-336)
=
98.86%
available.
Metric
Evaluator
Type:
Type
C
Transaction
Availability
For
source
applications
that
record
the
number
of
successful
transactions
and
the
number
of
failed
transactions
per
hour,
a
percentage
called
Transaction
Success
is
derived.
The
metric
can
be
enabled
in
IBM
Tivoli
Service
Level
Advisor
on
any
Appendix
A.
Introducing
Metric
Evaluators
83
performance
metric
supporting
the
sample
count
(MSMT_SMPL_CNT)
and
error
count
(MSMT_ERR_CNT)
fields.
The
calculation
is
as
follows:
%
Availability
=
(sample
count)/(sample
count
+
error
count)
For
example,
suppose
that
the
round
trip
time
for
an
HTTP
server
is
reflected
in
the
following
measurement
data
as
shown
in
Table
7:
Table
7.
Sample
measurement
data
for
HTTP
Server
round
trip
time
Start
time
Minimum
Maximum
Average
Sample
count
Error
count
12/21/2003
7:00:00
EST
10
5000
500
30
0
12/21/2003
8:00:00
EST
20
3000
600
25
5
12/21/2003
9:00:00
EST
30
6000
800
28
2
The
daily
transaction
success
value
for
21Dec2003
is
then
calculated
as
follows:
(30+25+28)/(30+25+28+5+2+0)
=
92.22%
Metric
Evaluator
Type:
Type
A
Performance
Performance
generally
measures
the
time
it
takes
to
access
a
critical
resource.
The
following
examples
of
performance
measurements
are
available
with
IBM
solutions:
v
HTTP
server
response
time
v
Bytes
transferred
per
second
v
WebSphere
servlet
execution
time
v
Average
database
connection
pool
wait
time
v
EJB
response
time
For
these
types
of
measurements
the
minimum
(MSMT_MIN_VAL),
maximum
(MSMT_MIN_VAL),
and
average
(MSMT_AVG_VAL)
values
per
hour
are
stored
in
the
central
data
warehouse
measurement
table.
Performance
data
might
also
be
stored
in
the
total
values
(MSMT_TOT_VAL).
Consult
the
warehouse
pack
documentation
for
your
source
application
for
details.
Weighted
Average
Performance
Measurements
optionally
include
values
for
sample
and
error
counts
assuming
the
data
is
available
from
the
source
application.
If
a
source
application
supports
sample
count
(MSMT_SMPL_CNT),
and
the
units
are
not
in
percentages,
a
weighted
average
is
calculated
as
shown
in
the
following
example:
Daily
Weighted
Average
=
(Sample
Count
X
Average
Value)/(Total
sample
counts)
For
example,
suppose
that
the
round
trip
time
for
an
HTTP
server
is
reflected
in
the
following
measurement
data
as
shown
in
Table
8:
Table
8.
Sample
measurement
data
for
HTTP
Server
round
trip
time
Start
time
Minimum
Maximum
Average
Sample
count
Error
count
12/21/2003
7:00:00
EST
10
5000
500
30
0
12/21/2003
8:00:00
EST
20
3000
600
25
5
12/21/2003
9:00:00
EST
30
6000
800
28
2
84
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
The
daily
response
time
values
for
21Dec2003
are
then
calculated
as
follows:
Minimum:
10
Maximum:
6000
Average:
[
(500
X
30)
+
(600
X
25)
+
(800
X
28)
]
/
(30
+
25
+
28)
=
631.33
ms
For
metrics
that
are
not
based
on
percentages,
if
an
application
supports
both
the
sample
count
(MSMT_SMPL_CNT)
and
error
count
(MSMT_ERR_CNT),
then
a
percent
error
value
is
calculated
and
is
reported
with
the
final
SLO
result
value.
The
percent
error
is
calculated
using
the
following
formula:
Percent
Error
=
(Total
Error
Counts)
/
(Total
Sample
Counts
and
Error
Counts)
For
this
example,
the
percent
error
value
for
21Dec2003
is
calculated
as:
Percent
Error:
(0
+
5
+
2)
/
(0
+
5
+
2
+
30
+
25
+
28)
=
(
7
/
90
)
=
7.78
%
For
metrics
that
do
not
support
Sample
Count
and
Error
Counts,
a
null
value
is
recorded
in
the
central
data
warehouse
measurement
table
in
these
fields,
and
a
value
of
1
is
assumed
for
the
calculations.
A
higher
percentage
of
error
might
indicate
a
problem
with
the
monitoring
mechanism
itself.
This
varies
from
source
application
to
source
application.
Metric
Evaluator
Type:
Type
A
Total
Performance
For
performance
thresholds,
counts
of
Tivoli
Enterprise
Console
events,
and
other
values,
a
total
value
for
an
evaluation
period
is
calculated:
Daily
Total
=
Sum
of
all
Total
Values
For
example,
suppose
that
a
threshold
is
set
up
in
a
source
application
that
indicates
that
the
access
time
for
a
Web
transaction
must
be
less
than
a
given
threshold.
Suppose
that
the
data
shown
in
Table
9
is
stored
in
the
central
data
warehouse
for
the
Threshold
Exceeded
metric
for
this
component:
Table
9.
Sample
data
for
Threshold
Exceeded
metric
Start
time
Total
Sample
count
Error
count
12/21/2003
7:00:00
EST
3
30
0
12/21/2003
8:00:00
EST
1
25
5
12/21/2003
9:00:00
EST
0
28
2
The
daily
total
values
for
21Dec2003
are
calculated
as
follows:
Minimum:
0
Maximum:
3
Total:
(3
+
1
+
0)
=
4
thresholds
were
exceeded
for
the
day.
Metric
Evaluator
Type:
Type
B
Utilization
Utilization
metrics
generally
measure
the
amount
of
consumption
of
a
resource.
Examples
of
common
utilization
metrics
are
CPU
utilization,
disk
space
utilization,
database
connection
pool
utilization,
and
network
bandwidth
utilization.
These
metrics
are
useful
in
Operational
Level
Agreements
(OLAs)
because
they
give
the
IT
staff
an
early
indication
of
whether
or
not
a
resource
used
by
an
external
SLA
Appendix
A.
Introducing
Metric
Evaluators
85
will
breach.
For
example,
if
a
database
connection
pool
is
being
utilized
at
90
%
or
greater
during
the
critical
period
of
a
day,
this
might
impact
the
end
user
response
time
of
an
application
that
requires
database
connections
from
this
pool.
Metric
Evaluator
Type:
Type
A
Incident
and
Change
Metrics
Incident
and
Change
metrics
generally
provide
measurements
on
Help
Desk
activities.
Incidents
describe
events
that
are
not
part
of
normal
operations
and
that
may
cause
interruptions
to
a
service.
Changes
are
actions
taken
by
IT,
sometimes
in
response
to
problems,
to
change
the
status
of
one
or
more
resources
in
an
infrastructure.
For
example,
if
you
call
the
help
desk
and
report
that
your
access
to
your
is
slow,
that
would
be
recorded
as
an
incident.
A
resulting
change
request
might
be
created
to
upgrade
the
hardware
on
the
server
that
you
access
for
your
e-mail.
You
should
refer
to
your
Help
Desk
application
or
ETL
documentation
for
exact
measurement
and
attribute
names.
There
are
several
types
of
metrics
that
work
with
IBM
Tivoli
Service
Level
Advisor
in
support
of
SLAs
with
incident
and
change
data:
v
Incident
and
change
record
counts
v
Incident
and
change
record
percentages
v
Total
time
to
reach
a
state
v
Total
time
in
state
Each
incident
or
change
is
modeled
in
Tivoli
Data
Warehouse
as
a
separate
component.
Because
of
this,
you
must
use
dynamic
resource
assignment
when
evaluating
these
types
of
metrics.
IBM
Tivoli
Service
Level
Advisor
calculates
results
across
several
incident
or
change
metrics
based
on
preconfigured
attributes.
Examples
of
each
are
described
in
the
following
sections,
along
with
information
on
how
to
use
IBM
Tivoli
Service
Level
Advisor
to
calculate
various
metrics.
Counts
This
type
of
incident
and
change
metric
covers
SLOs
such
as
the
total
number
of
incidents
that
were
opened
by
a
department
per
week.
To
get
the
open
incidents
for
a
particular
department,
the
attribute
value
of
Department
must
be
configured
for
this
metric
with
the
name
of
the
department
that
is
desired
for
the
SLO.
See
the
Administrator’s
Guide
for
more
information
on
configuring
resource
attributes
for
an
SLA.
For
example,
suppose
that
the
help
desk
application
provides
the
sequence
of
data
for
5
incidents
in
the
central
data
warehouse
for
the
metric,
total
number
of
opened
incidents,
as
shown
in
Table
10:
Table
10.
Sample
incident
data
for
a
help
desk
application
Component
ID
Department
attribute
Start
time
Total
1001
Loan
12/21/2003
7:00:00
EST
1
1002
Online
Banking
12/22/2003
8:00:00
EST
1
1003
Loan
12/23/2003
9:00:00
EST
1
1004
Brokerage
12/26/2003
8:00:00
EST
1
1005
Loan
12/26/2003
9:00:00
EST
1
86
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
For
this
example,
suppose
that
the
Department
resource
attribute
for
the
component
type
of
Incident
is
set
to
Loan.
IBM
Tivoli
Service
Level
Advisor
evaluates
the
weekly
period
from
21Dec2003
to
27Dec2003
as
a
total
of
3
incidents,
those
with
component
IDs
of
1001,
1003,
and
1005.
The
following
additional
help
desk
metrics
are
similarly
evaluated:
v
Total
number
of
closed
incidents
v
Total
number
of
open
change
requests
v
Total
number
of
closed
change
requests
v
Total
number
of
successful
change
requests
v
Total
number
of
successful
change
requests
with
problems
v
Total
number
of
withdrawn
change
requests
v
Total
number
of
cancelled
change
requests
v
Total
number
of
unsuccessful
change
requests
Metric
Evaluator
Type:
Type
B
Percentages
Another
type
of
incident
or
change
metric
that
covers
evaluating
SLOs
is
the
percentage
of
change
requests
that
were
implemented
successfully
for
a
department
per
week.
Similar
to
how
attributes
for
Department
were
used
in
the
previous
example
for
the
Counts
calculation,
attributes
must
be
configured
in
percentages
so
that
only
a
particular
set
of
incidents
are
used
in
the
calculation.
Suppose
that
the
help
desk
application
provides
the
following
sequence
of
data,
as
shown
in
Table
11,
for
5
change
requests
in
the
central
data
warehouse
for
the
metric
named
percent
of
successful
change
requests:
Table
11.
Sample
change
request
data
for
a
help
desk
application
Component
ID
Department
attribute
Start
time
Average
1001
Brokerage
12/21/2003
7:00:00
EST
100
1002
Online
Banking
12/22/2003
8:00:00
EST
95
1003
Loan
12/23/2003
9:00:00
EST
98
1004
Brokerage
12/26/2003
8:00:00
EST
75
1005
Loan
12/26/2003
9:00:00
EST
94
Suppose
for
this
example
that
the
Department
resource
attribute
for
the
component
type
of
Change
was
set
to
Brokerage.
IBM
Tivoli
Service
Level
Advisor
evaluates
the
weekly
period
from
21Dec2003
to
27Dec2003
as
an
average
of
(100
+
75)/2
=
87.5
%.
The
following
additional
help
desk
metrics
are
similarly
evaluated:
v
Percent
of
successful
change
requests
with
problems
v
Percent
of
withdrawn
change
requests
v
Percent
of
cancelled
change
requests
v
Percent
of
unsuccessful
change
requests
Metric
Evaluator
Type:
Type
A
Appendix
A.
Introducing
Metric
Evaluators
87
Time
in
State
This
type
of
metric
generally
measures
the
amount
of
time
that
an
incident
or
change
request
spends
in
a
particular
state.
Examples
of
metrics
that
fall
under
this
metric
type
are
time
spent
reviewing
a
change
or
time
spent
repairing
a
problem.
The
help
desk
application
normally
stores
the
amount
of
time
spent
in
a
particular
state
in
the
central
data
warehouse
as
a
total
number
of
minutes
recording
the
exact
measurement
start
time.
These
kinds
of
measurements
are
also
known
as
point
in
time.
Even
though
each
individual
measurement
is
stored
as
a
total,
the
SLO
result
is
calculated
as
an
average
across
all
matching
times
in
measurement
data.
Each
entry
in
the
measurement
table
represents
a
full
time
duration
that
an
incident
or
change
request
spent
in
a
particular
state.
Suppose
that
the
measurements
shown
in
Table
12(table)
represent
time
spent
reviewing
a
change:
Table
12.
Sample
measurement
data
for
change
requests
spent
in
a
particular
state
Component
ID
Department
attribute
Start
time
Total
1001
Brokerage
12/21/2003
07:12:00
EST
2160
(1.5
days)
1002
Loan
12/22/2003
09:05:00
EST
2160
(1.5
days)
1003
Brokerage
12/25/2003
05:05:00
EST
720
(0.5
days)
1004
Brokerage
12/26/2003
14:00:00
EST
2880
(2
days)
1005
Loan
12/26/2003
9:00:00
EST
1440
(1
day)
Suppose
for
this
example
that
25Dec2003
is
a
holiday
and
therefore
a
No
Service
period.
The
average
time
spent
reviewing
changes
for
the
Brokerage
department
for
the
weekly
evaluation
period
of
21Dec2003
to
27Dec2003
is
calculated
as
follows:
(2160
+
2040)
/
2
=
2100
minutes
or
35
hours
Because
the
value
on
26Dec2003
of
2880
minutes
extends
beyond
the
end
of
the
current
evaluation
period
(21Dec2003
at
00:00
EST
to
27Dec2003
at
23:59
EST),
only
the
amount
of
time
from
the
beginning
of
the
state
up
to
the
end
of
the
evaluation
period
is
used
in
the
calculation.
So
2040
minutes,
or
the
time
from
26Dec2003
at
14:00
EST
to
12/27/03
at
23:59
EST
is
used
in
the
calculation
(10
hours
on
26Dec2003
from
14:00
EST
to
23:59
EST,
plus
24
hours
on
27Dec2003,
equals
34
hours,
or
2040
minutes).
The
measurement
record
on
25Dec2003
is
removed
from
the
calculation
because
this
time
period
is
declared
a
No
Service
time.
Metric
Evaluator
Type:
Type
B1
Time
to
State
This
type
of
metric
measures
the
amount
of
time
that
an
incident
or
change
request
spends
transitioning
from
one
state
to
another.
Examples
of
metrics
that
fall
under
this
type
are
time
from
the
open
state
to
the
close
state
of
a
problem.
The
help
desk
application
normally
stores
the
amount
of
time
spent
at
each
transition
in
the
central
data
warehouse
as
a
total
number
of
minutes
recording
the
exact
start
time
of
the
transition.
Similar
to
the
Time
in
State
calculation,
each
individual
measurement
is
stored
as
a
total
and
the
SLO
result
is
calculated
as
an
average
across
all
matching
measurement
data.
Also,
each
entry
in
the
measurement
table
represents
the
full
time
duration
that
an
incident
or
change
request
spent
in
a
particular
state.
Suppose
that
the
data
in
Table
13
on
page
89
represents
consecutive
transitions
for
the
time
to
close
an
incident
measurement.
In
addition,
assume
that
all
of
the
data
matches
the
Loan
department:
88
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Table
13.
Sample
measurement
data
for
consecutive
state
transitions
Component
ID
Department
attribute
Start
time
Total
1000
Loan
12/10/2003
00:00:00
EST
1440
(1
day)
1000
Loan
12/11/2003
00:00:00
EST
720
(0.5
day)
1000
Loan
12/11/2003
12:00:00
EST
720
(0.5
day)
1001
Loan
12/20/2003
00:00:00
EST
1440
(1
day)
1001
Loan
12/21/2003
00:00:00
EST
720
(0.5
day)
1001
Loan
12/21/2003
12:00:00
EST
720
(0.5
day)
1001
Loan
12/22/2003
00:00:00
EST
1440
(1
day)
The
average
time
spent
reviewing
changes
for
the
Loan
department
for
the
month
of
December
is:
Incident
1000:
1440
+
720
+
720
=
2880
minutes
Incident
1001:
1440
+
720
+
720
+
1440
=
4320
minutes
Average
is
(4320
+
2880)
/
2
=
3600
minutes
or
2.5
days
Metric
Evaluator
Type:
Type
B2
Business
Schedule
Considerations
For
both
Time
in
State
and
Time
to
State
incident
and
change
request
data,
the
evaluated
result
is
always
included
in
the
evaluation
period
in
which
the
final
state
transition
ends.
For
example,
if
Time
in
Open
starts
on
30Nov2003
but
leaves
the
open
state
on
01Dec2003,
it
is
recorded
against
the
SLA
evaluation
period
for
December
instead
of
for
November.
The
default
schedule
state
is
always
the
business
schedule
period
against
which
the
Time
in
State
and
Time
to
State
results
are
recorded.
So
there
is
only
a
single
breach
value
associated
with
the
default
schedule
state
that
applies
for
incident
and
change
requests.
In
addition,
the
total
time
of
the
transition
is
from
the
initial
state
to
the
end
of
the
last
state
regardless
of
whether
or
not
the
time
duration
exceeds
the
evaluation
interval.
For
example,
if
a
change
request
is
opened
in
January
and
closed
in
March
then
the
value
reported
against
the
monthly
SLA
in
March
is
3
months.
Incidents
and
Change
Requests
that
start
and
complete
during
the
same
No
Service
period
are
filtered
out
and
not
counted.
Incidents
and
Change
Requests
that
start
during
a
No
Service
period
and
extend
beyond
the
No
Service
period
are
validated
against
the
default
schedule
state.
Incidents
and
Change
requests
that
start
during
the
default
schedule
state
and
extend
into
a
No
Service
period
are
validated
against
the
default
schedule
state.
Any
time
inside
a
No
Service
period
is
removed
from
the
calculation.
Appendix
A.
Introducing
Metric
Evaluators
89
90
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Appendix
B.
Validating
Data
Points
Using
Metric
Evaluators
IBM
Tivoli
Service
Level
Advisor
supports
several
types
of
metric
evaluators,
internal
components
of
IBM
Tivoli
Service
Level
Advisor
that
evaluate
data
for
various
types
of
metrics.
Each
type
of
metric
evaluator
processes
data
points
differently.
This
appendix
provides
a
summary
of
what
each
metric
evaluator
expects
from
a
data
point
and
what
it
considers
to
be
not
valid.
Note
that
when
a
metric
evaluator
invalidates
a
data
point,
it
means
that
the
entire
data
point
is
treated,
for
the
remainder
of
the
evaluation
process,
as
if
it
never
existed.
If
a
certain
portion
of
the
data
point
is
unusable,
it
is
marked
as
indeterminate
(unknown).
Generally
the
data
point
can
still
be
used
during
some
portion
of
the
evaluation
process.
Unless
otherwise
indicated,
incorrect
data
in
data
point
fields
is
typically
caused
by
a
faulty
or
unsupported
source
application
ETL.
If
you
are
writing
a
customized
ETL
to
put
measurement
data
into
Tivoli
Data
Warehouse,
it
is
not
sufficient
to
only
adhere
to
the
enablement
rules
as
specified
for
Tivoli
Data
Warehouse.
Tivoli
Data
Warehouse
can
accept
certain
data
points
that
IBM
Tivoli
Service
Level
Advisor
does
not
currently
support,
for
example,
data
points
with
negative
or
null
values.
If
your
ETL
is
putting
unsupported
data
into
the
Tivoli
Data
Warehouse,
it
is
invalidated
in
IBM
Tivoli
Service
Level
Advisor
and
generates
many
error
messages.
If
you
apply
the
information
provided
here,
your
ETL
results
in
valid
data
points
processed
by
IBM
Tivoli
Service
Level
Advisor.
The
following
sections
discuss
the
various
metric
evaluators
that
are
supported
in
IBM
Tivoli
Service
Level
Advisor.
Metric
Evaluator
Type
A
-
Min/Max/Avg
This
Type
A
metric
evaluator
uses
data
points
stored
in
the
DYK_DM
MSMT_MMA
table.
The
objective
of
this
metric
evaluator
is
to
examine
valid
data
points
and
report
the
minimum
value
and
maximum
value
that
it
encounters.
It
also
reports
the
weighted
average
of
all
valid
data
points
(the
average
value
field
for
each
data
point
is
multiplied
by
its
sample
count
and
added
to
a
running
total.
The
total
is
then
divided
by
the
summation
of
sample
counts
of
all
of
the
data
points).
In
addition,
the
metric
evaluator
also
reports
error
count
percentage.
The
Type
A
metric
evaluator
examines
the
following
data
point
fields:
MSMT_ST
(measurement
start
time
stamp)
Must
be
within
the
evaluation
start
and
end
time
period
(inclusive).
If
not,
the
metric
evaluator
issues
an
error
message
and
might
invalidate
the
data
point.
The
IBM
Tivoli
Service
Level
Advisor
metric
evaluator
component
is
responsible
for
retrieving
data
points
from
the
database
based
on
a
date
criteria.
This
error
should
never
be
visible
to
the
user,
but
if
it
does
appear,
it
is
most
likely
an
internal
error.
MSMT_ERR_CNT
(number
of
errors
in
this
hour)
If
the
field
is
null
or
negative,
it
is
considered
to
be
indeterminate.
The
data
point
is
still
valid.
Null
fields
are
common
among
ETLs
that
do
not
support
discrete
sampling.
©
Copyright
IBM
Corp.
2002,
2004
91
MSMT_SMPL_CNT
(number
of
samples
in
this
hour)
The
metric
evaluator
handles
this
data
field
according
to
the
following
criteria:
v
If
the
field
is
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
v
If
the
field
is
null
but
the
error
count
was
not
indeterminate,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
An
ETL
can
choose
not
to
support
discrete
sampling,
in
which
case
both
fields
must
be
null.
However
if
an
ETL
reports
discrete
error
counts
then
it
must
report
discrete
sample
counts,
even
if
the
sample
count
is
0.
v
If
the
field
is
null
and
the
error
count
is
indeterminate
and
the
value
fields
are
all
indeterminate,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
Essentially
this
data
point
is
not
reporting
any
data.
v
If
the
field
is
null,
but
there
is
at
least
one
value
field
that
is
not
indeterminate,
the
metric
evaluator
uses
the
default
value
of
1
for
the
sample
count.
v
If
the
field
is
0
and
the
error
count
is
indeterminate,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
Neither
valid
sample
counts
nor
error
counts
are
being
supplied
in
this
data
point.
v
If
the
field
is
0
but
there
is
at
least
one
value
field
that
is
not
indeterminate,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
A
0
sample
field
can
only
be
used
to
supply
error
count
information.
MSMT_MIN_VAL
The
minimum
value
received
in
all
samples
for
this
hour
MSMT_MAX_VAL
The
maximum
value
received
in
all
samples
for
this
hour
MSMT_AVG_VAL
The
average
value
received
in
all
samples
for
this
hour
MSMT_xxx_VAL
The
metric
evaluator
handles
this
data
field
according
to
the
following
criteria:
v
An
ETL
can
choose
to
support
one,
two
or
all
three
of
the
previous
value
fields
(MSMT_MIN_VAL,
MSMT_MAX_VAL
and
MSMT_AVG_VAL).
v
If
a
value
field
is
null,
it
is
considered
indeterminate.
All
value
fields
can
be
indeterminate
and
still
be
a
valid
data
point
if
it
is
reporting
a
valid
error
count.
v
If
a
value
field
is
negative,
it
is
considered
indeterminate.
The
metric
evaluator
issues
an
information
message
on
this
because
it
might
indicate
a
defective
ETL.
Metric
Evaluator
Type
A
-
Transaction
Success
This
Type
A
metric
evaluator
uses
data
points
stored
in
the
DYK_DM
MSMT_MMA
table.
The
objective
of
this
metric
evaluator
is
to
report
the
percentage
of
successful
transactions
over
the
total
number
of
attempted
transactions
(a
summation
of
sample
and
error
counts.
This
metric
evaluator
does
not
use
any
of
the
value
fields
and
ignores
any
data
supplied
there.
This
metric
evaluator
examines
the
following
data
point
fields:
92
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
MSMT_ST
(measurement
start
time
stamp)
Must
be
within
the
evaluation
start
and
end
time
period.
If
not,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
The
data
collector
is
responsible
for
retrieving
data
points
from
the
database
based
on
a
date
criteria.
This
error
should
never
be
visible
to
the
user,
but
if
it
is
displayed,
it
is
most
likely
an
internal
error.
MSMT_ERR_CNT
(number
of
errors
in
this
hour)
If
the
field
is
null
or
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
MSMT_SMPL_CNT
(number
of
samples
in
this
hour)
The
metric
evaluator
handles
this
data
field
according
to
the
following
criteria:
v
If
the
field
is
null
or
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
v
If
the
field
is
0
and
the
error
count
is
also
0,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
Metric
Evaluator
Type
B
-
Total
The
Type
B
metric
evaluator
uses
data
points
stored
in
the
DYK_DM
MSMT_TOT
table.
The
objective
of
this
metric
evaluator
is
to
report
the
summation
of
the
total
value
field
in
all
valid
data
points.
Sample
and
error
counts
are
examined
but
not
used
during
metric
evaluator
evaluation
flow.
This
metric
evaluator
examines
the
following
data
point
fields:
MSMT_ST
(measurement
start
time
stamp)
Must
be
within
the
evaluation
start
and
end
time
period.
If
not,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
The
data
collector
is
responsible
for
retrieving
data
points
from
the
database
based
on
a
date
criteria.
This
error
should
never
be
visible
to
the
user,
but
if
it
is
displayed,
it
is
most
likely
an
internal
error.
MSMT_ERR_CNT
(number
of
errors
in
this
hour)
If
the
field
is
null
or
negative,
it
is
considered
indeterminate.
The
data
point
is
still
valid.
MSMT_SMPL_CNT
(number
of
samples
in
this
hour)
If
the
field
is
null
or
negative,
it
is
considered
indeterminate.
The
data
point
is
still
valid.
MSMT_TOT_VAL
(total
value
received
in
all
samples
for
this
hour)
If
the
field
is
null
or
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
Metric
Evaluator
Type
B1
and
B2
-
Problem
Management
This
metric
evaluator
uses
data
points
stored
in
the
DYK_DM
MSMT_TOT
table.
The
objective
of
this
metric
evaluator
is
to
examine
valid
data
points
and
report
the
duration
of
component
ID
events.
This
metric
evaluator
examines
the
following
data
point
fields:
MSMT_ST
(measurement
start
time
stamp)
This
field
cannot
be
null.
If
it
is,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
Appendix
B.
Validating
Data
Points
Using
Metric
Evaluators
93
MSMT_TOT_VAL
(indicates
total
duration
time
of
incidence)
The
metric
evaluator
handles
this
data
field
according
to
the
following
criteria:
v
If
the
field
is
null
or
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
v
If
the
duration
time
added
to
the
measurement
start
time
exceeds
the
evaluation
end
time,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
The
data
collector
is
responsible
for
retrieving
data
points
from
the
database
based
on
a
date
criteria.
This
error
should
never
be
visible
to
the
user,
but
if
it
is
displayed,
it
is
most
likely
an
internal
error.
COMP_ID
(tracking
item
id
–
for
instance
the
incidence
id
in
problem
mgmt
data)
If
the
field
is
null
or
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
Metric
Evaluator
Type
C
-
Availability
The
Type
C
metric
evaluator
uses
data
points
stored
in
the
DYK_DM
MSMT_AVL
table.
The
objective
of
this
metric
evaluator
is
to
use
state
transition
data
points
to
create
a
time
linear
state
transition
flow.
It
reports
on
the
overall
availability
or
unavailability
of
the
resource
as
well
as
the
metric
derived
from
the
availability
state
changes
such
as
number
of
outages,
time
to
acknowledge
and
time
to
repair.
This
metric
evaluator
examines
the
following
data
point
fields:
MSMT_ST
(measurement
start
time
stamp)
This
field
cannot
be
null.
If
it
is,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
MSMTTYP_NM
(measurement
type
name
which
maps
a
unique
state
type)
If
the
field
is
null,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
MSMT_TOT_VAL
(indicates
total
duration
time
in
the
state)
If
the
field
is
null
or
negative,
the
metric
evaluator
issues
an
error
message
and
invalidates
the
data
point.
94
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
This
appendix
describes
an
alternative
method
for
rapidly
creating
and
deleting
SLM
objects,
such
as
customers,
realms,
schedules,
offerings,
and
SLAs,
using
CLI
commands
instead
of
using
the
SLM
Administrative
Console.
You
might
prefer
to
use
this
method
of
creating
SLM
objects
if,
for
example,
you
plan
to
create
many
similar
schedules
or
SLAs,
and
you
want
to
quickly
load
them
into
IBM
Tivoli
Service
Level
Advisor
without
using
the
detailed
creation
wizard.
You
actually
do
start
the
procedure
by
using
the
SLM
Administrative
Console
in
the
usual
way
to
create
a
basic
SLM
object,
such
as
a
schedule
or
an
SLA.
After
the
object
is
successfully
created,
you
can
use
a
CLI
command
to
export
the
properties
of
the
object
to
a
plain
text
file,
where
you
can
modify
certain
parts
of
the
object
description
to
manually
create
a
new,
similar,
object.
For
example,
you
can
create
a
schedule,
export
its
properties
file,
and
then
modify
those
properties
manually
to
create
a
new
schedule
with
similar
attributes.
You
can
then
issue
another
CLI
command
to
create
the
new
modified
object
in
IBM
Tivoli
Service
Level
Advisor,
essentially
importing
the
new
SLM
object
from
its
plain
text
properties
file
form
into
the
IBM
Tivoli
Service
Level
Advisor
environment,
as
if
you
are
creating
a
new
schedule
using
the
SLM
Administrative
Console.
You
can
repeat
this
process
as
often
as
needed
to
rapidly
create
many
new
SLM
objects
in
a
short
amount
of
time.
You
can
also
write
script
files
to
bundle
up
many
CLI
commands
into
an
automated
procedure
and
create
a
mass
population
tool
that
use
can
use
to
quickly
create
a
large
amount
of
customers,
realms,
schedules,
offerings,
and
SLAs.
Minimal
error
checking
is
performed:
Because
you
are
exporting
SLM
object
property
information
into
a
plain
text
file
that
you
can
modify
manually,
there
is
always
a
chance
that
you
might
make
an
error
or
change
a
part
of
the
object
properties
that
can
result
in
a
new,
incorrect
SLM
object
when
it
is
created
in
IBM
Tivoli
Service
Level
Advisor.
Due
to
the
nature
of
this
function,
minimal
error
checking
is
performed
for
you.
If
you
have
a
detectable
error
in
your
modified
text
file
when
you
attempt
to
create
the
new
SLM
object
in
IBM
Tivoli
Service
Level
Advisor,
you
might
receive
a
general
error
message
stating
that
the
input
was
not
valid.
You
must
then
examine
your
changes
manually
and
correct
any
problems
that
might
exist.
Even
if
you
do
not
receive
an
error
message
when
you
attempt
to
create
the
new
SLM
object,
your
manual
changes
might
introduce
errors
in
IBM
Tivoli
Service
Level
Advisor
that
can
cause
unpredictable
results.
Therefore
be
careful
when
editing
these
properties
files.
If
you
experience
problems
while
attempting
to
create
a
new
SLM
object
and
the
resolution
is
not
obvious
from
examining
your
manual
changes
to
the
properties
file,
you
might
try
creating
the
object
using
the
SLM
Administrative
Console,
then
exporting
that
SLM
object
to
a
plain
text
file
and
comparing
it
to
your
manually
modified
file
to
determine
the
source
of
the
problem.
The
basic
procedure
for
creating
an
SLM
object
using
CLI
commands
includes
the
following
steps:
1.
Use
the
SLM
Administrative
Console
to
create
an
SLM
object
(customer,
realm,
schedule,
offering,
or
SLA)
in
the
usual
way,
as
described
in
this
document.
©
Copyright
IBM
Corp.
2002,
2004
95
This
SLM
object
is
used
as
an
object
template
that
you
can
then
export
to
create
one
or
more
similar
objects
with
certain
attributes
modified
from
the
original
template.
2.
Initialize
the
SLM
environment
and
use
the
scmd
som
displayAll
–o
<object>
command
to
list
the
existing
SLM
objects
that
are
currently
in
the
IBM
Tivoli
Service
Level
Advisor
environment.
You
should
see
your
SLM
object
template
in
the
list
(see
the
Command
Reference
for
more
information
on
this
CLI
command).
3.
Issue
the
scmd
som
export
command
to
export
the
properties
of
the
SLM
object
template
into
a
plain
text
file
(see
the
Command
Reference
for
more
information
on
this
CLI
command).
4.
Using
your
preferred
text
editor,
edit
the
plain
text
file
and
modify
certain
properties
(described
in
more
detail
in
following
sections)
to
create
a
new,
similar
SLM
object.
Save
the
modified
text
file
to
a
new
name.
Depending
on
the
object
that
you
are
creating,
you
might
need
to
specify
time
zone
information.
You
can
use
the
scmd
som
displayTimezones
command
to
display
a
list
of
valid
time
zones
that
you
can
select
from
to
configure
your
properties
file
as
needed.
5.
Issue
the
scmd
som
create
command
to
take
as
input
the
new
modified
text
file
and
create
a
new
SLM
object
in
IBM
Tivoli
Service
Level
Advisor.
6.
Check
the
return
message
for
a
successful
creation
result.
Note
that
you
must
have
a
successful
result
before
you
can
use
that
SLM
object
in
the
creation
of
other
objects.
For
example,
if
you
export
an
existing
schedule
and
modify
its
properties
to
create
a
new
schedule,
when
you
issue
the
scmd
som
create
command
to
create
that
new
schedule
in
IBM
Tivoli
Service
Level
Advisor,
you
must
receive
a
successful
completion
message
before
you
can
include
that
schedule
in
an
offering
(either
by
using
the
SLM
Administrative
Console
or
by
specifying
it
in
a
modified
properties
file
for
an
offering
using
the
scmd
som
create
command).
7.
Repeat
steps
4
-
6
to
create
as
many
unique
new
SLM
objects
as
you
need.
You
can
issue
the
scmd
som
cancel
and
scmd
som
delete
commands
to
cancel
SLAs
and
delete
SLM
objects
from
the
IBM
Tivoli
Service
Level
Advisor
environment.
You
can
also
manage
these
objects
using
the
existing
manage
functions
in
the
SLM
Administrative
Console.
Modifying
Properties
to
Create
New
SLM
Objects
When
you
export
an
existing
SLM
object
(realm,
customer,
schedule,
offering,
or
SLA)
into
a
text
file,
you
can
modify
various
properties
in
the
file
to
create
new
SLM
objects.
Each
type
of
SLM
object
has
its
own
set
of
unique
properties,
and
in
some
cases
one
SLM
object
is
included
in
another,
such
as
a
realm
within
a
customer,
or
a
business
schedule
within
an
offering.
You
must
be
careful
when
you
modify
the
properties
of
an
SLM
object
that
you
maintain
a
valid
structure,
and
do
not
change
certain
properties
that
would
otherwise
not
be
allowed
if
you
were
using
the
SLM
Administrative
Console.
The
properties
of
each
type
of
SLM
object
are
described
in
the
following
sections:
v
“Modifying
Properties
for
Realms”
on
page
97
v
“Modifying
Properties
for
Customers”
on
page
97
v
“Modifying
Properties
for
Schedules”
on
page
98
v
“Modifying
Properties
for
Offerings”
on
page
102
v
“Modifying
Properties
for
SLAs”
on
page
110
96
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Sample
property
files
are
also
available
in
Appendix
D,
“Sample
SLM
Object
Properties
Files,”
on
page
117.
Modifying
Properties
for
Realms
The
properties
file
for
a
realm
contains
only
three
keywords:
OriginalRealm
The
ID
of
the
original
realm
that
was
exported.
This
keyword
can
be
ignored.
When
this
properties
file
is
used
to
create
the
new
realm,
the
new
realm
ID
is
automatically
assigned.
Example:
OriginalRealm:
1000
Name
The
name
that
you
assign
to
the
new
realm.
Example:
Name:
United
States
East
Coast
Desc
An
optional
text
description
of
the
realm.
Example:
Desc:
This
is
the
realm
for
the
East
Coast
of
the
United
States
of
America.
Combining
the
above
examples,
the
content
of
the
properties
file
for
a
realm
looks
similar
to
the
following
example:
OriginalRealm:
1000
Name:
United
States
East
Coast
Desc:
This
is
the
realm
for
the
East
Coast
of
the
United
States
of
America.
If
this
realm
properties
file
was
saved
in
C:\Realm1.txt,
you
would
then
issue
the
following
command
to
create
this
realm
in
IBM
Tivoli
Service
Level
Advisor:
scmd
som
create
-o
realm
-file
C:\Realm1.txt
You
must
use
the
scmd
som
create
command
to
successfully
add
this
realm
to
the
IBM
Tivoli
Service
Level
Advisor
environment
before
you
can
associate
it
with
a
customer.
Modifying
Properties
for
Customers
The
properties
file
for
a
customer
contains
only
four
keywords:
OriginalCustomer
The
ID
of
the
original
customer
that
was
exported.
This
keyword
can
be
ignored.
When
this
properties
file
is
used
to
create
the
new
customer,
the
new
customer
ID
is
automatically
assigned.
Example:
OriginalCustomer:
1001
Name
The
name
that
you
assign
to
the
new
customer.
Example:
Name:
AmplBank
Loan
Department
Desc
An
optional
text
description
of
the
customer.
Example:
Desc:
This
is
the
customer
name
for
the
Loan
department
at
AmplBank.
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
97
RealmName
This
is
the
name
of
a
realm
associated
with
this
customer.
The
realm
must
already
be
created
in
IBM
Tivoli
Service
Level
Advisor
before
you
can
include
it
in
this
customer
properties
file.
You
can
specify
more
than
one
realm
to
associate
with
this
customer,
but
each
realm
must
be
specified
on
a
separate
line,
starting
with
the
RealmName
keyword.
Example:
RealmName:
Realm1
RealmName:
Realm2
Combining
the
above
examples,
the
content
of
the
properties
file
for
a
customer
looks
similar
to
the
following
example:
OriginalCustomer:
1001
Name:
AmplBank
Loan
Department
Desc:
This
is
the
customer
name
for
the
Loan
department
at
AmplBank.
RealmName:
Realm1
RealmName:
Realm2
If
this
customer
properties
file
is
saved
in
C:\Customer1.txt,
you
can
then
issue
the
following
command
to
create
this
customer
in
IBM
Tivoli
Service
Level
Advisor:
scmd
som
create
-o
customer
-file
C:\Customer1.txt
You
must
use
the
scmd
som
create
command
to
successfully
add
this
customer
to
the
IBM
Tivoli
Service
Level
Advisor
environment
before
you
can
include
it
in
an
SLA.
Modifying
Properties
for
Schedules
The
properties
file
for
a
schedule
contains
its
own
set
of
keywords,
with
more
choices
to
consider.
You
need
to
specify
if
the
schedule
is
a
business
schedule
or
an
auxiliary
schedule.
If
the
schedule
is
a
business
schedule,
you
can
optionally
include
one
or
more
existing
auxiliary
schedules,
and
specify
a
default
schedule
state.
Finally,
you
can
specify
one
or
more
schedule
periods
for
the
schedule,
using
a
set
of
keywords
to
define
the
period
schedule
state,
its
start
and
end
times
and
time
zone,
and
how
frequently
the
period
occurs
in
the
schedule.
The
properties
file
for
a
schedule
includes
the
following
keywords:
OriginalSchedule
The
ID
of
the
original
schedule
that
was
exported.
This
keyword
can
be
ignored.
When
this
properties
file
is
used
to
create
the
new
schedule,
the
new
schedule
ID
is
automatically
assigned.
Example:
OriginalSchedule:
1012
Name
The
name
that
you
assign
to
the
new
schedule.
Example:
Name:
Weekly
First
Shift
Schedule
Desc
An
optional
text
description
of
the
schedule.
Example:
Desc:
Schedule
for
First
Shift
operations
during
the
normal
work
week.
98
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
IsAuxiliary
This
keyword
specifies
if
the
schedule
to
be
created
is
a
business
schedule
or
an
auxiliary
schedule.
Valid
values
are:
v
true:
the
schedule
is
an
auxiliary
schedule
v
false:
the
schedule
is
a
business
schedule
If
the
schedule
being
created
is
an
auxiliary
schedule
(the
IsAuxiliary
keyword
is
set
to
true),
then
this
properties
file
cannot
include
other
schedules,
and
cannot
specify
a
default
schedule
state.
Example:
IsAuxiliary:
false
AuxiliarySchedule
If
this
properties
file
is
for
a
business
schedule
(the
IsAuxiliary
keyword
is
set
to
false),
you
can
use
this
keyword
to
optionally
specify
the
name
of
one
or
more
existing
auxiliary
schedules.
Each
auxiliary
schedule
name
must
be
specified
on
a
separate
line,
starting
with
the
AuxiliarySchedule
keyword.
Note
that
the
order
of
these
schedule
names
is
important.
Refer
to
“Managing
Overlapping
Periods”
on
page
29
for
more
information
on
setting
the
order
of
schedules
and
periods.
Example:
AuxiliarySchedule:
AuxiliarySched1
AuxiliarySchedule:
AuxiliarySched2
These
auxiliary
schedules
must
already
be
created
in
IBM
Tivoli
Service
Level
Advisor
before
you
can
include
them
in
this
business
schedule.
Note:
If
this
properties
file
is
for
an
auxiliary
schedule,
do
not
specify
an
AuxiliarySchedule
keyword.
Auxiliary
schedules
cannot
contain
other
auxiliary
schedules.
DefaultState
If
this
properties
file
is
for
a
business
schedule
(the
IsAuxiliary
keyword
is
set
to
false),
you
can
use
this
keyword
to
specify
the
default
schedule
state
that
applies
for
any
time
period
in
the
schedule
that
is
not
otherwise
defined.
The
following
values
for
this
keyword
are
valid:
v
SCHEDULE_PEAK
v
SCHEDULE_CRITICAL
v
SCHEDULE_PRIME
v
SCHEDULE_STANDARD
v
SCHEDULE_LOW_IMPACT
v
SCHEDULE_OFF_HOURS
v
NO_SERVICE
Example:
DefaultState:
SCHEDULE_CRITICAL
If
this
properties
file
is
for
an
auxiliary
schedule,
do
not
specify
a
DefaultState
keyword.
Auxiliary
schedules
cannot
have
a
default
schedule
state.
Note
that
these
default
state
names
can
be
changed
by
setting
user
preferences
to
define
alternate
names
for
these
states
(see
“Changing
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
99
Schedule
State
Names”
on
page
31).
If
the
state
names
are
modified,
they
must
be
manually
mapped
back
to
these
default
state
names.
In
addition
to
the
above
keywords,
you
can
use
the
following
set
of
keywords
to
define
each
unique
schedule
period
for
the
schedule:
PeriodState
This
is
the
schedule
state
that
applies
for
the
duration
of
the
period.
Valid
values
are
the
same
as
for
the
DefaultState
keyword.
Example:
PeriodState:
SCHEDULE_STANDARD
PeriodStart
This
is
the
starting
time
for
the
period,
specified
in
the
format
HH:00,
where
HH
is
a
2-digit
integer
value
from
00
to
23.
Note
that
the
start
time
always
occurs
at
the
start
of
the
hour
(00
minutes).
Example:
PeriodStart:
02:00
PeriodEnd
This
is
the
ending
time
for
the
period,
specified
in
the
format
HH:59,
where
HH
is
a
2-digit
integer
value
from
00
to
23.
Note
that
the
ending
time
always
ends
at
59
minutes
past
the
hour.
Example:
PeriodEnd:
17:59
PeriodTimeZone
This
is
the
time
zone
for
the
specified
start
and
end
times
for
the
period.
Valid
values
include
America/New_York,
EST,
CST,
MST,
PST,
GMT,
and
many
others.
You
can
find
additional
valid
values
by
issuing
the
scmd
som
displayTimezones
command.
Example:
PeriodTimeZone:
America/Los_Angeles
Frequency
This
keyword
specifies
how
frequently
this
schedule
period
occurs.
The
following
values
are
valid:
v
Daily
If
you
specify
a
frequency
of
Daily,
no
other
keywords
are
required.
Example:
Frequency:
Daily
v
Weekly
If
you
specify
a
frequency
of
Weekly,
you
must
also
specify
the
Day
keyword,
which
can
have
one
of
the
following
valid
values:
Mon,
Tue,
Wed,
Thu,
Fri,
Sat,
Sun.
Example:
Frequency:
Weekly
Day:
Tue
You
can
specify
more
than
one
day
of
the
week
by
specifying
each
day
on
a
separate
line,
starting
with
the
Day
keyword.
Example:
Frequency:
Weekly
Day:
Tue
Day:
Thu
Day:
Fri
100
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
v
Monthly
If
you
specify
a
frequency
of
Monthly,
you
must
also
specify
the
Month
keyword,
which
can
have
one
of
the
following
valid
values:
Jan,
Feb,
Mar,
Apr,
May,
Jun,
Jul,
Aug,
Sep,
Oct,
Nov,
Dec.
You
must
also
specify
either
of
the
following
parameters:
–
The
DayOfMonth
keyword,
with
a
valid
integer
value
from
1
to
31,
or
the
word
Last.
Example:
Frequency:
Monthly
Month:
Apr
DayOfMonth:
15
–
The
DayInterval
and
Day
keyword
combination.
Valid
values
for
DayInterval
are
1st,
2nd,
3rd,
4th,
and
Last.
In
this
case
Day
is
a
valid
integer
value
from
1
to
31.
Example:
Frequency:
Monthly
Month:
May
DayInterval:
2nd
Day:
22
You
can
specify
more
than
one
month
by
specifying
each
month
on
a
separate
line,
starting
with
the
Month
keyword.
Example:
Frequency:
Monthly
Month:
Jan
Month:
May
Month:
Sep
DayOfMonth:
Last
v
Single_Date
If
you
specify
a
Frequency
of
Single_Date,
you
must
specify
Month,
Day,
and
Year
keywords.
Example:
Frequency:
Single_Date
Month:
Jan
Day:
21
Year:
2004
For
example,
specify
a
schedule
period
with
a
monthly
interval,
using
a
Standard
schedule
state
from
22:00
to
22:59
EST
on
the
third
Wednesday
of
January,
March,
and
May:
PeriodState:
SCHEDULE_STANDARD
PeriodStart:
22:00
PeriodEnd:
22:59
PeriodTimeZone:
EST
Frequency:
Monthly
DayInterval:
3rd
Day:
Wed
Month:
Jan
Month:
Mar
Month:
May
Combining
some
of
the
above
examples,
the
contents
of
the
properties
file
for
a
schedule
might
look
similar
to
the
following
example:
OriginalSchedule:
1012
Name:
Weekly
First
Shift
Schedule
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
101
Desc:
This
is
the
schedule
for
First
Shift
operations
during
the
typical
work
week.
IsAuxiliary:
false
AuxiliarySchedule:
AuxiliarySched1
AuxiliarySchedule:
AuxiliarySched2
DefaultState:
SCHEDULE_CRITICAL
//Standard
Schedule
Period
Definition
PeriodState:
SCHEDULE_STANDARD
PeriodStart:
09:00
PeriodEnd:
16:59
PeriodTimeZone:
America/Los_Angeles
Frequency:
Weekly
Day:
Tue
Day:
Thu
Day:
Fri
//Low
Impact
Schedule
Period
Definition
PeriodState:
SCHEDULE_LOW_IMPACT
PeriodStart:
02:00
PeriodEnd:
16:59
PeriodTimeZone:
America/Los_Angeles
Frequency:
Monthly
Month:
May
DayInterval:
2nd
Day:
22
Note:
In
the
examples
in
this
appendix,
lines
that
begin
with
two
forward
slashes
(//)
are
comments.
Each
set
of
keywords
that
defines
a
unique
period
should
be
placed
in
the
file
keeping
in
mind
that
order
of
placement
is
important.
Refer
to
“Managing
Overlapping
Periods”
on
page
29
for
more
information
on
setting
the
order
of
schedules
and
periods.
If
this
schedule
properties
file
is
saved
in
C:\MySchedule.txt,
you
can
issue
the
following
command
to
create
this
schedule
in
IBM
Tivoli
Service
Level
Advisor:
scmd
som
create
-o
schedule
-file
C:\MySchedule.txt
You
must
use
the
scmd
som
create
command
to
successfully
add
this
schedule
to
the
IBM
Tivoli
Service
Level
Advisor
environment
before
you
can
include
it
in
an
offering.
Modifying
Properties
for
Offerings
The
properties
file
for
an
offering
is
more
complex
than
for
customers,
realm,
and
schedules.
There
are
still
the
basic
keywords
such
as
ID,
name,
and
description,
and
other
keywords
that
specify
the
name
of
an
included
business
schedule,
the
state
of
the
offering
(Draft
or
Published
state),
and
the
SLA
type
that
this
offering
is
intended
for
(internal,
external,
or
outsourced).
You
can
optionally
specify
one
or
more
existing
SLAs
to
include
in
this
offering,
such
that
when
this
offering
is
itself
included
in
an
SLA,
the
result
is
a
tiered
SLA
structure.
102
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Of
course,
any
business
schedule
or
SLA
that
you
specify
to
include
in
this
offering
must
already
be
created
in
IBM
Tivoli
Service
Level
Advisor,
either
by
using
the
SLM
Administrative
Console
or
by
creating
these
SLM
objects
manually
using
these
CLI
commands
and
properties
files.
When
you
create
an
offering
using
the
SLM
Administrative
Console,
the
offering
creation
process
includes
the
creation
of
one
or
more
offering
components.
An
offering
component
contains
the
definition
for
a
resource
type
that
you
select
from
the
list
of
available
resource
types
in
the
SLM
Database.
Based
on
the
resource
type
that
you
select,
IBM
Tivoli
Service
Level
Advisor
then
determines
the
proper
measurement
source
code
for
the
associated
registered
source
application,
and
helps
you
to
select
a
metric
that
is
valid
for
that
resource
type,
and
then
configure
that
metric
by
specifying
appropriate
breach
values,
determining
evaluation
and
trend
frequencies,
and
selecting
other
advanced
settings.
The
power
and
convenience
of
creating
offerings
using
the
SLM
Administrative
Console
is
centered
in
this
capability
to
filter
all
of
the
possible
resource
and
component
type
information
in
the
SLM
Database
and
present
you
with
structured
menus
of
valid
selections
to
help
you
correctly
create
the
offering.
In
the
properties
file
for
an
offering
object,
offering
components
are
represented
by
the
OfferingComp
keyword.
The
OfferingComp
keyword
is
the
first
of
a
collection
of
keywords
that
defines
the
resource
type,
the
measurement
source
code,
and
one
or
more
associated
metrics
with
their
associated
breach
values
and
other
settings.
Specifying
values
for
these
keywords,
however,
requires
you
to
be
very
familiar
with
the
specific
component
name
and
measurement
source
code,
the
valid
metrics
that
are
appropriate
for
this
component
type,
the
breach
values
that
are
appropriate
for
the
type
of
metric
that
you
specify,
and
knowing
how
to
specify
appropriate
breach
values
for
each
schedule
state
in
the
included
business
schedule.
You
no
longer
have
the
filtering
capability
of
the
SLM
Administrative
Console
to
assist
you
in
making
these
choices.
This
is
where
creating
a
template
SLM
object
using
the
SLM
Administrative
Console
provides
the
most
benefit.
If
you
are
planning
to
create
a
number
of
similar
offerings,
for
example,
a
set
of
offerings
that
include
the
same
resource
types
and
metrics,
but
differ
only
in
the
breach
value
settings
for
each
offering,
then
you
can
first
use
the
Create
Offering
page
of
the
SLM
Administrative
Console
to
create
a
template
offering,
specifying
the
preferred
resource
types
and
metrics
and
other
settings.
Then
export
that
offering
to
a
properties
file,
and
modify
the
resulting
file,
changing
only
the
breach
value
settings
and
other
basic
definitions,
such
as
the
offering
name
and
description.
You
find
that
the
various
keywords
that
make
up
the
offering
component
are
already
configured
for
you,
with
the
correct
offering
component
name
and
resource
type,
and
valid
metrics
and
associated
breach
values
already
defined.
The
following
specific
keywords
are
included
in
the
properties
file
for
an
offering:
OriginalOffering
The
ID
of
the
original
offering
that
was
exported.
This
keyword
can
be
ignored.
When
this
properties
file
is
used
to
create
the
new
offering,
the
new
offering
ID
is
automatically
assigned.
Example:
OriginalOffering:
1003
Name
The
name
that
you
assign
to
the
new
offering.
Example:
Name:
Gold
Level
Offering
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
103
Desc
An
optional
text
description
of
the
offering.
Example:
Desc:
Highest
availability
during
first
shift
operations.
ScheduleName
This
is
the
name
of
the
business
schedule
to
be
included
in
this
offering.
If
you
are
modifying
a
properties
file
for
an
offering
that
was
created
in
the
SLM
Administrative
Console,
this
keyword
contains
the
name
of
the
schedule
that
was
previously
included.
If
possible,
you
should
plan
to
use
this
same
schedule
in
the
new
offering.
If
you
change
this
keyword
to
refer
to
a
different
business
schedule,
note
the
following
information:
v
The
business
schedule
must
already
exist
in
IBM
Tivoli
Service
Level
Advisor
before
including
it
in
this
offering.
v
The
schedule
that
you
select
might
not
have
the
same
set
of
schedule
states
defined
for
its
schedule
periods.
When
you
define
breach
value
settings,
you
must
provide
breach
values
for
each
unique
schedule
state
in
the
schedule.
You
should
closely
examine
any
differences
between
the
previous
schedule
and
the
new
schedule
to
determine
what
breach
values
might
need
to
be
specified
in
this
properties
file.
Example:
ScheduleName:
Weekly
Schedule
OfferingState
This
is
the
state
of
the
offering
when
you
create
it
in
IBM
Tivoli
Service
Level
Advisor.
Offerings
can
be
in
the
Published
or
Draft
state.
Valid
values
for
this
keyword
include:
v
STATE_PUBLISHED
v
STATE_DRAFT
If
you
specify
the
STATE_DRAFT
value,
this
offering
is
created
in
Draft
state
in
the
SLM
database.
You
then
need
to
use
the
Manage
Offerings
page
of
the
SLM
Administrative
Console
to
publish
the
offering
before
it
can
be
available
for
inclusion
in
SLAs.
Example:
OfferingState:
STATE_PUBLISHED
SlaType
This
keyword
indicates
the
type
of
SLA
for
which
this
offering
is
intended.
Valid
values
for
this
keyword
include:
v
TYPE_INTERNAL
v
TYPE_EXTERNAL
v
TYPE_OUTSOURCED
Example:
SlaType:
TYPE_EXTERNAL
IncludedSLA
This
optional
keyword
specifies
the
name
of
an
existing
SLA
to
be
included
in
this
offering.
If
this
keyword
is
specified,
then
when
this
offering
is
published
and
included
in
another
SLA,
the
resulting
structure
is
referred
to
as
a
tiered
SLA,
or
an
SLA
within
an
SLA.
Example:
IncludedSLA:
AmplBank
Loan
SLA
104
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
You
can
include
multiple
SLAs
in
the
offering,
specifying
each
SLA
name
on
a
separate
line,
starting
with
the
IncludedSLA
keyword.
Example:
IncludedSLA:
SLA
1000
IncludedSLA:
Response
Time
SLA
Restriction:There
are
restrictions
on
the
types
of
SLAs
that
can
be
included
in
other
SLAs
to
create
tiered
SLAs:
v
External
SLAs
can
contain
any
number
of
external,
internal,
or
outsourced
SLAs.
v
Internal
SLAs
can
include
any
number
of
internal
or
outsourced
SLAs,
but
not
external
SLAs.
v
Outsourced
SLAs
cannot
include
any
SLAs.
These
restrictions
are
not
checked
when
the
offering
is
created
from
this
properties
file.
Be
sure
that
you
understand
what
types
of
SLAs
you
are
including
in
this
offering.
In
addition
to
the
above
set
of
keywords,
the
properties
file
for
an
offering
includes
the
following
set
of
keywords
for
each
offering
component
that
was
included
in
the
original
offering:
OfferingComp
This
is
the
name
of
the
offering
component.
It
must
match
the
name
of
an
active
service
element
on
your
system.
You
can
use
the
scmd
sdc
displayActiveServiceElements
command
(see
the
Command
Reference
for
more
information)
to
list
the
active
service
elements
on
your
system.
Do
not
modify
this
keyword
manually:
If
you
need
to
specify
a
different
offering
component,
create
a
new
template
SLM
object
using
the
SLM
Administrative
Console,
and
select
the
preferred
resource
type
and
metric
information
from
the
offering
creation
wizard.
Then
export
and
modify
that
properties
file
as
needed.
Example:
OfferingComp:
CompTyp.CompTyp_Nm.BWM_QOS
OfferingCompName
This
keyword
specifies
the
component
name
for
this
offering
component.
It
must
be
unique
within
the
offering.
Example:
OfferingCompName:
QoS
Component
OfferingCompDesc
This
keyword
specifies
a
text
description
for
the
component
name.
Example:
OfferingCompDesc:
QoS
Component
Description
OfferingCompSource
This
keyword
indicates
the
measurement
source
code
for
the
source
application
that
is
providing
measurement
data
for
this
component.
Example:
OfferingCompSource:
BWM
Do
not
modify
this
keyword
manually:
If
you
need
to
specify
a
different
measurement
source
code,
create
a
new
template
SLM
object
using
the
SLM
Administrative
Console,
and
select
the
resource
type
and
metric
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
105
information
from
the
offering
creation
wizard.
Then
export
and
modify
that
properties
file
as
needed.
This
keyword
should
then
be
filled
in
with
the
correct
value
for
you.
Within
each
offering
component
in
the
offering,
one
or
more
metrics
is
defined
and
configured.
In
the
properties
file,
each
metric
in
the
offering
component
is
specified
with
the
following
set
of
keywords:
Metric
This
is
the
name
of
a
metric
that
exists
for
the
specified
offering
component.
Example:
Metric:
MsmtTyp.MsmtTyp_Nm.Round
Trip
Time
Do
not
modify
this
keyword
manually:
If
you
need
to
specify
a
different
metric
for
the
specified
offering
component,
create
a
new
template
SLM
object
using
the
SLM
Administrative
Console,
and
select
the
resource
type
and
metric
information
from
the
offering
creation
wizard.
Then
export
and
modify
that
properties
file
as
needed.
This
keyword
should
then
be
filled
in
with
the
correct
value
for
you.
Breach
Values
Breach
values
are
actually
represented
by
a
combination
of
keywords
that
specify
minimum,
maximum,
average,
total,
and
violation
condition
values
for
each
unique
schedule
state
that
is
defined
in
the
business
schedule
that
is
included
in
this
offering.
For
example,
the
Peak
schedule
state
has
the
following
keywords
that
define
its
breach
values:
v
PeakMin
v
PeakMax
v
PeakAvg
v
PeakTotal
v
PeakViolCond
Breach
value
keywords
for
other
schedule
states
are
similarly
named.
You
can
specify
one
or
more
of
the
minimum,
maximum,
or
average
keywords
for
each
schedule
state,
with
the
values
specified
in
floating
point
decimal
form
(for
example,
5000.0).
The
value
for
aViolation
Condition
keyword
such
as
PeakViolCond,
can
be
either
ascending
or
descending.
Do
not
modify
the
combination
of
breach
value
keywords
that
are
defined
in
the
original
object
properties
file,
because
these
are
determined
to
be
valid
for
the
selected
metric.
You
can
modify
the
keyword
values
to
create
new
breach
values,
but
if
you
choose
to
add
or
remove
specific
breach
value
keywords,
you
might
introduce
unpredictable
results
or
errors
in
later
evaluations.
Keep
in
mind
that
you
must
specify
appropriate
breach
values
for
every
unique
schedule
state
defined
in
the
included
schedule.
If
you
need
to
specify
a
different
set
of
breach
values
for
this
metric,
you
should
create
a
new
template
SLM
object
using
the
SLM
Administrative
Console,
and
select
the
preferred
schedule,
resource
type
and
metric
information
from
the
offering
creation
wizard,
and
then
export
and
modify
that
properties
file
as
needed.
The
breach
value
keywords
of
interest
should
then
be
already
included,
and
you
can
then
just
change
the
specific
values
of
the
keywords.
For
example
(note
that
the
maximum
and
total
keywords
for
the
Critical
schedule
state
are
commented
out):
106
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
CriticalMin:
7000.0
//CriticalMax:
9000.0
CriticalAvg:
8000.0
//CriticalTotal:
7900.0
CriticalViolCond:
descending
InternalUseOnly
This
keyword
indicates
if
this
metric
is
to
be
included
in
external
reports
to
customers.
Valid
values
are
yes
or
no.
Example:
InternalUseOnly:
no
EvalIntervalType
This
keyword
specifies
the
frequency
of
evaluations
for
this
metric.
You
can
specify
the
following
valid
values:
v
Hourly
(when
enabled)
v
Daily
v
Weekly
v
Monthly
If
you
specify
an
EvalIntervalType
keyword
with
a
value
of
Hourly,
you
can
specify
an
additional
EvalXHours
keyword
that
defines
the
hourly
frequency,
such
as
every
2
hours,
every
4
hours,
and
so
on.
The
valid
values
for
this
keyword
include
1,
2,
3,
4,
6,
8,
or
12.
Example:
EvalIntervalType:
Daily
or
EvalIntervalType:
Hourly
EvalXHours:
2
TrendIntervalType
This
keyword
specifies
the
frequency
for
trend
analysis
for
this
metric.
Valid
values
include:
v
Daily
v
Weekly
v
Monthly
The
frequency
specified
must
be
more
frequent
than
the
value
specified
for
EvalIntervalType.
For
example,
if
EvalIntervalType
is
specified
as
Weekly,
then
TrendIntervalType
must
be
specified
as
Daily.
Example:
TrendIntervalType:
Daily
EvalIntermediateType
This
optional
keyword
specifies
the
frequency
of
intermediate
evaluations.
Valid
values
include:
v
Hourly
v
Daily
The
frequency
specified
must
be
more
frequent
than
the
value
specified
for
EvalIntervalType.
For
example,
if
EvalIntervalType
is
specified
as
Daily,
then
EvalIntermediateType
must
be
specified
as
Hourly.
If
you
specify
an
EvaluationIntermediateType
keyword
with
a
value
of
Hourly,
you
can
specify
an
additional
EvalXHours
keyword
that
defines
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
107
the
hourly
frequency,
such
as
every
2
hours,
every
4
hours,
and
so
on.
The
valid
values
for
this
keyword
include
1,
2,
3,
4,
6,
8,
or
12.
Example:
EvalIntermediateType:
Hourly
EvalXHours:
4
TrendType
This
optional
keyword
indicates
the
type
of
trending
analysis
that
is
performed
for
this
metric.
Valid
values
include:
v
TYPE_CONTINUOUS
(this
is
the
default
of
not
specified)
v
TYPE_INPERIOD
Example:
TrendType:
TYPE_CONTINUOUS
ExpectedData
This
optional
keyword
indicates
whether
or
not
data
is
expected
for
every
evaluation
period.
Valid
values
are
yes
or
no.
If
this
keyword
is
set
to
yes,
then
any
evaluation
period
that
has
no
measurement
data
is
considered
to
be
an
error
condition.
Example:
ExpectedData:
Yes
You
can
create
additional
metrics
within
the
specified
offering
component
by
copying
the
above
set
of
keywords,
from
Metric
to
ExpectedData,
and
appending
them
after
the
previous
metric
definition,
then
modifying
these
keywords
as
needed.
You
can
create
additional
offering
components
within
the
offering
by
copying
the
above
set
of
keywords,
from
OfferingComp
to
the
last
ExpectedData
keyword
for
the
last
defined
metric,
and
appending
them
after
the
previous
offering
component
definition,
then
modifying
these
keywords
as
needed.
Combining
some
of
the
above
examples,
the
content
of
the
properties
file
for
an
offering
looks
similar
to
the
following
example:
OriginalOffering:
1003
Name:
Gold
Level
Offering
Desc:
Highest
availability
during
first
shift
operations.
ScheduleName:
Weekly
Schedule
OfferingState:
STATE_PUBLISHED
SlaType:
TYPE_EXTERNAL
IncludedSLA:
SLA
1000
IncludedSLA:
Response
Time
SLA
//
//OFFERING
COMPONENT
DEFINITION
FOR
QoS
Component
OfferingComp:
CompTyp.CompTyp_Nm.BWM_QOS
OfferingCompName:
QoS
Component
OfferingCompDesc:
QoS
Component
Description
OfferingCompSource:
BWM
//METRIC
DEFINITION
FOR
ROUND
TRIP
TIME
Metric:
MsmtTyp.MsmtTyp_Nm.Round
Trip
Time
108
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
CriticalMin:
7000.0
//CriticalMax:
9000.0
CriticalAvg:
8000.0
//CriticalTotal:
7900.0
CriticalViolCond:
descending
InternalUseOnly:
no
EvalIntervalType:
Daily
TrendIntervalType:
Daily
EvalIntermediateType:
Hourly
TrendType:
TYPE_CONTINUOUS
ExpectedData:
Yes
//END
OF
METRIC
DEFINITION
//
//METRIC
DEFINITION
FOR
(Metric
name
here)
Metric:
(name
here)
//PeakMin:
nnnn.0
PeakMax:
5000.0
PeakAvg:
4500.0
//PeakTotal:
7900.0
PeakViolCond:
ascending
//StandardMin:
nnnn.0
StandardMax:
6000.0
StandardAvg:
5500.0
//StandardTotal:
7900.0
StandardViolCond:
descending
InternalUseOnly:
no
EvalIntervalType:
Monthly
TrendIntervalType:
Daily
//EvalIntermediateType:
Hourly
//TrendType:
TYPE_CONTINUOUS
//ExpectedData:
Yes
//END
OF
METRIC
DEFINITION
//END
OF
OFFERING
COMPONENT
DEFINITION
//
//OFFERING
COMPONENT
DEFINITION
FOR
(Name
here)
OfferingComp:
(Name
here)
OfferingCompName:
(Name
here)
OfferingCompDesc:
(Description
here)
OfferingCompSource:
(Measurement
source
code
here)
//METRIC
DEFINITION
FOR
(Metric
name
here)
Metric:
(Metric
name
here)
(and
so
on)
If
this
offering
properties
file
was
saved
in
C:\GoldOffering.txt,
you
would
issue
the
following
command
to
create
this
offering
in
IBM
Tivoli
Service
Level
Advisor:
scmd
som
create
-o
offering
-file
C:\GoldOffering.txt
You
must
use
the
scmd
som
create
command
to
successfully
add
this
published
offering
to
the
IBM
Tivoli
Service
Level
Advisor
environment
before
you
can
include
it
in
an
SLA.
If
you
create
an
offering
in
the
Draft
state
usingthis
method,
you
must
use
the
SLM
Administrative
Console
to
put
the
offering
in
the
Published
state
before
you
can
include
it
in
an
SLA.
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
109
Modifying
Properties
for
SLAs
The
properties
file
for
an
SLA
is
also
one
of
the
more
complex
set
of
properties,
similar
to
that
of
an
offering.
In
addition
to
the
basic
ID,
name,
and
description
keywords,
the
SLA
properties
file
contains
additional
keywords
that
specify
SLA
start
date,
the
time
zone
for
when
evaluations
occur,
the
name
of
the
customer
and
offering
to
be
associated
with
this
SLA,
and
then
one
or
more
service
elements
that
define
a
specific
resource
or
a
filtered
collection
of
resources
associated
with
the
level
of
service
as
specified
by
the
included
offering.
Because
you
are
including
other
SLM
objects
(customer
and
offering)
in
the
SLA
properties
file,
these
SLM
objects
must
already
be
created
in
IBM
Tivoli
Service
Level
Advisor
before
you
can
include
them
in
an
SLA.
Similar
to
modifying
properties
files
for
offerings,
it
is
recommended
that
you
first
create
a
template
SLA
using
the
Create
SLA
page
of
the
SLM
Administrative
Console,
specifying
schedule,
offering
and
resource
information.
Then
export
this
SLA
to
a
plain
text
properties
file
and
modify
it
as
needed
to
create
similar
but
unique
SLAs
for
your
enterprise
business
needs.
The
following
specific
keywords
are
included
in
the
properties
file
for
an
SLA:
OriginalSLA
This
keyword
specifies
the
ID
of
the
original
SLA
that
was
exported.
This
keyword
can
be
ignored.
When
this
properties
file
is
used
to
create
the
new
SLA,
the
new
SLA
ID
is
automatically
assigned.
Example:
OriginalSLA:
1000
Name
The
name
that
you
assign
to
the
new
SLA.
Example:
Name:
AmplBank
Loan
SLA
Desc
An
optional
text
description
of
the
SLA.
Example:
Desc:
SLA
between
IT
and
the
AmplBank
Loan
Office,
established
5/26/2004.
StartDate
This
optional
keyword
specifies
the
date
that
the
SLA
is
considered
to
be
active.
If
this
keyword
is
not
specified,
the
current
date
is
assumed.
The
date
value
must
be
specified
in
MM/DD/YYYY
format.
For
example:
StartDate:
06/01/2004
If
you
specify
a
start
date
prior
to
the
current
date
that
causes
reevaluations
to
occur,
performance
is
considerably
slower
during
this
processing
time
because
the
SLAs
are
processed
sequentially.
TimeZone
This
optional
keyword
specifies
the
time
zone
that
is
used
for
evaluations
of
this
SLA.
If
this
keyword
is
not
specified,
the
time
zone
where
the
SLM
Server
is
located
is
used.
Valid
values
for
this
keyword
include
America/New_York,
EST,
CST,
MST,
PST,
GMT,
and
many
others.
You
can
find
additional
valid
values
by
issuing
the
scmd
som
displayTimezones
command
(see
the
Command
Reference
for
more
information).
Example:
TimeZone:
CST
110
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
CustomerName
This
keyword
specifies
the
customer
that
is
associated
with
this
SLA.
The
customer
object
must
already
be
created
in
the
SLM
Database.
Example:
CustomerName:
AmplBank
Loan
Dept
OfferingName
This
keyword
specifies
the
name
of
the
offering
to
be
included
in
this
SLA.
The
offering
must
already
be
created
in
the
SLM
Database.
Example:
OfferingName:
Gold
Level
Offering
OfferingCompName
This
keyword
specifies
the
name
of
one
of
the
offering
components
that
was
specified
in
the
offering
that
is
included
in
this
SLA.
If
you
specified
the
OfferingCompName
keyword
in
the
offering
component
definition,
use
that
name
here.
Otherwise
use
the
value
that
was
specified
for
the
OfferingComp
keyword
in
the
offering.
Example:
OfferingCompName:
QoS
Component
You
can
specify
additional
offering
components
in
the
SLA
by
copying
the
set
of
keywords
starting
with
OfferingCompName
and
ending
with
either
the
ResourceName
or
FilterValue
keyword
(whichever
was
specified,
as
described
below).
ResourceName
This
keyword
specifies
a
single
resource
name
for
this
SLA.
You
can
specify
more
than
one
resource
for
the
offering
component,
but
each
resource
must
be
on
a
separate
line
and
start
with
the
ResourceName
keyword.
For
example:
ResourceName:
/BWM_EP_#5/BWM_QOS_#1
ResourceName:
/BWM_EP_#7/BWM_QOS_#3
If
you
are
not
sure
of
the
exact
resource
name
you
might
try
using
the
SLM
Administrative
Console
to
view
suitable
resource
names
and
copy
them
from
the
selection
menus.
If
you
do
not
specify
a
ResourceName
keyword
for
one
or
more
specific
resources,
you
can
create
a
dynamic
list
of
resources
defined
by
a
set
of
filter
keywords.
Each
filter
is
defined
by
at
least
seven
filter
keywords:
FilterName
This
keyword
specifies
the
name
of
the
filter.
For
example:
FilterName:
MyQoSFilter
FilterDesc
This
keyword
specifies
a
text
description
for
the
filter.
For
example:
FilterDesc:
This
filter
matches
resources
with
"BWM_QOS"
in
the
name.
AttrSetDoAnd
This
keyword
indicates
how
multiple
filter
groups
are
handled,
when
present.
Filters
are
either
logically
ANDed
together
or
logically
ORed
together.
Valid
values
for
this
keyword
include:
v
true
(means
to
AND
the
filters
together)
v
false
(means
to
OR
the
filters
together)
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
111
Example:
AttrSetDoAnd:
true
FilterAttr
This
keyword
and
the
next
three
keywords
should
always
be
specified
in
a
keyword
group.
You
can
specify
more
than
one
keyword
group
by
replicating
this
keyword
group
and
modifying
as
desired.
This
keyword
defines
the
attribute
that
should
be
used
for
filtering.
The
following
list
identifies
some
of
the
valid
values
that
you
can
specify,
depending
on
the
service
element
or
resource
type:
v
__NAME__
v
TEC_SEVCODE
v
BWM_RTT_CONST
v
BWM_TASKID
v
IP_DOMAIN
v
IP_NET_ADDRESS
v
(and
others)
Example:
FilterAttr:
__NAME__
FilterIsName
This
keyword
specifies
whether
the
filter
attribute
is
the
NAME
attribute.
Valid
values
for
this
keyword
are
true
or
false.
Example:
FilterIsName:
true
FilterOper
This
keyword
specifies
the
operator
to
be
used
for
filtering.
Valid
values
include:
v
EQUALS
v
NOT_EQUALS
v
LIKE
Example:
FilterOper:
LIKE
FilterValue
This
keyword
specifies
the
value
to
filter
on.
You
can
use
a
percent
sign
(%)
as
a
wild
card
to
match
0
or
more
characters.
For
example:
FilterValue:
%BWM_QOS%
Combining
some
of
the
above
examples,
the
content
of
the
properties
file
for
an
SLA
looks
similar
to
the
following
example:
//PROPERTIES
FILE
FOR
AMPLBANK
LOAN
SLA
OriginalSLA:
1000
Name:
AmplBank
Loan
SLA
Desc:
The
SLA
between
IT
and
the
AmplBank
Loan
Office,
established
3/23/2004.
StartDate:
05/26/2004
TimeZone:
CST
CustomerName:
AmplBank
Loan
Dept
OfferingName:
Gold
Level
Offering
//
112
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
//OFFERING
COMPONENT
DESCRIPTION
FOR
QoS
Component
OfferingCompName:
QoS
Component
ResourceName:
/BWM_EP_#5/BWM_QOS_#1
ResourceName:
/BWM_EP_#7/BWM_QOS_#3
//END
OF
OFFERING
COMPONENT
DESCRIPTION
//
//OFFERING
COMPONENT
Template
for
(Offering
Component
Name
here)
//OfferingCompName:
(Offering
Component
Name
here)
//FilterName:
(Filter
name
here)
//FilterDesc:
(Filter
description
here)
//AttrSetDoAnd:
true
//
//FILTER
GROUP
//FilterAttr:
__NAME__
//FilterIsName:
true
//FilterOper:
LIKE
//FilterValue:
%BWM_QOS%
//END
OF
FILTER
GROUP
//
//FILTER
GROUP
(Template)
//FilterAttr:
(Attribute
name
here)
//FilterIsName:
(Value
here)
//FilterOper:
(Operator
here)
//FilterValue:
(Value
here)
//END
OF
FILTER
GROUP
//END
OF
OFFERING
COMPONENT
DESCRIPTION
//END
OF
SLA
DESCRIPTION
If
this
SLA
properties
file
was
saved
in
C:\AmplBankSLA.txt,
you
would
issue
the
following
command
to
create
this
offering
in
IBM
Tivoli
Service
Level
Advisor:
scmd
som
create
-o
SLA
-file
C:\AmplBankSLA.txt
You
must
use
the
scmd
som
create
command
to
successfully
create
this
SLA
in
the
IBM
Tivoli
Service
Level
Advisor
environment
before
you
can
begin
to
evaluate
the
associated
resources
for
violations
and
trends.
Example:
Creating
a
Realm
Create
a
separate
realm
for
each
of
the
fifty
states
in
the
United
States,
using
the
name
of
the
state
as
the
name
of
the
realm.
If
you
use
the
SLM
Administrative
Console,
you
can
use
the
Create
Realm
function
multiple
times
to
create
each
of
the
realms
in
the
usual
way,
as
this
is
a
relatively
simple
SLM
object.
You
need
only
to
specify
a
name
for
the
realm
and
an
optional
text
description,
as
shown
in
Figure
15
on
page
114.
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
113
As
you
create
new
realms,
they
are
be
displayed
in
the
Manage
Realms
page
of
the
SLM
Administrative
Console
similar
to
Figure
16.
For
purposes
of
illustration,
however,
you
can
also
use
the
SLM
Object
Manager
method
to
create
a
single
template
realm
in
the
SLM
Administrative
Console
and
Figure
15.
Creating
a
realm
using
the
SLM
Administrative
Console.
Figure
16.
Displaying
created
realms
in
the
SLM
Administrative
Console.
114
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
then
export
it
to
a
plain
text
file.
You
can
then
modify
this
text
file
to
create
each
new
realm
in
IBM
Tivoli
Service
Level
Advisor.
Consider
the
existing
realm
for
Alabama
as
a
template
for
other
realms
that
you
want
to
create.
Using
the
SLM
Object
Manager
method
and
the
associated
CLI
commands,
first
list
the
available
realm
SLM
objects
and
then
export
one
as
a
template
file
for
creating
additional
realms
(in
the
following
examples,
a
Windows
platform
is
assumed.
Use
similar
commands
for
your
operating
system
as
needed):
1.
Open
a
command
prompt
and
navigate
to
<TSLA_Dir>,
the
location
where
IBM
Tivoli
Service
Level
Advisor
was
installed,
such
as
C:\TSLA.
2.
Initialize
the
SLM
environment
by
issuing
the
slmenv
command
3.
List
the
available
realm
SLM
objects
that
currently
exist
in
IBM
Tivoli
Service
Level
Advisor
by
issuing
the
command:
scmd
som
displayall
-o
realm
The
output
is
displayed
listing
the
existing
realms,
which
should
be
in
agreement
with
the
list
of
realms
as
shown
in
the
SLM
Administrative
Console
(see
Figure
16
on
page
114):
Realms
...
3/29/04
2:12:04
PM
EST
Cnt
Name
ID
Description
---
-------------------
--------------------
----------
0.
Alabama
1000
All
customers
in
Alabama
1.
Alaska
1001
All
customers
in
Alaska
2.
Arkansas
1002
All
customers
in
Arkansas
4.
Select
the
realm
for
Alabama
and
export
it
to
a
file,
C:\TSLA\alabama.txt
by
issuing
the
following
command:
scmd
som
export
-o
realm
-name
1000
-file
C:\TSLA\alabama.txt
Now
use
your
preferred
text
editor
to
open
the
C:\TSLA\alabama.txt
file.
Its
contents
should
look
similar
to
the
following
example:
OriginalRealm:
1000
Name:
Alabama
Desc:
All
customers
in
Alabama
Change
the
name
of
the
realm
to
another
name,
say,
Arizona,
and
modify
the
description
as
needed,
then
save
the
file
as
C:\TSLA\arizona.txt:
OriginalRealm:
1000
Name:
Arizona
Desc:
All
customers
in
Arizona
Note
that
the
ID
number
1000
remains
the
same
as
the
original.
When
the
new
realm
is
created
in
IBM
Tivoli
Service
Level
Advisor,
this
ID
number
is
ignored
and
a
new
ID
number
is
automatically
assigned
to
this
new
realm.
Now
use
the
scmd
som
create
command
to
create
the
new
realm
object
in
IBM
Tivoli
Service
Level
Advisor:
scmd
som
create
-o
realm
-file
C:\TSLA\arizona.txt
If
the
realm
was
created
successfully,
you
should
receive
a
message
similar
to
the
following
example:
DYKOM5027I
The
realm
with
ID:1003
was
created
successfully.
You
can
then
do
another
listing
of
the
realm
SLM
objects
to
verify
that
the
new
realm
is
added:
scmd
som
displayall
-o
realm
Appendix
C.
Creating
SLM
Objects
Using
CLI
Commands
115
Realms
...
3/29/04
2:20:17
PM
EST
Cnt
Name
ID
Description
---
-------------------
--------------------
----------
0.
Alabama
1000
All
customers
in
Alabama
1.
Alaska
1001
All
customers
in
Alaska
2.
Arkansas
1002
All
customers
in
Arkansas
3.
Arizona
1003
All
customers
in
Arizona
You
can
also
display
the
available
realms
in
the
SLM
Administrative
Console
using
the
Manage
Realms
page.
You
can
repeat
this
process
for
each
realm
that
you
want
to
create.
You
could
create
multiple
text
files,
one
per
SLM
object,
and
then
issue
multiple
scmd
som
create
commands
for
each
file,
or
bundle
all
of
the
CLI
commands
into
a
script
file
that
you
can
run
to
populate
the
SLM
databases
with
the
new
realms
more
quickly.
Example:
Creating
a
Customer
Create
a
customer
for
each
of
the
100
counties
in
the
state
of
North
Carolina,
using
the
North
Carolina
realm,
and
using
the
county
name
as
the
name
for
the
customer.
You
could
use
the
SLM
Administrative
Console
to
create
these
customers
one
by
one,
each
time
specifying
a
customer
name
and
description,
and
associating
the
North
Carolina
realm
to
each
customer
(assume
that
this
realm
was
already
created
in
the
previous
example).
You
can
alternatively
create
a
template
customer
once,
and
export
it
to
a
properties
file,
and
then
modify
it
to
create
the
customer
names
for
each
county.
You
can
use
a
procedure
similar
to
the
following
steps:
1.
Using
the
Create
Customer
page
of
the
SLM
Administrative
Console,
create
a
template
customer
named
Alamance
County.
Add
a
short
description
and
associate
this
customer
to
the
realm
name
North
Carolina.
2.
Issue
the
following
command
to
list
all
customers:
scmd
som
displayAll
-o
customer
3.
Obtain
the
ID
number
for
the
Alamance
County
customer,
for
example,
1003,
and
use
this
in
the
following
command
to
export
the
SLM
object
to
a
properties
file:
scmd
som
export
-o
customer
-id
1003
-file
C:\AlamanceCty.txt
4.
Edit
the
C:\AlamanceCty.txt
file.
The
contents
should
look
similar
to
the
following
example:
OriginalCustomer:
1003
Name:
Alamance
County
Desc:
This
is
the
customer
for
Alamance
County,
NC
RealmName:
North
Carolina
5.
Change
the
name
of
the
customer
to
Alexander
County,
and
modify
the
description.
Save
this
to
a
new
properties
file,
C:\AlexanderCty.txt.
6.
Issue
the
following
command
to
create
the
new
customer:
scmd
som
create
-o
customer
-file
C:\AlexanderCty.txt
7.
Check
the
message
to
verify
that
the
customer
was
created
successfully.
Repeat
step
4
through
step
7
for
each
county,
creating
a
new
customer
each
time.
You
could
also
bundle
the
create
commands
into
a
script
file
and
run
them
together
to
create
the
customers
more
quickly.
116
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Appendix
D.
Sample
SLM
Object
Properties
Files
This
appendix
contains
samples
of
the
SLM
object
properties
files
that
you
can
refer
to
when
you
export
SLM
objects
and
modify
them
to
create
new
SLM
objects
in
IBM
Tivoli
Service
Level
Advisor,
using
the
scmd
som
CLI
commands.
See
Appendix
C,
“Creating
SLM
Objects
Using
CLI
Commands,”
on
page
95
for
more
information
on
these
commands.
The
sample
SLM
object
properties
files
included
in
this
appendix
are:
v
“Sample
Properties
File
for
a
Realm”
v
“Sample
Properties
File
for
a
Customer”
v
“Sample
Properties
File
for
a
Schedule”
on
page
118
v
“Sample
Properties
File
for
an
Offering”
on
page
121
v
“Sample
Properties
File
for
an
SLA”
on
page
125
Note:
In
the
sample
files,
lines
that
begin
with
two
forward
slashes
(//)
are
comments.
Sample
Properties
File
for
a
Realm
The
following
sample
properties
file
is
for
a
realm:
//
Sample
Realm
properties
file
//
Update
the
keywords
with
appropriate
values
//
Original
Realm
ID
//
This
is
the
ID
number
of
the
original
realm.
//
Must
start
with
the
"OriginalRealm:"
keyword
//
It
is
ignored
when
this
file
is
used
to
create
a
new
realm.
The
realm
//
ID
for
the
new
realm
is
assigned
automatically.
OriginalRealm:
1200
//
Name
of
the
Realm
//
This
is
the
name
assigned
to
the
realm.
//
Must
start
with
the
"Name:"
keyword
//
Change
the
original
name
to
a
new
realm
name.
Name:
SampleRealm
//
Description
for
Realm
//
This
is
the
optional
text
description
for
the
realm.
//
Must
start
with
the
"Desc:"
keyword.
//
Enter
a
text
description
for
this
realm
if
desired.
//
If
you
do
not
enter
a
text
description,
specify
the
keyword
with
no
//
descriptive
text.
Desc:
This
is
the
sample
realm
description
Sample
Properties
File
for
a
Customer
The
following
sample
properties
file
is
for
a
customer:
//
Sample
Customer
properties
file
//
Update
the
keywords
with
appropriate
values
//
Original
Customer
ID
//
This
is
the
ID
number
of
the
original
customer
//
Must
start
with
the
"OriginalCustomer:"
keyword
//
It
is
ignored
when
this
file
is
used
to
create
a
new
customer.
//
The
customer
ID
for
the
new
customer
is
assigned
automatically.
©
Copyright
IBM
Corp.
2002,
2004
117
OriginalCustomer:
1006
//
Name
of
the
Customer
//
This
is
the
name
assigned
to
the
customer.
//
Must
start
with
the
"Name:"
keyword
//
Change
the
original
name
to
a
new
customer
name.
Name:
SampleCustomer
//
Description
for
Customer
//
This
is
the
optional
text
description
for
the
customer.
//
Must
start
with
the
"Desc:"
keyword.
//
Enter
a
text
description
for
this
customer
if
desired.
//
If
you
do
not
enter
a
text
description,
specify
the
keyword
with
no
//
descriptive
text.
Desc:
This
is
the
sample
customer
description
//
List
one
or
more
RealmNames
for
the
customer
//
This
customer
can
be
associated
with
one
or
more
realms.
//
The
realm
name(s)
specified
MUST
already
exist
in
the
SLM
databases
for
this
//
customer
to
be
created
successfully.
RealmName:
SampleRealm
//RealmName:
realm1
//RealmName:
realm2
Sample
Properties
File
for
a
Schedule
The
following
sample
properties
file
is
for
a
schedule:
//
Sample
Schedule
properties
file
//
Update
the
keywords
with
appropriate
values
//
Original
Schedule
ID
//
This
is
the
ID
number
of
the
original
schedule
//
Must
start
with
the
"OriginalSchedule:"
keyword
//
It
is
ignored
when
this
file
is
used
to
create
a
new
schedule.
//
The
schedule
ID
for
the
new
schedule
is
assigned
automatically.
OriginalSchedule:
1001
//
Name
of
the
Schedule
//
This
is
the
name
assigned
to
the
schedule.
//
Must
start
with
the
"Name:"
keyword
//
Change
the
original
name
to
a
new
schedule
name.
Name:
SampleSchedule
//
Description
for
the
Schedule
//
This
is
the
optional
text
description
for
the
schedule.
//
Must
start
with
the
"Desc:"
keyword.
//
Enter
a
text
description
for
this
schedule
if
desired.
//
If
you
do
not
enter
a
text
description,
specify
the
keyword
//
with
no
descriptive
text.
Desc:
This
is
the
sample
schedule
description.
//
Auxiliary
Schedule
Indicator,
valid
values:
true,
false
//
Must
start
with
the
"IsAuxiliary:"
keyword
//
If
this
is
an
auxiliary
schedule,
set
IsAuxiliary
to
true
//
If
this
is
a
business
schedule,
set
IsAuxiliary
to
false
//
NOTE:
Auxiliary
schedules
cannot
contain
other
auxiliary
schedules.
IsAuxiliary:
false
//
List
of
Contained
Auxiliary
Schedules
//
If
this
schedule
is
a
business
schedule
and
not
an
auxiliary
schedule
//
(that
is,
IsAuxiliary
is
false),
optionally
list
one
or
more
auxiliary
118
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
//
schedule
names
that
are
included
in
this
schedule.
//
Each
auxiliary
schedule
must
start
with
the
"AuxiliarySchedule:"
keyword
//
Each
auxiliary
schedule
specified
must
already
exist
in
the
SLM
database.
//
NOTE:
if
IsAuxiliary
is
true,
this
schedule
file
cannot
contain
a
list
of
//
included
auxiliary
schedules
AuxiliarySchedule:
SampleAuxSchedule
//AuxiliarySchedule:
SampleAuxSchedule2
//AuxliarySchedule:
SampleAuxSchedule3
//
Default
schedule
state
//
This
is
the
value
for
the
schedule
state
that
is
assumed
for
all
unspecified
//
time
periods
in
the
business
schedule.
//
This
entry
is
valid
only
for
business
schedules
(IsAuxiliary
is
false)
//
Must
start
with
the
"DefaultState:"
keyword
//
Valid
values
that
can
be
specified
include:
//
-
SCHEDULE_PEAK
//
-
SCHEDULE_CRITICAL
//
-
SCHEDULE_PRIME
//
-
SCHEDULE_STANDARD
//
-
SCHEDULE_LOW_IMPACT
//
-
SCHEDULE_OFF_HOURS
//
-
NO_SERVICE
//
//
NOTE:
if
IsAuxiliary
is
true,
this
schedule
file
should
not
contain
a
default
//
schedule
state.
DefaultState:
SCHEDULE_OFF_HOURS
//
Period
Specification
//
If
this
is
an
auxiliary
schedule,
you
must
define
at
least
one
period
for
//
the
schedule.
//
If
this
is
a
business
schedule,
you
must
either
define
at
least
one
period
//
for
this
schedule
or
include
an
auxiliary
schedule
that
has
at
least
one
//
period
defined.
//
//
Each
period
that
is
specified
in
this
schedule
file
must
be
defined
by
the
//
following
set
of
required
keywords:
//
-
PeriodState:
This
is
the
schedule
state
for
the
period,
specifying
one
//
of
the
following
valid
values:
//
-
SCHEDULE_PEAK
//
-
SCHEDULE_CRITICAL
//
-
SCHEDULE_PRIME
//
-
SCHEDULE_STANDARD
//
-
SCHEDULE_LOW_IMPACT
//
-
SCHEDULE_OFF_HOURS
//
-
NO_SERVICE
//
//
NOTE:
PeriodState
MUST
be
the
first
keyword
specified
for
each
period
//
definition.
//
//
-
PeriodStart:
This
is
the
starting
time
for
the
period,
specified
in
HH:00
//
format,
where
HH
is
a
valid
2-digit
integer
value
from
00
to
23.
Note
that
//
start
time
occurs
at
the
start
of
the
specified
hour
(00
minutes).
//
//
-
PeriodEnd:
This
is
the
ending
time
for
the
period,
specified
in
HH:59
//
format,
where
HH
is
a
valid
2-digit
integer
value
from
00
to
23.
Note
that
//
the
period
end
time
must
occur
AFTER
the
period
start
time,
and
occurs
at
//
59
minutes
after
the
specified
hour.
//
//
-
PeriodTimeZone:
This
is
the
time
zone
for
the
specified
start
and
end
times.
//
Valid
values
include
America/New_York,
EST,
CST,
MST,
PST,
GMT,
and
many
//
others.
You
can
find
additional
valid
values
by
issuing
the
command:
//
"scmd
som
displayTimezones"
//
//
-
Frequency:
This
specifies
the
frequency
of
this
period.
Valid
values
include:
//
-
Daily
(this
is
the
default
value
if
Frequency
is
not
specified)
Appendix
D.
Sample
SLM
Object
Properties
Files
119
//
-
Weekly
//
-
Monthly
//
-
Single_Date
//
//
ADDITIONAL
KEYWORDS:
//
//
If
you
specify
a
Frequency
of
Daily,
no
other
keywords
are
necessary.
//
//
If
you
specify
a
Frequency
of
Weekly,
you
must
also
specify
the
"Day:"
//
keyword,
specifying
one
of
the
following
valid
values:
//
-
Mon,
Tue,
Wed,
Thu,
Fri,
Sat,
Sun
//
You
can
specify
more
than
one
day,
but
each
day
must
be
specified
on
//
a
new
line
and
start
with
the
"Day:"
keyword.
//
//
If
you
specify
a
Frequency
of
Monthly,
you
must
specify
the
"Month:"
//
keyword,
specifying
one
of
the
following
valid
values:
//
-
Jan,
Feb,
Mar,
Apr,
May,
Jun,
Jul,
Aug,
Sep,
Oct,
Nov,
Dec
//
You
can
specify
more
than
one
month,
but
each
month
must
be
specified
//
on
a
new
line
and
start
with
the
"Month:"
keyword.
//
//
AND
you
must
specify
either
the
"DayOfMonth:"
keyword
OR
the
//
"DayInterval:"
and
"Day:"
keyword
combination,
where:
//
-
DayOfMonth
is
a
valid
integer
between
1
and
31,
or
the
word
"last"
//
-
DayInterval
is
one
of
the
following
valid
values:
//
1st,
2nd,
3rd,
4th,
or
"last"
//
-
Day
is
a
valid
integer
between
1
and
31
//
//
If
you
specify
a
Frequency
of
Single_Date,
you
must
specify
the
following
//
additional
keywords:
//
-
Month:
(one
of
the
valid
values
as
specified
above)
//
-
Day:
(a
valid
integer
between
1
and
31)
//
-
Year:
(a
valid
4-digit
calendar
year,
such
as
2004.)
//
A
sample
weekly
period
specification
-
critical
state
from
9am-5pm
weekdays
PeriodState:
SCHEDULE_CRITICAL
PeriodStart:
09:00
PeriodEnd:
16:59
PeriodTimeZone:
America/New_York
Frequency:
Weekly
Day:
Mon
Day:
Tue
Day:
Wed
Day:
Thu
Day:
Fri
//
A
sample
daily
period
specification
-
low
impact
state
everyday
//
from
07:00
to
18:59
PeriodState:
SCHEDULE_LOW_IMPACT
PeriodStart:
07:00
PeriodEnd:
18:59
PeriodTimeZone:
America/New_York
Frequency:
Daily
//
A
sample
monthly
interval
period
specification
-
standard
state
from
//
10pm
to
11pm
on
the
3rd
Wednesday
of
January,
March
and
May
//PeriodState:
SCHEDULE_STANDARD
//PeriodStart:
22:00
//PeriodEnd:
22:59
//PeriodTimeZone:
America/New_York
//Frequency:
Monthly
//DayInterval:
3rd
//Day:
Wed
//Month:
Jan
//Month:
Mar
//Month:
May
//
A
sample
monthly
exact
day
period
specification
-
no
service
state
120
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
//
from
2am
to
3am
on
the
15th
day
of
every
month
//PeriodState:
NO_SERVICE
//PeriodStart:
02:00
//PeriodEnd:
02:59
//PeriodTimeZone:
America/New_York
//Frequency:
Monthly
//DayOfMonth:
15
//Month:
Jan
//Month:
Feb
//Month:
Mar
//Month:
Apr
//Month:
May
//Month:
Jun
//Month:
Jul
//Month:
Aug
//Month:
Sep
//Month:
Oct
//Month:
Nov
//Month:
Dec
//
a
sample
single
date
period
specification
//PeriodState:
SCHEDULE_PRIME
//PeriodStart:
10:00
//PeriodEnd:
14:59
//PeriodTimeZone:
America/New_York
//Frequency:
Single_Date
//Month:
Jan
//Day:
12
//Year:
2004
Sample
Properties
File
for
an
Offering
The
following
sample
properties
file
is
for
an
offering:
//
Sample
Offering
properties
file
//
Update
the
keywords
with
appropriate
values
//
Original
Offering
ID
//
This
is
the
ID
number
of
the
original
offering.
//
Must
start
with
the
"OriginalOffering:"
keyword
//
It
is
ignored
when
this
file
is
used
to
create
a
new
offering.
//
The
offering
ID
for
the
new
offering
is
assigned
automatically.
OriginalOffering:
1004
//
Name
of
the
Offering
//
This
is
the
name
assigned
to
the
offering.
//
Must
start
with
the
"Name:"
keyword
//
Change
the
original
name
to
a
new
offering
name.
Name:
SampleOffering
//
Description
for
the
Offering
//
This
is
the
optional
text
description
for
the
offering.
//
Must
start
with
the
"Desc:"
keyword.
//
Enter
a
text
description
for
this
offering
if
desired.
//
If
you
do
not
enter
a
text
description,
specify
the
keyword
with
//
no
descriptive
text.
Desc:
This
is
the
sample
offering
description.
//
Name
of
Included
Schedule
//
This
is
the
name
of
the
schedule
that
is
to
be
included
in
this
offering.
//
Must
start
with
the
"ScheduleName:"
keyword.
Appendix
D.
Sample
SLM
Object
Properties
Files
121
//
This
schedule
must
already
exist
in
the
SLM
database
before
it
can
be
//
included
in
this
offering.
ScheduleName:
SampleSchedule
//
Offering
State
//
This
is
the
state
of
the
offering.
//
Must
start
with
the
"OfferingState:"
keyword.
//
Valid
values
are:
//
-
STATE_PUBLISHED
//
-
STATE_DRAFT
//
NOTE:
Offerings
must
be
in
the
STATE_PUBLISHED
state
before
they
can
//
be
included
in
SLAs.
If
you
create
an
offering
in
DRAFT
state,
//
you
can
later
use
the
Manage
Offerings
page
of
the
SLM
Administrative
//
Console
to
publish
the
offering,
and
then
it
will
be
available
for
//
inclusion
in
SLAs.
OfferingState:
STATE_PUBLISHED
//
SLA
type
//
This
is
an
indication
of
the
type
of
SLA
for
which
this
offering
is
intended.
//
Must
start
with
the
"SlaType:
keyword
//
Valid
values
include:
//
-
TYPE_INTERNAL
//
-
TYPE_EXTERNAL
//
-
TYPE_OUTSOURCED
SlaType:
TYPE_INTERNAL
//
Optionally
Included
SLAs
//
This
is
used
when
you
intend
to
create
a
tiered
SLA
with
this
//
offering.
You
can
list
one
or
more
existing
SLA
names
to
include
//
in
this
offering.
//
Each
SLA
that
is
included
must
start
with
the
"IncludedSLA:"
//
keyword.
//
//
NOTE:
Dependencies
on
the
types
of
SLAs
that
can
be
included
in
//
other
SLAs
are
not
enforced.
Refer
to
"Managing
Service
Level
Agreements"
//
for
information
on
the
types
of
SLAs
that
can
be
included
in
other
//
SLAs
to
create
valid
tiered
SLAs.
IncludedSLA:
AnIncludedSLAName
//IncludedSLA:
IncludedSLA2
//IncludedSLA:
IncludedSLA3
//
Offering
Component
Name
//
The
offering
component
name
specified
must
match
the
name
of
a
//
service
element
that
is
active
on
your
system.
//
You
can
use
the
"scmd
sdc
displayActiveServiceElements"
command
to
//
display
a
list
of
the
active
service
elements
and
metrics
on
your
//
system.
//
//
Must
start
with
the
"OfferingComp:"
keyword
//
//
To
add
multiple
service
elements,
copy
and
paste
the
keywords
from
//
"OfferingComp"
to
"ExpectedData"
(described
in
the
remainder
of
//
this
file)
and
modify
their
values
as
needed
for
each
keyword.
//
//
NOTE:
If
you
included
one
or
more
SLAs
using
the
"IncludedSLA"
//
keyword
(above),
this
offering
can
optionally
contain
no
service
//
elements.
OfferingComp:
CompTyp.CompTyp_Nm.BWM_QOS
122
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
//
Component
name
for
this
offering
component
//
Must
start
with
the
"OfferingCompName:"
keyword
//
Must
be
unique
within
the
offering
OfferingCompName:
QoS
Component
//
Component
description
//
A
text
description
of
the
specified
component.
//
Must
start
with
the
"OfferingCompDesc:"
keyword.
OfferingCompDesc:
Qos
Component
description
//
Component
Measurement
Source
type
code
//
Specifies
the
measurement
source
code
for
source
application
providing
//
measurement
data
for
this
component.
//
Must
start
with
the
"OfferingCompSource:"
keyword
OfferingCompSource:
BWM
//
Metric
Name
//
Under
each
service
element,
define
one
or
more
metrics.
//
The
metric(s)
specified
must
match
the
Name
of
a
metric
//
that
exists
for
the
specified
offering
component
on
your
system.
//
To
add
multiple
metrics
under
an
offering
component,
//
copy
the
keywords
from
"Metric:"
to
"ExpectedData:"
and
paste
//
after
the
current
metric.
Metric:
MsmtTyp.MsmtTyp_Nm.Round
Trip
Time
//
Breach
Values
//
This
includes
Min,
Max,
Avg,
and
Violation
Condition
for
each
//
of
the
different
schedule
states
that
are
specified
in
the
//
included
schedule
named
above.
Specify
one
or
more
of
the
Min,
//
Max,
and
Avg
values
for
each
schedule
state.
//
Min,
Max
and
Avg
are
specified
as
floating
point
decimals.
//
Valid
values
for
Violation
Condition
include:
//
-
ascending
(this
is
the
default
value
if
not
specified)
//
-
descending
//
All
possible
keywords
are
listed
below
for
reference
//
(most
are
commented
out).
//PeakMin:
5000.0
//PeakMax:
6000.0
//PeakAvg:
5500.0
//PeakTotal:
7500.0
//PeakViolCond:
ascending
//OffHoursMin:
5500.0
OffHoursMax:
6000.0
OffHoursAvg:
6500.0
//OffHoursTotal:
3400.0
//OffHoursViolCond:
ascending
CriticalMin:
7000.0
//CriticalMax:
9000.0
CriticalAvg:
8000.0
//CriticalTotal:
7900.0
CriticalViolCond:
descending
//PrimeMin:
7500.0
//PrimeMax:
9500.0
Appendix
D.
Sample
SLM
Object
Properties
Files
123
//PrimeAvg:
8500.0
//PrimeTotal:
5500.0
//PrimeViolCond:
ascending
//StandardMin:
7700.0
//StandardMax:
9700.0
//StandardAvg:
8700.0
//StandardTotal:
9900.0
//StandardViolCond:
descending
LowImpactMin:
7900.0
//LowImpactMax:
9900.0
LowImpactAvg:
8900.0
//LowImpactTotal:
4400.0
//LowImpactViolCond:
descending
//
Internal
use
only
//
Must
start
with
the
"InternalUseOnly:"
keyword
//
Valid
values
include:
//
-
YES
//
-
NO
(this
is
the
default
if
not
specified
InternalUseOnly:
no
//
Evaluation
Interval
type
//
Must
start
with
the
"EvalIntervalType:"
keyword
//
Valid
values
include:
//
-
Hourly
(when
enabled)
//
-
Daily
//
-
Weekly
//
-
Monthly
EvalIntervalType:
Monthly
//
//
Hourly
Evaluation
Frequency
//Must
start
with
the
"EvalXHours:"
keyword
//
Valid
Values
include
1,
2,
3,
4,
6,
8,
or
12
EvalXHours:
4
//
Trend
Interval
type
//
Must
start
with
the
"TrendIntervalType:"
keyword
//
Valid
values
include:
//
-
Daily
//
-
Weekly
//
-
Monthly
//
Must
be
more
frequent
than
or
equal
to
the
value
specified
//
for
Evaluation
Interval
Type
(above)
TrendIntervalType:
Daily
//
Intermediate
Evaluation
Type
//
Optionally
specifies
the
frequency
for
intermediate
evaluations
//
Must
start
with
the
"EvalIntermediateType:"
keyword
//
Valid
values
include:
//
-
Daily
//
-
Hourly
(where
available)
//
Must
be
more
frequent
than
the
value
specified
for
Evaluation
//
Interval
Type
(above)
EvalIntermediateType:
Daily
//
//
Hourly
Evaluation
Frequency
//Must
start
with
the
"EvalXHours:"
keyword
//
Valid
Values
include
1,
2,
3,
4,
6,
8,
or
12
124
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
EvalXHours:
4
//
Trend
Type
//
Must
start
with
the
"TrendType:"
keyword
//
Valid
values
include:
//
-
TYPE_CONTINUOUS
(this
is
the
default
value
if
not
specified)
//
-
TYPE_INPERIOD
TrendType:
TYPE_CONTINUOUS
//
Expected
data
//
Indicates
whether
or
not
data
is
expected
for
every
evaluation
interval
//
Valid
values
include:
//
-
YES
(if
no
data
is
received
for
any
evaluation
period
it
is
considered
//
to
be
an
error)
//
-
NO
(If
no
data
is
received
for
any
evaluation
period
it
is
ignored.
This
is
the
default
if
not
specified.)
ExpectedData:
no
Sample
Properties
File
for
an
SLA
The
following
sample
properties
file
is
for
an
SLA:
//
Sample
SLA
properties
file
//
Update
the
keywords
with
appropriate
values
//
Original
SLA
ID
//
This
is
the
ID
number
of
the
original
SLA.
//
Must
start
with
the
"OriginalOrder:"
keyword
//
It
is
ignored
when
this
file
is
used
to
create
a
new
SLA.
//
The
SLA
ID
for
the
new
SLA
is
assigned
automatically.
OriginalOrder:
1002
//
The
SLA
Name
//
This
is
the
name
assigned
to
the
SLA
//
Must
start
with
the
"Name:
keyword
//
Change
the
original
name
to
a
new
SLA
name.
Name:
SampleSLA
//
Description
for
the
SLA
//
This
is
the
optional
text
description
for
the
SLA.
//
Must
start
with
the
"Desc:"
keyword.
//
Enter
a
text
description
for
this
SLA
if
desired.
//
If
you
do
not
enter
a
text
description,
specify
the
keyword
with
//
no
descriptive
text.
Desc:
This
is
the
sample
SLA
description
//
The
Start
Date
of
the
SLA.
//
Must
start
with
the
"StartDate:"
keyword.
//
Will
default
to
the
beginning
of
today’s
date
if
not
specified.
//
The
format
is
MM/DD/YYYY
//
NOTE:
If
you
specify
a
start
date
in
the
past
that
causes
re-evaluations
to
//
occur,
performance
will
be
significantly
affected
during
this
extra
processing.
StartDate:
03/19/2004
//
TimeZone
//
This
is
the
time
zone
for
when
the
SLA
will
be
evaluated.
//
Must
start
with
the
"TimeZone:"
keyword.
Appendix
D.
Sample
SLM
Object
Properties
Files
125
//
Valid
values
include
America/New_York,
EST,
CST,
MST,
PST,
GMT,
and
many
//
others.
You
can
find
additional
valid
values
by
issuing
the
command:
//
"scmd
som
displayTimezones"
//
The
Timezone
value
will
default
to
the
time
zone
of
the
SLM
server
if
//
not
specified.
TimeZone:
America/New_York
//
The
Customer
Name
associated
with
this
SLA
//
Must
start
with
the
"CustomerName:"
keyword
//
This
customer
name
must
already
exist
in
the
SLM
databases.
CustomerName:
SampleCustomer
//
The
Offering
Name
to
be
included
in
the
SLA
//
Must
start
with
the
"OfferingName:"
keyword
//
This
offering
name
must
already
exist
in
the
SLM
databases.
OfferingName:
SampleOffering
//
Offering
Component(s)
//
The
offering
component(s)
specified
must
match
the
name(s)
of
one
or
//
more
service
elements
that
are
active
on
your
system.
//
//
The
service
elements
listed
here
must
match
the
service
elements
//
that
are
contained
in
the
offering
that
is
specified
above.
//
The
OfferingCompName
specified
in
the
offering
should
be
used
here.
If
//
no
OfferingCompName
was
specified
in
the
offering,
then
use
the
OfferingComp
//
name
that
was
specified
in
the
offering.
//
To
add
multiple
service
elements,
copy
and
paste
from
OfferingComp
//
to
ResourceName
or
FilterValue.
OfferingCompName:
QoS
Component
//
Under
each
offering
component,
list
one
or
more
ResourceNames
//
-
OR
-
//
define
a
filter
specification
(which
consists
of
at
least
7
filter
//
keywords,
described
below).
//
A
single
resource
name
//
Must
start
with
the
"ResourceName:"
keyword
ResourceName:
/BWM_EP_#5/BWM_QOS_#1
ResourceName:
/BWM_EP_#7/BWM_QOS_#3
//
A
filter
specification
//
Consists
of
at
least
7
filter
fields:
//
One
each
of
FilterName,
FilterDesc,
and
AttrSetDoAnd,
and
//
One
or
more
sets
of
the
following
4
filter
fields:
//
FilterAttr,
FilterIsName,
FilterOper,
and
FilterValue
//
Give
the
filter
a
name
//
Must
start
with
the
"FilterName:"
keyword
FilterName:
MyQOSFilter
//
Give
the
filter
a
description
//
Must
start
with
the
"FilterDesc:"
keyword
FilterDesc:
This
filter
matches
resources
with
"BWM_QOS"
in
them
//
Specify
the
filtering
method
for
when
multiple
filter
groups
are
present.
126
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
//
Must
start
with
the
"AttrSetDoAnd:"
keyword
//
Valid
values
include:
//
-
true
(means
to
AND
the
filters
together)
//
-
false
(means
to
OR
the
filters
together)
AttrSetDoAnd:
true
//
The
next
four
filter
attributes
should
always
be
specified
in
groups:
//
FilterAttr,
FilterIsName,
FilterOper
and
FilterValue
//
Set
the
filter
attribute
to
use
//
Must
start
with
the
"FilterAttr:"
keyword
//
Valid
values
can
include:
//
-
__NAME__
//
-
TEC_SEVCODE
//
-
BWM_RTT_CONST
//
-
BWM_TASKID
//
-
IP_DOMAIN
//
-
IP_NET_ADDRESS
//
and
many
more,
depending
on
the
offering
component
or
resource
type
FilterAttr:
__NAME__
//
Specify
whether
the
filter
attribute
is
the
Name
attribute
//
Must
start
with
the
"FilterIsName:"
keyword
//
Valid
values
are
true
or
false
FilterIsName:
true
//
Specify
the
filter
operator
//
Must
start
with
the
"FilterOper:"
keyword
//
Valid
values
include:
//
-
EQUALS
//
-
NOT_EQUALS
//
-
LIKE
FilterOper:
LIKE
//
Specify
the
filter
value
//
Must
start
with
the
"FilterValue:"
keyword
//
You
can
specify
a
%
character
as
a
"wild
card"
to
match
0
or
more
characters
FilterValue:
%BWM_QOS%
Appendix
D.
Sample
SLM
Object
Properties
Files
127
128
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Appendix
E.
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
129
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.
130
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Trademarks
IBM,
the
IBM
logo,
Lotus,
Rational,
Tivoli,
the
Tivoli
logo,
WebSphere,
DB2,
DB2
Universal
Database,
eServer,
iSeries,
OS/390,
Passport
Advantage,
pSeries,
Redbooks,
Tivoli
Enterprise,
and
Tivoli
Enterprise
Console
are
trademarks
or
registered
trademarks
of
International
Business
Machines
Corporation
in
the
United
States,
other
countries,
or
both.
Microsoft,
Windows,
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.
Other
company,
product,
or
service
names
may
be
trademarks
or
service
marks
of
others.
Appendix
E.
Notices
131
132
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
Index
Aaccessibility
ix
screen-reader
software
8
addSingleScheduleState
34
adjudicating
violations
68,
73
adjudication
66
Administer
SLM
group
31,
32
Administrators
Guide
vi
advance
settings,
offering
43
analysisfrequency
of,
considerations
48
applicationenabling
12
event
escalation
80
applicationssource
2
auxiliary
schedule
19,
20
AVA
measurement
source
code
13
availability,
metric
evaluator
81
percent
of
time
in
state
81
state
transitions
82
transaction
availability
83
Bbenefits
of
using
SLM
3
breach
value
3,
17,
43,
69
breach
values
43
business
schedule
19
CCDW
1
central
data
warehouse
1
change
offeringlisting
affected
customers
and
orders
51
change
request,
metric
evaluator
81
change,
metric
evaluator
86
child
resource
type
42
Command
Reference
vi
compatible
schedule
34
continuous
trend
evaluation
47
counts,
incident
and
change
metric
86
critical
schedule
state
22,
26
current
evaluation
period
only,
trend
47
customer
2
associating
with
order
15
change
offering,
listed
affected
51
creating
55
customer
support
ix
customer,
in
SLA
57
customize
schedules
31,
32
Ddata
arriving
after
evaluation
69
flow
11
data
(continued)flow
of
2
late
arriving
69
data
flowcustomer,
defining
15
enabling
source
application
12
evaluating
17
obtaining
measurement
type
13
obtaining
resource
type
13
offering,
creating
13
order,
creating
15
schedules,
defining
13
trend
17
violation
17
data,
missing
48
databaseSLM
2
deleting
SLA,
restrictions
64
displayTimezones
96
Distributed
MonitoringSee
IBM
Tivoli
Monitoring
documentation,
accessing
on
product
CD
vi
double-byte
characterspassword,
SLM
Administrative
Console
4
draft
offering
51
Ee-mail
3,
17,
77
notification
77
including
HTML
link
78
notification,
testing
78
escalatione-mail
notification
77
escalation,
event
77
ETL
13
normal
data
flow
48
evaluation
67
frequency
of,
considerations
48
historical
data
72
hourly
16
intermediate
14,
16,
46
metric
evaluators
81
retrying
68
SLO
frequency
44
evaluation
frequency,configuring
43
evaluation
results
3
evaluation,
SLO
14
eventnotification
3
event
escalation
17
application
80
notification
77
notification
77
SNMP
trap
79
exclude
metric
from
external
reports
44
excluding
a
violation
68,
73
excluding
violations
66
exponential
stress
detection
trend
69
external
SLA
14,
39
Ffilter
offering
component
41
filtering
resources
15
GGetting
Started
vi
Hhelp
ix
historical
evaluation
72
Home
Page
Reader
8
hourly
evaluationenabling
45
evaluationhourly
44
HTML
link,
including
in
78
IIBM
Tivoli
Business
Systems
Manager
1
IBM
Tivoli
Enterprise
Console
1
IBM
Tivoli
Monitoring
1
IBM
Tivoli
Monitoring
for
Transaction
Performanceprevious
nameTivoli
Web
Services
Manager
1
IBM
Tivoli
Service
Level
Advisorenvironment
1
IBM
WebSphere
Application
Server
4
imminent
violation
75
incident,
metric
evaluator
81,
86
intermediate
evaluation
14,
16,
46
internal
SLA
14,
39
internal
use
only,
metric
44
Llate
data
69
level
of
service
v
managing
2
library,
product
vi
linear
trend
69
low
impact
schedule
state
26
Mmanage
schedule
35
Managing
Service
Level
Agreements
vi
measurement
source
code
13
measurement
source,
selecting
42
Messages
vi
metric
3
©
Copyright
IBM
Corp.
2002,
2004
133
metric
(continued)advance
settings
46
internal
use
only
44
log
messages
for
missing
data
46
selecting
42
metric
evaluator
68,
81,
91
Type
A
81,
83,
84,
85,
87,
91,
92
Type
B
85,
86,
93
Type
B1
88,
93
Type
B2
88,
93
Type
C
82,
94
Microsoft
Internet
Explorer
xiii
missing
data
48
missing
data,
logging
46
Mozilla
xiii
Nnewsgroups
xiii
no
service
schedule
state
22,
26
no
evaluation
27
None
SLA
state
61
notification
17
e-mail,
including
HTML
link
78
number
of
outages
82
Ooff
hours
schedule
state
22,
26
offering
1,
2,
11
advance
settings,configuring
43
change,
listing
affected
customers
and
orders
51
changing
published
51
component
13
component,
adding
41
creating
38
creating,
managing
37,
57
draft
15
draft,
published,
withdrawn
51
in
SLA
57
publishing
15,
50
replace
37
select
metric
42
offering
component
14
Offering
Specialist
v,
13,
15
offering,
selecting
from
available
15
online
help
vi
order
2,
11
associating
with
customer
15
change
offering,
listing
affected
51
outsourced
SLA
14,
39
overlapping
periods
29
Pparent
resource
type
42
peak
schedule
state
22,
26
percent
available
83
percentages,
incident
and
change
metric
87
performance,
metric
evaluator
81,
84
period
19,
22
creating,
schedule
23
frequency,
defining
29
overlapping,
managing
29
period
(continued)renamig
schedule
states
31
schedule,
defining
23
portfolio
5
prime
schedule
state
22,
26
problem
reporting
x
Process
ETLapplication
event
escalation
80
scheduled
or
run
on
demand
16
publicationaccessing
online
viii
Tivoli
Data
Warehouse
vii
warehouse
pack
viii
WebSphere
viii
publications
vi
ordering
ix
published
offering
51
publishing
the
offering
50
Qquarter,
customizing
fiscal
32
RRead
Me
First
vi
realm
15
creating
53
realm,
in
SLA
57
Registration
ETLapplication
event
escalation
80
obtaining
measurement
and
resource
types
13
scheduled
or
run
on
demand
13
reinstating
a
violation
68,
73
reinstating
violations
66
Release
Notes
vi
remark,
adding
to
SLA
64
removeSingleSchedulePeriod
35
reportexternal,
excluding
metric
from
44
reports
3
accessing,
Web
17
customizing
fiscal
quarter
and
year
32
resourceconfiguring
14
name,
changing
in
an
SLA
65
parent,
child
42
type,
selecting
42
resource
type
14,
15
filtering
41
multiple
measurement
sources
for
42
retrying
evaluation
68
role
v,
13
offering
specialist
15
sla
specialist
16
ruleslm.baroc
79
slm.rls
72
Ssample
points,trend
analysis
69
scheduleauxiliary
19
schedule
(continued)business
19,
37
compatible,
defining
34
creating
22
creating
for
offering
38
creating,
managing
19
customizing
fiscal
quarter
and
year
32
in
SLA
57
incident
and
change
request
89
managing
35
ordering
periods
29
period
22,
37
period,
adding
for
a
single
future
date
34
period,
defining
23
period,creating
23
preferences
31
rules
for
creating
20
state
2,
13,
19,
37
defining
multiple
27
states,
defining
26
states,
renaming
31
schedule
state
22
schedule,
auxiliarycreating
20
selecting
measurement
source
42
selecting
metrics
42
service
level
agreement
1,
11
service
level
management
v
service
level
objective
13
in
SLA
57
service
level
objective,configuring
43
service
transaction
1
showHourlyFrequencyIntervals
45
SLA
1,
11
adding
remarks
64
canceling
64
changing
63
creating
58
creation
overview
2
deleting
64
evaluation
67
external
14
internal
14
name,
specifying
text
61
offering,
changing
65
outsourced
14
reactivating
64
reports
17
resource,
changing
the
name
65
start
date
16
start
date
in
the
past
72
state
61
submitting
16,
60
tiered
14,
39
tiered,
changing
63
type
14
SLA
Adjudicator
v
SLA
process
overview
11
SLA
results
77
SLA
Specialist
v,
16
SLA
statein
SLA
61
SLM
v
SLM
Admininstrative
Consolestarting
4
134
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
SLM
Administrative
Console
v,
viii,
1
accessibility
8
layout
5
password,
double-byte
4
starting
4
SLM
Administrator
v
SLM
Database
2,
17,
42
getting
measurement
and
resource
type
information
13
SLM
Measurement
Data
Mart
2,
16
SLM
Reports
vi,
17
slm.baroc
rule,
TEC
event
79
slm.rls
TEC
rule
72
SLO
13,
69
SLO
evaluation
14
SLO,configuring
43
SMTP
server,
notification
78
SNMP
3,
17
SNMP
trap
77
UDP
protocol,
using
80
SNMP
trap
event
79
source
application
1
enabling
for
data
collection
12
standard
schedule
state
22,
26
start
date,SLA
16
startingSLM
Administrative
Console
4
stateschedule
19,
22
schedule,
defining
23,
26
state,
available
81
statesschedule,
renaming
31
steady
SLA
state
61
support,
contacting
ix
Ttableof
contents
5
TAPMSee
Tivoli
Application
Performance
Management
taskrole
authorization
v
Task
Assistant
vi,
5
tasks
5
TBSMSee
IBM
Tivoli
Business
Systems
Manager
TEC
3,
17
See
IBM
Tivoli
Enterprise
Console
TEC
event
79
TEC
event
escalation
72
tiered
SLA
14,
39,
63
time
in
state,
incident
and
change
metric
88
time
to
repair
83
time
to
state,
incident
and
change
metric
88
time
zone
21,
23,
27,
50,
61,
63,
96
modifying
29
modifying
a
period
36
period
100
schedule
98
SLA
60,
72,
110
SLM
Server
50,
69
spanning
multiple
49
Tivoli
Application
Performance
Managementnew
nameIBM
Tivoli
Monitoring
for
Transaction
Performance
1
Tivoli
Data
Warehouse
1
Tivoli
Enterprise
Consoleevent
notification
79
rule,
slm.rls
72
Tivoli
Enterprise
Console
event
77
Tivoli
Web
Services
Managernew
nameIBM
Tivoli
Monitoring
for
Transaction
Performance
1
total
performance
85
transaction
success
83,
92
trend
3
analysis
frequency
46
analyzing
69
continuous
evaluation
47
current
evaluation
period
only
47
evaluating
2,
17
event
notification
17
exponential
stress
detection
69
frequency
of,
considerations
48
linear
69
trend
analysis
67,
77
trend
analysis,
frequency
47
trend
cancelled
69
trend
SLA
state
61
trend_and_violation
SLA
state
61
Troubleshooting
vi
TWSMSee
Tivoli
Web
Services
Manager
UUDP
protocol,
with
SNMP
Trap
80
user
13
user
assistance
vi
user
roles
v
users
and
passwords
v
utilization,
metric
evaluator
81,
85
Vviolation
3,
69,
77
adjudicating
66,
68,
73
evaluating
2,
17
event
notification
17
imminent
75
SLA
state
61
Wwarehouse
administrator
16
warehouse
pack
viii
Web
siteDB2
vii
IBM
Home
Page
Reader
9
IBM
Software
Support
x,
xi
IBM
Technical
Support
Advantage
ix
IBM
Tivoli
education
ix
IBM
Tivoli
Service
Level
Advisor
support
vii
Web
site
(continued)IBM
WebSphere
Application
Server
viii
Passport
Advantage
ix
phone
numbers
to
order
publications
ix
Software
Support
Handbook
xii
starting
the
SLM
Administrative
Console
4
Tivoli
Software
Glossary
viii
Tivoli
software
library
viii
WebSphere
viii
WebSphere
security
4
weighted
average
performance
84
withdrawn
offering
51
work
area
5
Yyear,
customizing
fiscal
32
Index
135
136
IBM
Tivoli
Service
Level
Advisor:
Managing
SLAs
����
Printed
in
USA
SC32-1247-00
