I've been in this business for decades and have never once observed a 
deliberate conspiracy to cheat a vendor. Frequent ads about 'piracy' conjure up 
boardrooms full of Captain Hooks comparing the size of their parrots while they 
chart cheating schemes. It doesn't happen. 

OTOH I've become aware of a few unauthorized or inadvertent violations. One 
involved a cowboy operator who copied an ISV product to an environment for 
which it was not licensed. He thought he had found a better way to do his job. 
Nasty fallout. Another case concerned PSF, where the contract specified a 
certain volume of AFP print--not CPU MSUs. No one noticed that the limit had 
been exceeded until a routine IBM audit revealed the excession. The piper was 
paid.

The alternative to customer self-regulation is a complex of software keys and 
usage monitors. As a long-time customer, I believe that IBM places a high 
priority on the customer's business. This means keeping it running while 
anomalies are sorted out and resolved. I've experienced major business 
interruptions when *other* vendors' products simply stop working when some cap 
is exceeded, consequences be damned. Be very careful what you wish for.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
[email protected]


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Wednesday, October 18, 2017 5:37 AM
To: [email protected]
Subject: (External):Re: Potential stupid question - MSUs

Thanks Bob, yes I'm fairly comfortable with the sub-capacity reporting for IBM.
From time to time, I get these questions in my head such as, what would happen 
if IBM were to try and implement a per-second billing sort of thing that cloud 
providers do.
Real-time enforcement/monitoring will also allow shops to know their usage (of 
s/w by diff vendors) and pay for just that instead of something as broad as 
charged-for-CPU-limit-eventhough-it-may-not-be-used, and wait for a really long 
time before the ability to renegotiate.

This may mean extra $$ for most, and there's no dearth of complexity in 
pricing, but... these things are fun to learn sometimes with examples.

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Richards, Robert B.
Sent: 18 October 2017 15:44
To: [email protected]
Subject: Re: Potential stupid question - MSUs

Vignesh,

Whether or not enforcement is even necessary depends on your software contract 
with IBM. If you do not mind paying for full capacity (let's use the 30 MSUs  
that Tim liked as the max capacity), then you can choose to just pay IBM 6,000 
rupees every month (30 times 200 rupees) and not worry about sending IBM any 
usage information. Most companies do not want to just give money away, 
especially if you know you can't always get to the peak of 30 MSUs.

Enter the sub-capacity software contract with its terms and conditions. Once in 
force, you are required to send IBM a report every month. That report is 
created by culling certain SMF records from every lpar and having them read by 
a tool that IBM provides called the Sub-Capacity Reporting Tool (commonly known 
as SCRT). Assuming that you only peak at 20 MSUs in a given month, then your 
software bill would only be 4,000 rupees. Put the 2,000 rupees that you 
effectively saved that month (assuming you budgeted for full capacity) to good 
use. Maybe for a tool that audits the SCRT report called LCS <grin>.

The SCRT report is the enforcement tool *after the fact*, but only if the 
sub-capacity contract is in play. Good faith or not....IBM software contracts 
are legally binding.

Bob

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Timothy Sipples
Sent: Wednesday, October 18, 2017 12:40 AM
To: [email protected]
Subject: Re: Potential stupid question - MSUs

Vignesh Sankaranarayanan wrote:
>....but for some reason, I just can't fathom a vendor leaving the 
>enforcement of a rule up to a customer, and letting the contract 
>(something completely detached from the machine) be the only binding 
>factor.

Is that so hard to imagine, though?

Let's suppose you rent an apartment, and you sign a lease. The lease contains 
certain terms and conditions. Those terms include, as possible
examples:

1. You cannot sublet (rent out) the apartment to someone else without the 
landlord's permission.

2. You cannot make major modifications to the apartment, such as paint the 
walls with alternating pink and black stripes.

3. You cannot start an open fire inside your apartment and roast marshmallows 
(or anything else).

4. You cannot keep a tiger, lion, elephant, or alligator in the apartment.

If you violate the terms of the lease, you face certain penalties, enforced 
through the courts (hopefully).

Does the landlord have video cameras installed the apartment, with 
round-the-clock surveillance, to make sure you are living up to your 
contractual obligations? No, usually not. In fact, in most jurisdictions, the 
landlord has only very limited rights to enter the apartment, under specific 
conditions that seldom apply.

Contracts routinely depend on the parties having "good faith," with voluntary 
compliance as the default behavior. This approach works especially well when 
the parties have an ongoing, mutually beneficial relationship of some kind. For 
example, software vendors and licensees typically have some sort of support and 
subscription agreement. There are also what are known as "due diligence" 
checks, before you do business with someone. A landlord might run a credit 
check before renting an apartment. A software vendor might check with Dun & 
Bradstreet or some other firm to verify creditworthiness. And vice versa.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to