ClearPath OS 2200 Metering Technology - assets.unisys.com · Introduction Selecting a Unisys...

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:




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:




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 25. Key ID M513301689-1 (Total)




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 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.

ClearPath OS 2200 Metering Technology - assets.unisys.com · Introduction Selecting a Unisys...

Documents

Transcript of ClearPath OS 2200 Metering Technology - assets.unisys.com · Introduction Selecting a Unisys...