clearpath os 2200 metering technology - assets.unisys.com · introduction selecting a unisys...
TRANSCRIPT
ClearPath OS 2200 Metering Technology
By: Ron Tanning and Monica LangsfordDorado Metering Development
White Paper
Properly sizing a mainframe system involves some pretty complex calculations and decisions. How much processing power do you need, over the system’s entire life expectancy? Can it grow with your business? Traditionally, you’ve had to evaluate your current requirements, calculate how your needs might change and perhaps do some modeling or benchmarking. Once you bought the system, and reached the upper limit for upgrading it, you simply had to buy a new one.
However, now you have a better choice. We’ll provide you a system with all the capacity you need, and even increase this substantially. What’s more? You’ll pay only for the exact amount of capacity you use. That’s right! We’ll deliver to you a ClearPath Dorado server with our OS 2200 metering technology, together with a significant amount of extra processing power – capacity that is always on and available for your immediate use.
This paper explains our ClearPath Dorado Pay-for-Use business models based on our innovative ClearPath OS 2200 metering technology. It describes how our meters work, how your usage is calculated and how you can use its innovative and unique features to manage your ClearPath Dorado environment and your business operating style too!
2
3
Table of Contents
Introduction 4
Metering and Capacity on Demand 4
Processor Metering Overview 8
Managing a Metering Environment 10
Unisys Metering Services 14
Configuring a Metering Environment 15
Maintaining a Metering Environment 16
Examples 17
Biography 24
Authors 24
IntroductionSelecting a Unisys ClearPath Dorado/OS 2200 system has
traditionally involved a complex decision making process.
Many factors have gone into your choice. Yet, there’s one
issue that’s particularly critical – the right system sizing.
Will it have enough processing power to meet your current
and future IT processing needs? Will it provide the flexibility
needed to grow your business as your processing power
sees growth?
Historically, you made a careful assessment of your
then-current processing-power needs before you decided
how powerful a system to purchase. You made an estimate
of how you anticipated your need for changes over time.
And, perhaps you did some modeling or benchmarking. Once
you purchased a system of a particular size, your business
was locked into that system until it no longer met the
business’ needs. Budgets then allowed you to buy a
new system.
Now you have better, more flexible options, thanks to
today’s ClearPath Dorado Pay-for-Use business models
and ClearPath OS 2200 metering technology that offer an
alternate approach for solving this dilemma. Instead of
purchasing all of the system’s processing power up front,
you can now choose a metered system that can deliver
a very high level of processing power – one that lets you
control its processing capacity and allows you to pay only
for the capacity you use, as you use it, with our innovative
Pay-for-Use licensing models.
Unisys ClearPath metered systems offer two Pay-for-Use
licensing models:
• Pre-Paid Performance licensing let you license up front all
your metered usage. Actual system usage is decremented
monthly from your balance.
• Base-plus-Usage licensing lets you license up front
a certain lower baseline level of system processing
power and be billed monthly for your usage above that
contracted baseline level.
Each of these licensing models uses the same OS 2200
metering technology discussed throughout this paper.
This paper describes the capabilities of ClearPath Dorado
metered servers. It begins with a discussion of what the
meters are and how your usage is calculated, and also
presents the many features and functions that help to
manage your metered environment.
ClearPath OS 2200 metered servers have been introduced
across the family: the Dorado mid-range and the Dorado
high-end since 2004. Recent addition includes the
Intel-based entry and mid-range Dorado servers. These
servers include the measurement, management and
reporting functionality of our metering technology, as well as
flexible Pay-for-Use business models. The flexible Pay-for-Use
business models are available for entry, mid-range and
high-end ClearPath Dorado systems; all running the OS 2200
operating environment.
Metering and Capacity on DemandThe traditional pricing model for large-scale servers is a
Buy-for-Peak approach, wherein the system purchased will be
able to meet the business’ peak demands—and allow for
some pre-defined amount of growth. Capacity planning is critical
in this model to achieve the right balance of meeting peak
capacity needs while minimizing non-peak idle capacity. This
often results in answering peak demands with an adequate,
but not optimal, performance level. Typically, when looking at
utilization patterns on a system, the system is running at peak
capacity at certain times. During this period, there is latent
demand that isn’t being satisfied. If the system had more
resources, that latent demand could be satisfied.
Capacity on Demand (CoD) was the first solution introduced
to address the capacity issues associated with traditional
licensing approaches. Today Capacity on Demand options
are available for all ClearPath Dorado Systems that are
purchased using traditional business model.
The ClearPath OS 2200 Image Enabler performance key(s)
support this business model by providing licensed keys that
enable the level of processing power the customer wants
at the overall system level. Furthermore, the image enabler
keys can allow a system to be split into multiple partitions,
such that processing power is divided among the individual
partitions, while maintaining the overall system processing
power. Performance Redistribution within a partition
can allow the user to increase/decrease single thread
performance by downing or upping IPs.
4
Capacity on Demand comes in one day granularity. Different
types of CoD Image Enabler offerings are available.
1. A Disaster Recovery option for long outages. Disaster
recovery keys can be purchased to enable a site to move its
production workload to a backup system and have adequate
processing power in that temporary environment.
2. An Emergency Recovery option for less serious outages.
3. A Temporary Workload option which allows you to scale
processing capacity up and down on a temporary basis.
Dorado metering takes Capacity on Demand (CoD) flexibility
to a whole new level. Unisys metering technology allows you
to instantaneously tap into extra resources, as and when
needed, and then measures or “meters” the resources that
are consumed. With Dorado metered systems, you no longer
need to license at peak levels, because added performance
is held in ready reserve. Each partition is provided with
potential processing power that greatly exceeds what the
typical workload for that environment needs.
With metering, increasing a partition’s processing power
to meet a temporary spike in demand does not require the
purchase of a special temporary Image Enabler key. Extra
resources are always on and available instantaneously. Also,
adding more processing power to one partition does not
impact the level of power that other partitions have available,
while metered and non-metered partitions can be mixed in
the same system for the greatest flexibility.
In addition to flexibility, the Dorado metering solution also
provides more control than a traditional CoD solution. The
site has operational control over how much of this excess
processing power it wants to tap into, at a moment’s notice.
With a non-metered ClearPath server, a significant increase
in the amount of required processing power would involve
advanced planning and the installation of a new key. With
a metered ClearPath Dorado system, a site administrator
has operational and financial control over the metered
environment and can thus respond to fluctuations in both
service and budget requirements in real time.
How Processing Power is CalculatedThe metering Image Enabler key contains the parameters
needed for calculating utilization, specifically the maximum
running MIPS or ceiling MIPS, and the prepaid MIPS or
baseline MIPS values (both visible to the operator and
administrator). For metering purposes, the system keeps
track of idle time on the processor. Idle time is the
time when the system is not doing work or is actively
looking for work. With this information, usage is calculated
every minute.
Busy time, or non-idle time, is time not spent in either forced
idle or natural idle. Busy time for all active processors in the
configuration is averaged over the minute. Applied to the
configuration’s hardware capable MIPS rating, this gives the
average MIPS usage for that minute. Then, by multiplying
by the exact time period, this gives the metered usage
in MIPS-seconds. The calculations match those done by
performance analysis tools and previous MIPS keys.
All usage information is logged each minute. The log contains
a minute-by-minute report of actual usage, plus any significant
events such as a key change or processor state change or
reboot. The usage information is written to the system log audit
trail and the COD audit trail. Starting with ClearPath OS 2200
Release 11.1, all systems are configured for a COD audit trail
which is a dedicated audit trail for the usage information. The
usage information also continues to be written to the system
log audit trail for compatibility and resiliency.
Metering KeysA Software Controlled Performance (SCP) Image Enabler key
is required for the Dorado metering capability. This metering
key specifies both a performance “ceiling” in terms of MIPS
and a baseline value also expressed in MIPS.
The management of metered keys is similar to previous
MIPS-based Image Enabler keys. They can be installed “on
the fly” and have optional start and end dates. All metered
keys support performance redistribution within a single
image. As you change the number of processors, the system
automatically adjusts to use them appropriately. High-end
servers also allow performance redistribution of a metered
key across alike workload multiple images.
5
The system can have a number of different kinds of workload keys for different partitions
such as General Purpose, Business Information Server (BIS), Enterprise Application
Environment (EAE), Software Development Kit (SDK) and Business Continuation (BC).
DR keys are a special metered business continuance offering that are available to back-up
metered workloads. The metered business continuance workload is delivered via special
metered disaster back-up keys. They contain a baseline of zero and accumulate no charges
as long as the usage remains below 4 percent. These keys are intended for use on
hot-standby systems that are not otherwise being used.
The metered business continuance workload is only available using Pre-Paid Performance
licensing, although it may be used to back-up a primary metered sever that uses either
Pre-Paid Performance or Base-plus-Usage licensing.
ClearPath Dorado Pay-for-Use servers are offered in two different business models designed
to meet different business requirements. For both Base-plus-Usage and the Pre-Paid
Performance models, the ceiling amount limits the maximum power of the system. To control
the upper limit on usage, the system operator, systems administrator or operations manager
can use a “governor” to lower the performance ceiling.
Performance ControlsBefore describing how to control performance in a metering environment, it is worthwhile to
review the capabilities of the existing performance controls.
In traditional computing, you would license a server that could accommodate the peak level
of performance you need to meet. But in metered servers, you can license at your average
run-rate, instead of at the peak.
Traditional Settings
6
In the example above, the client has a key that sets the performance level of the OS
2200 partition (an instance of the OS 2200 operating system) to the peak setting. The
system manages the performance using a “forced idle” technique. The frequency of such
forced idle periods depends on the value in the key and the potential performance of the
current hardware configuration. At several instances during the time illustrated, users were
getting delayed responses, as the system was 100% busy and being constrained by the
performance limit in the key.
Metered severs come with a ceiling many times higher than the average run-rate. This will
typically mean that you receive a system much more powerful than you currently have and
one much more powerful than you would receive if you chose a traditional server.
The extra performance that comes in your system is always on and ready to be used. With
this extra performance that is instantaneously available, comes tremendous flexibility and
agility. It gives one the ability to be prepared for any contingency that may occur.
Together with the ceiling, there is also a baseline value that is expressed in MIPS. The
baseline MIPS setting indicates the MIPS, or MIPS-Months, that have been previously
purchased. If a Pre-Paid Performance model is used, the baseline value will be set to zero
(0). In a Base-plus-Usage model, the baseline is usually equivalent to the expected average
run rate.
Average Run Rate
New Ceiling
Baseline
Performance Controls
The baseline is managed quite differently on a metered system. Using the Base-plus-Usage
model, the client has already paid for the baseline MIPS, but will be billed retroactively
and monthly for usage above that baseline. Alternately, the client can pre-pay for the MIPS
usage, by choosing Pre-Paid Performance licensing. With this approach, the baseline is zero
and the customer reports the number of MIPS-months used each month, which are then
deducted from the Pre-Paid starting MIPS balance. A usage statement, rather than an invoice
is generated each month for clients using Pre-Paid performance licensing.
7
In non-metered or traditional systems white space is that time when you’re running
below your peak level. It is essentially capacity that you’ve paid for but that goes
unused. With metering and Pay-for-Use we can significantly reduce or even eliminate
white space. On a metered system, this “white space” time offsets the time when
running over the average run-rate.
White Space
For example, if running 50% under your average run-rate for 3 hours during the day, and 50%
over your average run-rate for 3 hours a night, those times will offset each other.
This is how metering significantly reduces, and in many cases eliminates, “white space” or
capacity that has been paid for, but not used.
Processor Metering OverviewEach Dorado metered partition measures a client’s actual usage of the system. Data is
collected from each processor every second to determine its percentage utilization. Once
per minute, the data is merged to create a COD trail log entry and a system log entry citing
the MIPS-seconds used during that minute. MIPS-seconds are calculated using the standard
MIPS ratings for each hardware configuration and will match the reports from performance
analysis tools. The calculated system partition utilization is recorded in both the COD audit
trail and the system log.
The COD audit trail is defined in the default configuration and is used as the primary source
for metering data with the system log used as backup. The COD audit trail benefits include
less swapping, reduced f-cycle contention, and faster read access because it only contains
metering data.
Independent processor utilization data is recorded on each metered Dorado partition(s).
The Utilization Report Utility for OS 2200 (URU-OS2200), resides on a Windows PC or server
and collects the usage data from each metered partition via the use of a OS 2200 URU
background run. Automatically, each month, the URU-OS2200 consolidates and reports the
usage for all metered systems to the client and to Unisys.
8
Metering ParametersEach metered partition in a system is known by a set of
metering parameters within the metering key that include the
“ceiling”, “baseline” and “contract identifier”.
The ceiling is the maximum performance level at which the
partition runs, expressed in MIPS.
In a ClearPath metered system with Base-plus-Usage
licensing, the baseline is the amount of processing
power that a customer has paid for up front. Though it is
typically expressed in terms of MIPS, it really represents
“MIPS-months,” or the amount of processing power that is
purchased for a given monthly reporting interval. So when we
say that the baseline is 500 MIPS, it really means that the
baseline is 500 MIPS-months.
Then there’s the question about the duration of a month.
Obviously, some months are longer than others. For the
purpose of metering, a standard month is defined as being
one-twelfth (1/12th) of 365.25 days. This works out to be
30.4375 days or 2,629,800 seconds. This value is used
to normalize a given month’s actual metered usage for
the purpose of comparing it to the contracted baseline
MIPS-months. In a ClearPath metered system with Pre-Paid
performance licensing, the baseline is always zero (0), and
all metered usage is totaled and reported each month. The
accumulated MIPS-Months are decremented at the end of
the monthly reporting interval from the customer’s Pre-Paid
account by Unisys billing.
The contract identifier is set to the System Control Number
(SCN) and is used for reporting. The URU-OS2200 creates
utilization reports based on each specific contract identifier.
Usage is collected from each metered partition, either within
a single Dorado system, or across multiple Dorado systems.
Any usage collected for a specific contract identifier will
be reported in a single utilization report. This way, specific
workload types can be reported in separate utilization
reports, or all utilization can be reported in a single report.
The determination of different contract identifiers is all part
of the agreement with Unisys and is reflected in the metered
Image Enabler key(s).
Metering Reporting IntervalContractual reports are created on the first of each month
by the URU-OS2200 to report the usage for the prior month.
These reports must contain all of the utilization data up to
midnight (UTC) of the last day of the previous month.
It is important to remember that the dates and times that
are used by the metering software are UTC, sometimes
referred to as universal time. This is done so that an
absolute time can be referenced for each of the partitions in
a system. As a result, a site in New York, for example, would
actually generate reports at the same time as a site located
in California.
The URU-OS2200 provides a feature to automatically
generate and deliver an e-mail containing the required
monthly reports. It is strongly recommended that the
automated feature is used to deliver the utilization reports;
however, if it is not configured on site, it is expected that the
site will create the appropriate e-mail to deliver the required
reports on the first day of each month.
Metered Invoice CalculationA key piece of information contained in the monthly
metering report is the billable usage for the reporting
period. The monthly metering report is the same for both
Base-plus-Usage and Pre-Paid Performance metering model.
However, if a Base-plus-Usage license model is used, the
billable MIPS reported in the monthly meter report is the
number of MIPS-Months that will be charged for the billing
period. In a Pre-Paid Performance model, the billable MIPS
value is the number of MIPS-Months that will be deducted on
the invoice for the billing period.
Usage is reported on a Dorado system using MIPS-months.
MIPS-months are calculated using a standard month that is
365.25 days * 24 hours * 60 minutes * 60 seconds / 12 or
2,629,800 seconds. The baseline is also normalized to this
standard month. The reported value for billable MIPS-months
reflects the number of MIPS-months that were metered
above the contracted baseline for the reporting period.
With Base-plus-Usage licensing, assuming that the baseline
is 600 MIPS and average usage over the month of August
was 620 MIPS, the report would show:
Baseline for reporting period = 611.0882957 MIPS-months
Usage for reporting period = 631.4579055 MIPS-months
Billable usage for reporting period = 20.370 MIPS-months
9
The contracted rate, as previously determined for the specified Contract ID, would be applied
to the reported billable MIPS-months on the invoice.
With Pre-Paid Performance licensing, the baseline will be set to zero. Therefore, all reported
MIPS-Months are reported as billable MIPS-Months. The monthly meter report would show:
Baseline for reporting period = 0.0000000 MIPS-months
Usage for reporting period = 631.4579055 MIPS-months
Billable usage for reporting period = 631.458 MIPS-months
The billable MIPS-Months would be deducted from the total MIPS-Months purchased, and the
remaining MIPS-Months, as contracted, would be indicated in the invoice.
Managing a Metering EnvironmentOS 2200 metering software provides a variety of tools you can use to manage your metering
environment. As we’ll explain later in this document, Unisys offers you the technical
consulting services you need to size, monitor and maintain your metered environment.
Many leading third-party vendors that provide performance measurement services have also
updated their capabilities to address metering environments. This section describes some
of the easy-to-use tools that we’ve integrated into the OS 2200 environment to provide the
capability of managing metered performance.
The Metering GovernorWhen all of the processors in a partition are busy, the partition is running at the maximum
performance level described by the ceiling. While there are times when you need the
absolute maximum power possible, there are other times when a reduced level of
performance is sufficient (and paying for maximum performance isn’t necessary). ClearPath
metered systems provide you a metering “governor” that lets you lower the number of ceiling
MIPS available. This is accomplished by changing the desired_mips setting. Utilizing the
governor may help reduce expenditures in the case of possible runaway programs. Reducing
the ceiling MIPS may reduce response times, and may also increase task completion times.
The governor is a powerful tool that lets you adjust the processing power of your system
to match your current business needs. Most businesses have predictable periods of
peak demand as well as periods of less demand. If an unexpected spike in processing
power demand presents itself, you can increase the processing-power of your system on
the fly to meet that demand. All you have to do is issue a single MIPS keyin command at
the system console.
The effective range of the governor is between the baseline and the ceiling. The
administrator cannot affect the key-imposed ceiling, but the number of MIPS available can be
effectively reduced by use of the governor. Conversely, lowering it below the baseline will not
affect expenditures. Because the system requires a minimum amount of processing power
to function in a consistently stable manner, setting the baseline to a value below 8% of the
maximum hardware capable MIPS is not supported.
10
Governor
Metering Security ControlsBecause the governor setting has significant financial implications, it’s vital that you have
absolute control over its use. The governor setting is equivalent to the desired_mips setting.
The site can change the value of the minimum_mips, desired_mips, or maximum_mips
parameters by updating the EXEC configuration (ER CONFIG$). In this case, the
SSCONFIGMGR security privilege is required. Additionally, if the value of maximum_mips
is updated to a non-zero value, the MIPS console keyin can then be used to change the
desired_mips setting. This keyin is only available at the main system console. If the EXEC
configuration is updated such that the desired_mips value can be updated using the console
keyin, limited access to the main system console should be in place in order to limit the
capability of changing the metering governor setting.
Various security measures have also been put in place on the Dorado systems in order to
ensure the validation of metering data. Essentially, these mechanisms can be viewed as
checkpoints to verify the metering data before it is reported for billing purposes.
First, when COD log entries are written on the OS 2200, an electronic signature is calculated
and stored within the entry itself. This electronic signature identifies the actual data written
in the log entry. Then, when the URU-OS2200 collects each log entry, it maintains the
electronic signature along with the specific data from each log entry. During the report
process, the URU-OS2200 verifies the electronic signature against the associated data.
If the electronic signature does not match the associated data, it will not be used in any
calculation. The electronic signature is used to determine if the data was altered subsequent
to the time it was written.
Similarly, when a specific report is created, an electronic signature is maintained for the
completed report. At the bottom of each report the electronic signature is indicated. When
Unisys receives the report for billing, this electronic signature is used to verify the reported
values. If the values within the report had been altered before the report was submitted, the
report validation would fail.
By using these security measures, Unisys and each specific metering site can rest assured
that valid data is being recorded and reported.
11
Monthly Meter ReportsOn the first of each month, the URU-OS2200 will generate monthly utilization reports, called
Contractual reports. Contractual reports contain all utilization for a specific contract identifier
collected for the previous month. The transport that is used to send metering reports is
e-mail. The monthly metering e-mail has a specific subject line, clear text in the body and
requires at least one attachment.
The required attachment is the Utilization Summary report. This report is intended for use by
Unisys, which will use it in combination with the client’s contract to construct an invoice or
usage statement. The summary report specifies the contract identifier from the key and the
specific reporting period. All usage being reported will be expressed as MIPS-months used
over the reporting period.
The Utilization Summary report summarizes the utilization for all partitions reporting usage
for the particular contract identifier. Subtotals are provided for specific partitions, MCNs and
metered key ids. The total MIPS-months and billable MIPS-months can be seen at the end
of the report. If a determination is made that data is missing for the reporting period, an
indication is made in the report. An electronic signature is used at the end of the report to
ensure that the report submitted has not been altered since creation.
MIPS-months are calculated using a standard month that is 365.25 days * 24 hours * 60
minutes * 60 seconds / 12 or 2,629,800 seconds. The baseline is also normalized to this
standard month.
Assuming that the baseline is 600 MIPS and average usage over the month of August was
620 MIPS, the report would show:
Baseline for reporting period = 611.0882957 MIPS-months
Usage for reporting period = 631.4579055 MIPS-months
Billable usage for reporting period = 20.370 MIPS-months
A second output, attached to the email by some levels of URU, is the Utilization Detail report.
This is not a required attachment. This detailed report includes all the recorded usages and
associated system events for the specified contract identifier and the reporting period. It is
directly associated with a corresponding Utilization Summary report. It may be used by the
client’s analysts and Unisys staff to understand the data behind the usage reported. This
detailed data is sent as an attachment in CSV (comma separated variables) format that can
be easily imported into a spreadsheet. Again, an electronic signature is used at the end of
the report to ensure that the report submitted has not been altered since creation.
Refer to the Examples section of this document for details about specific report formats.
12
Report utility
-
-
-
COD trail/system log
How Usage is Reported
As stated above, utilization reports are expected to be submitted via e-mail. The
URU-OS2200 provides a feature that will automatically create the appropriate e-mail and
deliver the required reports as they are created each month. In order to ensure on time
delivery, it is strongly recommended that this feature be used for submitting monthly reports.
However an alternate option is that the client will first locate the generated utilization reports
(the summary and detail reports) and then forward them as attachments in an e-mail to
Unisys using the documented e-mail format.
Transmission of Report to Unisys
In the interests of both parties, Unisys will raise an alert if the expected monthly report does
not arrive.
13
Interim meter reportsThe URU-OS2200 enables you to create an interim metering
report for your own use. An interim report can be requested
for any date and time range up to a complete billing period.
An interim report can be used to track the MIPS-months
usage or current metering values. Interim reports follow the
same format as contractual, or billing, reports. Utilization
Summary, Utilization Detail reports, or both, can be created
for the specified contract identifier and billing period(s). Interim
metering reports can be used to track MIPS-months usage
throughout the current billing period.
Please refer to the Examples section of this document
for information about what is displayed for an interim or
contractual report.
Querying the Metering SettingsThe MODELNUM console keyin can be used in order to
provide the current metering settings. The output for this
request provides several items of information related to
system metering and is available via the operator’s console.
The output of the console keyin includes metering-specific
information, including the unique metering key identifier and
related key information. For each metering partition on the
system, the interface also provides settings of the baseline
value, the governor settings (both target and actual values),
the workload type and the ceiling.
Please refer to the Examples section of this document for
more details about what is displayed for the MODELNUM
console keyin.
Changing the Metering KeyThere may be cases in which your organization and Unisys
agree to modify your metering contract. For example, you
may want to increase your metering baseline. After the
contract is updated, you are given a new Image Enabler
MIPS metering key for implementing these changes. This
section discusses the effect that changing the metering key
has on your monthly metering reports.
It is expected that a new contract identifier will be specified
for the new contract agreement. After the “new” metered
key is registered on an OS 2200 partition, usage will
continue to be recorded; however, the log entries tracking
the usage will indicate the “new” contract identifier. Since
the URU-OS2200 creates utilization reports based on unique
contract identifiers, usage under the “new” metered key
will be reported in separate utilization reports. All generated
usage reports will be submitted for the month to ensure all
usage is reported for billing purposes.
System Logging of Metering InformationAs stated throughout this document, system usage is
recorded in the COD and the system log. These log entries
are available to other tools and applications that are able
to retrieve them from the metered OS 2200 partitions.
Depending on the site sophistication, these additional tools
and applications can be used to track and analyze usage
simply by collecting and processing the usage log entries.
Metering MIPS Use vs. SIP IP UseURU derived MIPS utilization matches the IP utilization reported
by the standard performance analysis tools that is SIP.
Unisys Metering ServicesIt is important that a well informed decision be made when
moving to a metering system. This involves having a good
understanding of the processing-power needs of your current
system, how this might change when moving to a metering
system and how the various metering settings would affect
your metered usage costs.
For this reason, Unisys offers several services designed to
help customers make the right choice and to help them
manage their metering environment on an ongoing basis.
Performance Baseline and Validation ServiceThis Unisys service is accomplished in two phases. The
first phase involves taking a performance baseline on
your existing ClearPath system to determine the current
processing-power needs. Your processor utilization patterns
are sampled over a period of time and processed by
our technology consulting services (TCS) consultants to
determine how that usage would translate into a metered
system’s processing-power. Our consultants can then work
with you to identify the metering settings (ceiling, baseline
and governor) required to meet your future needs. The
second phase takes place after the metered system is
installed. A second set of data is collected on your metered
system to ensure the client is optimizing its metered system
to ensure the metered system is optimized to give you
maximum efficiency.
14
Performance Modeling and Validation ServiceThis Unisys service also begins with a performance-baseline
phase. Data gathered during this phase is then run
through analytical models to predict the effects of
system configuration changes or the compound effect of
your organization’s continued growth. This is a valuable
tool to determine the effects of any significant capital
expenditures you make, configuration changes and
business expansion before you make an investment. The
second phase takes place after your metered system
is installed. A second set of data is collected on your
metered system to ensure that your metered system is
optimized to achieve maximum efficiency.
Performance Benchmark and Validation ServiceThis Unisys service involves taking your applications, data
and workload to a Benchmark center, for their execution
on a metered server. After collecting the baseline data on
your existing ClearPath system, the recommended metering
settings are then confirmed in a live metering environment,
before being installed at your site. Once these settings are
finalized and your metered system is installed, a second set
of data is collected on your metered system to ensure that it
is optimized to deliver maximum efficiency.
Performance Analysis for Metered Systems ServiceOnce you’ve moved to your metering system, this Unisys
service is available to analyze the performance of your
metered system and identify any actions that can be taken
to further improve your system’s performance and use its
metering more efficiently. Recommendations can be made
on how to best manage your metered costs.
We highly recommend that any clients considering a
metering system take advantage of these services. Doing
so ensures that the ultimate metering environment is best
configured to maximize the benefits of ClearPath Pay-for-Use
business models and metering technology.
Configuring a Metering EnvironmentConfiguring a metering environment is straightforward. This
section describes the required configuration steps as well
as options some customers might want to consider. To
summarize, a metered system customer must take these
steps in order for metering to function properly:
• Minimum level of system software installed
• Utilization Report Utility for OS 2200 installed and running
on Windows PC workstation/server having
- A TCP/IP connection to OS 2200 metered partitions
- E-mail access from PC workstation/server or alternate
e-mail capability
• URU OS 2200 background run installed and running on OS
2200 metered partition
• Metering key registered
Each metered system customer has the option to have its
metering reports sent to one or more user-specified e-mail
address/es in addition to the reports being sent to the
Unisys billing center.
Minimum System Software LevelsMetering on Dorado Models was released in GCA level of
OS 2200 ClearPath Release 10.1 and is available on all
supported GCA levels of OS 2200 ClearPath as released
in the Unisys Operating Environment (UOE), the super-set
of the Integrated Operating Environment (IOE) available on
non-metered Dorado servers.
Registration of the Metering Key As with the required system software levels, a Dorado
Model system being shipped from Unisys will come with the
metering image enabler key(s).
Installation and activation of a metering image enabler key
can be done dynamically. Just as is done for non-metered
MIPS-based keys, SOLAR is used to register MIPS metered
image enabler keys. Once the “new” key is successfully
registered, any previous key settings will be replaced with
the “new” key settings.
15
Usage Data and E-mail ConnectionsThe calculated system utilization is recorded in the COD and
the system log audit trails. In order to allow the URU-OS2200
the ability to collect this data, a TCP/IP connection must
be configured between each OS 2200 metered partition
and the Windows workstation or PC where the URU-OS2200
is installed. Each OS 2200 metered partition must
be configured in the URU-OS2200 using the provided
user-interface. Each OS 2200 metering partition must have
the URU background run installed and running. Then, at a
set interval, the URU-OS2200 connects to each configured
OS 2200 metered partition via the TCP/IP connection and
collects all recorded utilization data.
On the first day of each month, the URU-OS2200 generates
all required utilization reports for the prior month based
on the utilization data collected. It is recommended that
the automatic reporting feature be enabled as part of
the URU-OS2200 configuration. This feature will provide
automatic e-mail delivery of all generated reports. In order
to utilize this feature, there must be connectivity to an
SMTP server from the Windows workstation or PC where the
URU-OS2200 is installed. Note that a local e-mail application
is not required on the workstation or PC. If there is no
connectivity from the workstation or PC to an SMTP server,
the e-mail must be created manually and the reports must
be attached following the documented format.
Configurable Meter Report DestinationsThe automatic reporting feature in the URU-OS2200 must
be enabled in order for monthly utilization reports to be
automatically e-mailed. By default, monthly metering reports
are sent to a Unisys e-mail address to determine whether a
metering invoice is required. You can choose to have a copy
of these reports e-mailed to additional e-mail addresses.
This is accomplished by updating configuration settings in
the URU-OS2200. The default Unisys billing e-mail address
provided in the default configuration should not be deleted;
however, additional e-mail destinations can be added.
Maintaining a Metering EnvironmentThis section provides some recommended practices to
follow in maintaining a metering environment.
Managing Usage DataThe resiliency of the metering data collected by URU is
provided by the following pieces: the metering audit trail
records on each OS 2200 system, the metering data in the
URU database, and the monthly metering reports produced
by the URU.
The metering audit trail records on each OS 2200 system
are written to the COD audit trail and also to the system
log audit trail for resiliency. The URU Service first harvests
from the COD audit trail and then from the system log file, if
needed. The COD and the system log file defaults allow, at a
maximum, 32 individual cycles to exist at any one time. With
the default configuration of the COD audit trail, the 32 cycles
contain approximately 5 months of metering data. The COD
audit trail and the system log audit trail may be reconfigured
by the site.
After 32 cycles have been created, the oldest cycles may
either be archived or deleted. An OS 2200 log management
plan includes regular backup and removal of older log cycles.
There are several mechanisms you can use to back up these
log file cycles before they are deleted. Unisys recommends
using the Integrated Recovery Utility (IRU) MOVE command
(see the ClearPath Enterprise Servers Integrated Recovery
Utility Operations Guide for more information). The IRU
MOVE command creates a copy of the log on tape and
records information about the tape in a move history file.
Subsequent use of IRU or a utility that uses IRU’s FSAH (Free
Standing Audit Handler), such as the URU, can read this
move history file to obtain audit information when the file
cycle is no longer on mass storage. All other IRU audit trail
related functions, such as reporting, are supported for COD
and system log audit trails.
When an OS 2200 metered partition is configured within the
URU-OS2200, MIPS usage log entries are harvested from
that host; these log entries are stored in a Microsoft Access
database found in the <URU Installation Path>\Data folder.
This data is required for MIPS usage report generation.
16
To ensure that no data is lost between the OS 2200 partition and the URU, the MIPS
metering data should be retrieved from the OS 2200 partition and then the Data folder
should be backed up. Backing up the Data folder should occur at intervals that ensure that
data from the existing COD and system log file cycles are harvested or archived before the
maximum number of file cycles is reached.
The metering data in the URU database can be retained indefinitely, but doing so may
decrease the efficiency of processing the data. Configuration options exist to specify the
number of months of metering data to retain. Backing up the URU database on a daily basis
is not necessary, as it can be recreated from data on the OS 2200 relatively quickly. At a
minimum, it is recommended to back up the URU database on the Windows server monthly,
as that corresponds to the metering reporting period. If the database is backed up after the
monthly metering reports are sent, restoration of the data will not cause the reports to be
regenerated (and possibly resent.)
Unisys also recommends that the client back up the URU contractual report directory
containing the completed URU monthly reports.
Unsuccessful Metering Report TransmissionIn the event that Unisys does not receive an expected monthly metering report, then Unisys
will contact the customer to request that the metering report be resent. This will involve
sending an e-mail to the OS 2200 Metering e-mail address. The e-mail must contain the
Utilization Summary report and must follow the defined e-mail format. Previously generated
Contractual reports can be found in the “Contractual Reports” directory under the default
installation path for the URU-OS2200 on the workstation or PC or can be reproduced via the
URU-OS2200 using the URU database.
ExamplesThe performance values shown in the following examples are provided purely as a way to
convey how the metering software works. These performance values do not in any way
represent the actual performance that a metered system would deliver.
Querying the Metering SettingsThe MODELNUM console keyin is used to display the current metering settings. The following
example shows sample output from a MODELNUM keyin on an OS 2200 metered partition
using Pre-Paid Performance licensing (baseline MIPS set to 0).
Line 1: SCP Exec Key MCN: 513301689 PDB MCN: 222000085
Line 2: NORMAL KEY Model: UOL20792-999 Performance Level: 100%
Line 3: Key ID: M513301689-1 Partitionable: YES
Line 4: Key MIPS: 0 Baseline MIPS 24975 Ceiling MIPS
Line 5: Expiration Date: 2013-12-31 Hard Expiration Date: NONE
Line 6: Contract ID: 0200011 SCN: 0200011
Line 7: Java IPs: 2
Line 8: Desired MIPS = 24975, Minimum MIPS = 0, Maximum MIPS = 24975
Line 9: This partition (RS06 ) is using 2535 MIPS.
Line 10: No other partitions are using this key.
17
Line 1 – Displays the MCN both from the hardware and from the PDB
Line 2 – Displays the Model and Software Controlled Performance (SCP) level
Line 3 – Displays the image enabler key identifier and the indication if the image enabler key
is a partition-able key
Line 4 – Displays the values for both the baseline and ceiling MIPS as defined by the
registered image enabler key
Line 5 – Displays the expiration date of the image enabler key
Line 6 – Displays the contract identifier and SCN as defined in the image enabler key
Line 7 – Indicates the number of IPs reserved for Java use only
Line 8 – Displays the current MIPS settings including the current governor setting, which is
specified by the desired_mips value along with the current settings for minimum_
mips and maximum_mips
Line 9 – Displays the name of the OS 2200 metered partition along with the current
SCP utilization
Line 10 – Reports any other OS 2200 partitions using the same key (only applies to
partition-able keys)
Monthly Metering Report E-mail TextMonthly utilization reports are submitted using e-mail. The subject line of that e-mail must
specify the SCN/MCN being reported (found in the report itself) and must end with the words
“OS2200 METER REPORT.”
Subject: <SCN/MCN> OS2200 METER REPORT
The body does not require text. However, if the e-mail is automatically created by the
URU-OS2200, the following body text will appear:
Body Text: This email and attachments are part of the URU’s automatic email software.
The .TXT attachment contains the summary report.
A Utilization Summary report must be submitted each month. The Utilization Summary
report must be a text file (.TXT). A Utilization Detail report may be also attached but it is not
required.
Attachment 1 – Utilization Summary Report (.TXT)
Attachment 2 – Utilization Detail Report (.CSV)
Utilization Summary Report Text. This section provides an example of a Utilization Summary report. The text of the report is
presented, followed by a line-by-line explanation.
It is important to note that the format of the Utilization Summary report is the same for
both Pre-Paid and Base-Plus-Usage models. However, in a Pre-Paid model the baseline
MIPS-Months will always be zero and the billable MIPS-Months will be deducted from the total
MIPS-Months purchased. In the Base-plus-Usage model, the baseline MIPS-Months represent
the MIPS-Months previously paid for and the billable MIPS-Months are the MIPS-Months that
will be billed for at the contracted rate.
18
Utilization Summary reports generated automatically for billing purposes and Interim reports
generated at the request of an administrator are created using the same format. The Report
Type can be used to determine the difference.
19
COD Usage Summary Report
Line 1. Report Date & Time 2 0100501-021828(local time)
20100501-071828(UTC time)
Line 2. Source OS Type OS2200
Line 3. Contract ID ROSEVILLES06
Line 4. Report Type Contractual
Line 5. Report Version 4
Line 6. Detail Report 20100501-071828-ROSEVILLES06.csv
Line 7. Billing Date 1
Line 8. Report Interval 20100401 000000 - 20100430 235959 (UTC time)
20100331 190000 - 20100430 185959 (local time)
Line 9. Key ID M513301689-1:
Line 10. Baseline MIPS 0
Line 11. Ceiling MIPS 24975
Line 12. Model Number UOL20792-999
Line 13. SCN 999999999999
Line 14. MCN 513301689:
Line 15. Partition RS06:
Line 16. Total Used (MIPS-Months) 253.05687467
Line 17. Baseline MIPS (MIPS-Months) 0.00000000
Line 18. Billable MIPS (MIPS-Months) 253.057
Line 19. ** First Data Record Date/Time (UTC): 20100401 000000
Line 20. ** Last Data Record Date/Time (UTC): 20100430 235900
Line 21. MCN 513301689 (Total)
Line 22. Total Used (MIPS-Months) 253.05687467
Line 23. Baseline MIPS (MIPS-Months) 0.00000000
Line 24. Billable MIPS (MIPS-Months) 253.057
Line 25. Key ID M513301689-1 (Total)
Line 26. Total Used (MIPS-Months) 253.05687467
Line 27. Baseline MIPS (MIPS-Months) 0.00000000
Line 28. Billable MIPS (MIPS-Months) 253.057
Line 29. Keys used:
Line 30. M513301689-1
Line 31. SCN values found for Contract ID (ROSEVILLES06):
Line 32. ̀ 999999999999
Line 33. Contract ID ROSEVILLES06 (Total)
Line 34. Total Used (MIPS-Months) 253.05687467
Line 35. Baseline MIPS (MIPS-Months) 0.00000000
Line 36. Billable MIPS (MIPS-Months) 253.057
Line 37. CHECKSUM-GENERATED 152369
20
Line 1 – Date and time the report was created. Both local time and UTC time
are displayed.
Line 2 – Always OS2200.
Line 3 – Contract identifier for the entire report. Utilization is reported for a single
contract identifier, as specified in the metered key.
Line 4 – Report type, Contractual (billing) or Interim.
Line 5 – Report version. The report format may change between version settings, so
this value is used to ensure the correct report format.
Line 6 – This line reports the name of the corresponding detail report that was produced.
Line 7 – The billing date within the month for the contract identifier, as specified in
the metered key.
Line 8 – Report interval showing the start date and time, and the end date and time for
this report. In a Contractual report, this will correspond to the billing period. In
an Interim report, this date and time range may be a complete billing period, but
it may also be a smaller date and time range, as requested.
Line 9 – The first key identifier being reported. This example shows the use of a
single key; however, if multiple keys were used having the same contract
identifier, additional key identifier sections would be created following each
key identifier summary.
Line 10 – The number of Baseline MIPS, as specified in the metered key.
Line 11 – The number of Ceiling MIPS, as specified in the metered key.
Line 12 – This line displays the model number for the key identifier in line 9.
Line 13 – This line displays the Software Control Number (SCN) for the key identifier in
line 9.
Line 14 – Machine Control Number (MCN) of the first system reporting usage for the
specific key identifier and contract identifier. This example shows usage
for a single MCN; however, if multiple MCNs were reporting usage for the
same key identifier and contract identifier, additional MCN sections would be
created following the MCN summary.
21
Line 15 – Partition name of the first partition reporting usage for the specific MCN,
key identifier and contract identifier. This example shows usage for a single
partition; however, if multiple partitions were reporting usage for the same
MCN, key identifier and contract identifier, additional partition sections
would be created following the partition summary.
Lines 16 to 17 – These lines are the Partition subtotals for the reported partition, MCN, key
identifier and contract identifier.
Line 16 – This line shows the total usage in MIPS-Months, as calculated, for the
specified partition, MCN, key identifier and contract identifier.
Line 17 – This line shows the baseline usage in MIPS-Months, as calculated, based on
the baseline setting found in the metered key.
Line 18 – This line shows the total billable usage in MIPS-Months, as calculated. This
value is the number of total usage MIPS-Months over the based MIPS-Months.
If the total usage MIPS-Months is less than the baseline MIPS-Months, the
billable MIPS-Months would be zero (0). Since this example shows a Pre-Paid
Performance model, the baseline is set to zero (0). Therefore, all usage
MIPS-Months are billable. In a Base-plus-Usage model, the baseline would be
set to the number of MIPS-Months previously purchased.
Lines 19 to 20 – These lines show the date and times of the first and last MIPS entries
included in the report.
Lines 21 to 24 – The values in lines 22 - 24 are the MCN subtotals for the reported MCN in
line 21, key identifier in line 9 and contract identifier in line 3. The values
are the sum of all reported partition subtotals.
Lines 25 to 28 – The values in lines 26 – 28 are the key identifier subtotals for the reported
key identifier in line 25 and contract identifier in line 3. The values are the
sum of all reported MCN subtotals.
Lines 29 to 30 – These lines specify all key identifiers used throughout the report. This information
can be used to ensure that all registered metered keys are reported.
Lines 31 to 32 – These lines specify all the SCN values found for the contract listed in line 31.
Lines 33 to 36 – The values in lines 34 - 36 are the report totals for all partitions, MCNs, and
key identifiers reporting usage for the specified contract identifier in line 33.
These values are the sum of all reported key identifier subtotals.
Line 37 – This is the electronic signature, as calculated for the report. Validation is
done using this value upon receipt of the report to ensure that the contents
of the report have not been altered since the report was written.
Utilization Detail Report CSV formatThe Utilization Detail report is in Comma Separated Value (CSV) format, making it easy to
import the data in the attachments into a spreadsheet. The next example shows a portion of
a raw CSV format attachment, and how it looks after being imported into the spreadsheet.
Utilization Detail reports generated automatically for billing purposes and Interim reports
generated at the request of an administrator are created using the same format. The
Report Type is specified in the report heading row which has Subtype set to zero (see Line 2
explanation below).
Raw CSV Format Data:
Note: Some of the lines in the following report have been wrapped; in an actual Detail
Report they are not formatted that way.
Log Date, Log Time (UTC), Log Sub-Type, Rec Version, Key ID, MCN, Partition Name,
Expiration Date, MIPS Seconds, Interval, Mask of IPs Running, Desired MIPS, Running
MIPS, Baseline MIPS, Ceiling MIPS, IP Name, Recording Period, Averaging Period, Report
Period, Reporting Day, SCN, Key Type, Model Num, Max MIPS IP, Hard Expiration, System
Perf Level, RESYNC Old Date, RESYNC Old Time
20100501, 021843, 0, 20100501, 071843, OS2200, NA, ROSEVILLES06, Contractual,
Version 4, 20100401 000000, 20100430 235959, 1,
20100501-071828-ROSEVILLES06.txt
20100401, 00000000, 7, 4, M513301689-1, 513301689, RS06, , 1657, 59999999, 0377
20100401, 00010000, 7, 4, M513301689-1, 513301689, RS06, , 7971, 59999997, 0377
20100401, 00020000, 7, 4, M513301689-1, 513301689, RS06, , 1607, 59999999, 0377
20100401, 00030000, 7, 4, M513301689-1, 513301689, RS06, , 1349, 60000001, 0377
20100401, 00040000, 7, 4, M513301689-1, 513301689, RS06, , 1601, 60000004, 0377
20100401, 00050000, 7, 4, M513301689-1, 513301689, RS06, , 1800, 60000005, 0377
20100401, 00060000, 7, 4, M513301689-1, 513301689, RS06, , 2491, 59999992, 0377
20100401, 00070000, 7, 4, M513301689-1, 513301689, RS06, , 1865, 60000000, 0377
20100401, 00080000, 7, 4, M513301689-1, 513301689, RS06, , 1699, 60000001, 0377
20100401, 00090000, 7, 4, M513301689-1, 513301689, RS06, , 1578, 59999999, 0377
20100401, 00100000, 7, 4, M513301689-1, 513301689, RS06, , 1757, 60000002, 0377
20100401, 00110000, 7, 4, M513301689-1, 513301689, RS06, , 1347, 59999998, 0377
20100401, 00120000, 7, 4, M513301689-1, 513301689, RS06, , 1637, 59999999, 0377
20100401, 00130000, 7, 4, M513301689-1, 513301689, RS06, , 1469, 60000006, 0377
20100401, 00140000, 7, 4, M513301689-1, 513301689, RS06, , 1787, 59999998, 0377
20100401, 00150000, 7, 4, M513301689-1, 513301689, RS06, , 1471, 59999996, 0377
22
Deciphering a metering CSV format fileLine 1 – The first line of the report contains all column headers. Therefore, when this file is
loaded into a spreadsheet, the column headers will appear at the top and represent each
individual column in the spreadsheet.
Line 2 – The second line contains a special subtype value of zero (0). Subtype zero (0) is
an invalid subtype. It indicates that the information on this line does not comply with the
defined column headers. This line specifies the report header information as follows: Local
report creation date, local report creation time, subtype (always 0), UTC report creation date,
UTC report creation time, source OS type (always ‘OS2200’), ‘NA’, contract ID, report type
(contractual or interim), report version, report interval start date and time, report interval end
date and time, billing date, and location of detailed report.
Line 3 through n – All remaining lines contain data. Each line is a specific log entry. The
specific fields used in each log entry are defined based on the subtype field. If no value
exists in a specific log entry, an additional comma will be included in order to ensure that all
fields populate the appropriate columns when loaded into a spreadsheet.
The following is an example of a portion of a monthly metering report file CSV attachment, as
it would appear after being imported into an Excel spreadsheet:
23
For more information visit www.unisys.com
©2011 Unisys Corporation. All rights reserved.
Unisys and the Unisys logo are registered trademarks of Unisys Corporation. All other brands and products
referenced herein are acknowledged to be trademarks or registered trademarks of their respective holders.
Printed in the United States of America 06/11 11-0203
Biography
AuthorsRon Tanning is a Unisys OS 2200 software engineer overseeing the various Software
Controlled Performance (SCP) with the Capacity On Demand (COD) aspects that started in
1997 on the first ClearPath system. Ron has worked on a variety of OS 2200 development
projects and continuation support during his 40 years with Unisys. Patent # 6,978,374
“Authorization key system for selectively controlling the performance of a data processing
system” was awarded to the SCP team of which Ron is a member. Patent Application #
20050138422 “System and method for metering the performance of a data processing
system” was submitted by the SCP team.
Monica Langsford is a Unisys OS 2200 software engineer and a member of the URU-OS2200
product team. Monica has worked on a variety of OS 2200 development projects and
continuation support primarily in the areas of TIP and Integrated Recovery including URU, IRU
and XTC.