License keys for ISV products(What alternatives are there?)

[David Day]

The current discussion on license keys prompts this. If an ISV doesn't use a key tied to a date and a machine serial number, what other mechanism is there to insure there are no pilfered copies of the ISV's product running somewhere, and the ISV doesn't have a clue? From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal? I'm not asking this last question sarcastically, I'd like to know if there are issues with this that I'm not taking into account.

--Dave

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>If an ISV doesn't use a key tied to a date and a machine serial number, what other mechanism is there to insure there are no pilfered copies of the ISV's product running somewhere, and the ISV doesn't have a clue?

There is the 'trust' model, which IBM uses.


>From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal?

1. That's a big IF.
2. In a 7/24 multi-time zone environment, getting the capability to stop all users of a product long enough to apply the keys is problematic.
3. You don't always know until the last minute (usually on a weekend), and some companies (PKWARE, for example), only work M-F/9-5.
4. If you're out-sourced, you sometimes have the service provider:
a. Waiting until after they expire to tell you.
b. Slow in applying them.
c. Making mistakes and applying another customer's keys.

The key point is it complicates an already complex environment!
I can see a use for evaluation keys, but once the contract is signed, give me a permanent key, and use the 'trust' model.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Feb 17, 2007, at 7:58 AM, Ted MacNEIL wrote:
----SNIP------------------
>
>
>> From a user's perspective, if the ISV is timely in his delivery of
>> license keys, why is it a big deal?
>
> 1. That's a big IF.
> 2. In a 7/24 multi-time zone environment, getting the capability to
> stop all users of a product long enough to apply the keys is
> problematic.
> 3. You don't always know until the last minute (usually on a
> weekend), and some companies (PKWARE, for example), only work M-F/9-5.
> 4. If you're out-sourced, you sometimes have the service provider:
> a. Waiting until after they expire to tell you.
> b. Slow in applying them.
> c. Making mistakes and applying another customer's keys.
>
> The key point is it complicates an already complex environment!
> I can see a use for evaluation keys, but once the contract is
> signed, give me a permanent key, and use the 'trust' model.
>
--SNIP-------------

Ted,

You are right on the money. We ran into the PKWARE issue 7-9 years
ago. *NOT* a company to do business with, IMO. Keep the issue simple
and fool proof that is a simple request, no?

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>The key point is it complicates an already complex environment!
>I can see a use for evaluation keys, but once the contract is signed, give
>me a permanent key, and use the 'trust' model.

I have about 15 keys on my keychain. I can never find the right one; it
certainly complicates my environment. If I stopped locking my doors, I could
throw away all my keys and just use the trust model. :-)

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Free Alerts : Be smart - let your information find you !
http://alerts.live.com/Alerts/Default.aspx

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Finnell]

In a message dated 2/17/2007 7:53:26 A.M. Central Standard Time,
***@YAHOO.CA writes:

The key point is it complicates an already complex environment!
I can see a use for evaluation keys, but once the contract is signed, give
me a permanent key, and use the


>>
It's a value assessment based on risk and functionality. Back in the olden
days GRS just couldn't cut it in a JES3 environment especially. So we found
MXI(now MIM) from Allen Systems. It was great in many respects. Down side was
without electronic delivery or notification the contract office would get the
updates a couple weeks in advance then it would trickle down to those who
needed to apply them. The really perverse nature is that it would run past the
end of expiration until it hit somebody's birthday-usually one of Medici's.
Vlad the Impaler, Lizzie Borden also in the mix.

As Bruno suggests it can be a motivator/incentive for software cleanup and
review that probably should have been done months ago. That's our job. The
ISV's want to protect intellectual property and trade secrets. That's there job.
It complicates upgrades and DR but it's all doable with planning. My favorite
vendor mechanism is IBI's. Keys required but they give a thirty day
grace period for DR so usually can get in and get out before really have to
do anything.

The silver bullet would be a magic decoder ring on the HMC that says this
can run and this can't. Doubt we'll see that anytime soon.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Chase, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Ed Finnell
>
> [ snip ]
>
> The silver bullet would be a magic decoder ring on the HMC
> that says this
> can run and this can't. Doubt we'll see that anytime soon.

IFAPRDxx ?

-jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Eric N. Bielefeld]

IFAPRDxx really isn't a key. You have to turn it on for each product to use
it, but there is no key that only works on your CPU. I'm not sure just what
IBM's reasoning behind IFAPRD is, but the only way IBM could limit your use
of different software products using IFAPRD would be if IBM was present
during your IPLs and monitored IFAPRD's contents just after the IPL.

This has been a very interesting discussion. A few of the vendors have
givin very good reasons for having keys. This comes at a time when I was
givin the task to renew our Syncsort keys. I found that negotiating the
contract was part of the process, which is something I won't have to do,
fortuneatly for me. When they get the contract process done, I'll just have
to install the keys. By the way, does anyone know if Syncsort's key is a
hard fail key? I suspect it is after a grace period.

I think its interesting that so many sysprogs on the list hate keys so much.
I think a lot of it is just poor business practices when you can't get a key
in time. Yes, there are a few vendors who are only available 9-5 M-F, which
could be a problem in a real disaster, but most of the major ones can
respond 24 by 7.

Eric Bielefeld
Sr. z/OS Systems Programmer
Lands End
Dodgeville, Wisconsin
414-475-7434

----- Original Message -----
From: "Chase, John" <***@USSCO.COM>
Subject: Re: License keys for ISV products(What alternatives are there?)


>> -----Original Message-----
.
>
> IFAPRDxx ?
>
> -jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

--------------------------<snip>--------------------------
IFAPRDxx really isn't a key. You have to turn it on for each product to
use it, but there is no key that only works on your CPU. I'm not sure
just what IBM's reasoning behind IFAPRD is, but the only way IBM could
limit your use of different software products using IFAPRD would be if
IBM was present during your IPLs and monitored IFAPRD's contents just
after the IPL.
------------------------<unsnip>--------------------------
But why couldn't IFAPRDxx contain a vendor's key in one of the supported
fields, instead of a "english description" of the software, for example?
The key could be maintained "on the fly" (checked daily by the vendor
package until expiration; then checked at each invocation) and all the
keys would be in one simple, central repository. And why can't vendor
code provide timely expiration warnings? And reasonable "grace periods"
after expiration or for DR purposes? Comments were that the accounting
department might be a little slow in reacting to a required renewal.
Give them their due; they're trying to be protective of company assets,
too. And some organizations, like my last one, require that the Legal
department ALSO review anything and everything. So Accounting may be
willing to cut the check, but Legal may be "resting on its laurels" and
delaying the process.

Vendors have an obligation to their shareholders to protect their
intellectual property, and try to limit liability in case of abuses; I
can accept that. But let's face it, some vendors' pricing practices are
downright PREDATORY. First they hook you into using their products,
then impose unconscionable price increases after the so-called
"introductory period". In my personnal experience, one vendor sent 9
marketting reps to my office, when all I had requested was a copy of the
proposed contract, which could have been FAXed to me! Bloated marketting
staff with nothing to do; I'm sure other areas of staff are similarly
bloated; all these things contribute to high prices and loss of
fexibility. Compuware built a nice shiny new headquarters building in
downtown Detroit, then promptly laid off 5,000 people to "cut costs".

Too many "pencil pushers" and not enough technicians!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Jeffrey D. Smith]

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
> Behalf Of Rick Fochtman
> Sent: Sunday, February 18, 2007 11:20 AM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: License keys for ISV products(What alternatives are there?)
>
/snip/
> Vendors have an obligation to their shareholders to protect their
> intellectual property, and try to limit liability in case of abuses; I
> can accept that. But let's face it, some vendors' pricing practices are
> downright PREDATORY. First they hook you into using their products,
> then impose unconscionable price increases after the so-called
> "introductory period". In my personnal experience, one vendor sent 9
> marketting reps to my office, when all I had requested was a copy of the
> proposed contract, which could have been FAXed to me! Bloated marketting
> staff with nothing to do; I'm sure other areas of staff are similarly
> bloated; all these things contribute to high prices and loss of
> fexibility. Compuware built a nice shiny new headquarters building in
> downtown Detroit, then promptly laid off 5,000 people to "cut costs".
>
> Too many "pencil pushers" and not enough technicians!

Now you're starting a different subthread. Keys to protect intellectual
property have not much correlation with the pricing model. Usage-based
pricing model is for "leased software", not "purchased software" (like
M$ Excel).

There is a huge difference between leased versus purchased software
licensing models.

Purchase software, like M$ Excel, generally have limitations on upgrades,
operating system, and support life (bug fixes). You pay once, and get
bug fixes on a somewhat timely basis until end of support. Installing
the software "phones home" and identifies itself to be sure that the
particular serial-numbered software is not already installed elsewhere.
This is a reasonable way to protect against piracy, but it may be a
problem for some mainframe sites that want to be isolated from the
outside world.

Leased software, like much of the mainframe software out there, has
some kind usage-based pricing that hopes to correlate the cost of the
software to the benefit received. The customer receives bug fixes,
new versions, and support for newer operating systems. If the customer
does not perceive the benefit as being greater than the cost, then
the customer stops paying and the product stops operating. Most CFO's
use the concept of a "hurdle rate" that specifies the rate of return
on any investment. The benefit must exceed a certain multiplier applied
to the cost of the investment.

Usage-based pricing has many challenges. Is it per user, machine capacity,
or per transaction (i.e., "metered usage"). If it is metered usage, how
is the usage measured and reported (e.g, intrusiveness and accuracy are
primary concerns). If it is machine capacity, how to accommodate periods
of low activity versus high activity (end of quarter and end of year
processing)? If it is per user, how quickly can the ISV accommodate
changes in user quota?

The notion of using dongles (a hardware device with a programmatically
accessible serial number) is one way to assure that the software is
running on the correct machine. The mainframe CPU serial number serves
the same purpose. The MAC address for a network card also serves the
same purpose, but is harder to verify programmatically on a mainframe.

All of the concerns and issues mentioned above must somehow be
distilled into a license key implementation that does not add
unnecessarily to the sysprog burden.

I understand that customers don’t want to become dependent on
leased software that expires and shuts down during critical times.
However, there must be some reasonable cut-off point when negotiations
break-down at contract renewal time. If the customer and vendor cannot
agree on a new contract, then the product must stop operating. Where
will you draw the line; 30 days, 60 days, 180 days, more? How long will
customer get a free ride on a mission-critical ISV software? Until a
replacement can be found or built? Does the contract allow for defaulting
to month-to-month fees until a new long-term contract is negotiated (or
the customer has gotten past their critical end-of-quarter processing)?
What if there are no acceptable replacement products and the customer
is unable or unwilling to build their own replacement? Disaster recovery
on unknown machines (why are they unknown?) is a big issue.

Many license key implementations are awkward and difficult to manage.
Complain to the ISV and be specific about the issues. Pricing models
are entirely a different matter that have little correlation to the
license key implementation. Let's be clear in this topic when discussing
pricing models versus license key implementation. License keys are never
going away. However, bad implementations should go away.


Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark Morris]

On 18 Feb 2007 11:44:17 -0800, in bit.listserv.ibm-main you wrote:

>> much snipped
>
>I understand that customers don’t want to become dependent on
>leased software that expires and shuts down during critical times.
>However, there must be some reasonable cut-off point when negotiations
>break-down at contract renewal time. If the customer and vendor cannot
>agree on a new contract, then the product must stop operating. Where
>will you draw the line; 30 days, 60 days, 180 days, more? How long will
>customer get a free ride on a mission-critical ISV software? Until a
>replacement can be found or built? Does the contract allow for defaulting
>to month-to-month fees until a new long-term contract is negotiated (or
>the customer has gotten past their critical end-of-quarter processing)?
>What if there are no acceptable replacement products and the customer
>is unable or unwilling to build their own replacement? Disaster recovery
>on unknown machines (why are they unknown?) is a big issue.

When a disaster is declared, the specific target system may in part
depend on how many other sites have declared a disaster at the same
time. I would not want to depend on getting a specific physical box
in many cases. Of course if the DR system is owned by the site
declaring the disaster, the serial number should be known.
>
>Many license key implementations are awkward and difficult to manage.
>Complain to the ISV and be specific about the issues. Pricing models
>are entirely a different matter that have little correlation to the
>license key implementation. Let's be clear in this topic when discussing
>pricing models versus license key implementation. License keys are never
>going away. However, bad implementations should go away.
>
>
>Jeffrey D. Smith
>Principal Product Architect
>Farsight Systems Corporation
>700 KEN PRATT BLVD. #204-159
>LONGMONT, CO 80501-6452
>303-774-9381 direct
>303-484-6170 FAX
>http://www.farsight-systems.com/
>see my résumé at my website (yes, I am looking for employment)
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <000c01c7536c$bfc105a0$***@ericapm9hpwqxr>, on 02/18/2007
at 08:54 AM, "Eric N. Bielefeld" <eric-***@CHARTER.NET> said:

>IFAPRDxx really isn't a key. You have to turn it on for each product
>to use it, but there is no key that only works on your CPU. I'm not
>sure just what IBM's reasoning behind IFAPRD is,

Presumably protection from inadvertent license violation.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Binyamin Dissen]

On Mon, 19 Feb 2007 13:33:26 -0500 "Shmuel Metz (Seymour J.)"
<shmuel+ibm-***@PATRIOT.NET> wrote:

:>In <000c01c7536c$bfc105a0$***@ericapm9hpwqxr>, on 02/18/2007
:> at 08:54 AM, "Eric N. Bielefeld" <eric-***@CHARTER.NET> said:

:>>IFAPRDxx really isn't a key. You have to turn it on for each product
:>>to use it, but there is no key that only works on your CPU. I'm not
:>>sure just what IBM's reasoning behind IFAPRD is,

:>Presumably protection from inadvertent license violation.

Does IBM custom build the IFAPRD** for each customer?

Or are most products turned off, requiring the customer to activate those that
were licensed?

Or, perhaps, all are on and the customer has to deactivate them?

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[John Eells]

See below...

Binyamin Dissen wrote:

> Does IBM custom build the IFAPRD** for each customer?

Yes. Every z/OS ServerPac or CBPDO order includes a custom-built
IFAPRDxx member.

> Or are most products turned off, requiring the customer to activate those that
> were licensed?

So far as I know, only z/OS elements use IFAPRDxx at this time.
(Other things potentially could but I am not currently aware of
any that do, or I've forgotten.) All licensed z/OS elements
should be turned on, and all unlicensed ones turned off.

> Or, perhaps, all are on and the customer has to deactivate them?

If you activate another z/OS element, you should contact IBM
beforehand. If you deactivate one, we don't mind so much if you
drag your feet or forget. ;-)

<snip>

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Neal Eckhardt]

On 19 Feb 2007 12:57:49 -0800, ***@ibm-main.lst (John Eells) wrote:

>See below...
>
>Binyamin Dissen wrote:
>
>> Does IBM custom build the IFAPRD** for each customer?
>
>Yes. Every z/OS ServerPac or CBPDO order includes a custom-built
>IFAPRDxx member.
>
>> Or are most products turned off, requiring the customer to activate those that
>> were licensed?
>
>So far as I know, only z/OS elements use IFAPRDxx at this time.
>(Other things potentially could but I am not currently aware of
>any that do, or I've forgotten.) All licensed z/OS elements
>should be turned on, and all unlicensed ones turned off.
>
>> Or, perhaps, all are on and the customer has to deactivate them?
>
>If you activate another z/OS element, you should contact IBM
>beforehand. If you deactivate one, we don't mind so much if you
>drag your feet or forget. ;-)
>

Of course the theory is that IBM can simplify it's system builds by
shipping most of the commonly used products to everybody, and disable
the ones that you did not pay for. When you decide you want something
new (like we did with DFSort last year) just enable it in IFAPRDxx
and it is ready to go. No install required. It was already there.

It sure made life a lot easier.

Now of course, this is an honor system. There is nothing to prevent
you from enableing say SDSF if you use a competing product.

Neal

[Joel C. Ewing]

Since probably the most important function of a System Programmer is to
provide a stable Operating System platform for production applications
(typically requiring a number of ISV products), and to do this while
juggling software release changes, software maintenance, and changes in
hardware, it is not surprising that system programmers (and enlightened
managers) would be irked at anything that makes that task more
difficult, and especially at any product whose license key management
introduces additional points of failure into the process.

If a hard failure occurs in a critical ISV product because of a bad
license key, this potentially affects many application, large numbers of
end users, and costs the company real money. It makes no difference
whether the outage is caused by an ISV failure to supply correct keys or
by some error on our part in the installation process, the effect on the
end user is equally bad.

Particularly in the case of processor upgrades, or in DR, there is no
reliable way for us to verify that new keys from the vendors are correct
and correctly installed until we are running on the new processor. If
they aren't and a hard failure results, there is a high likelihood that
this failure will be seen in some way by the end users, even if the
vendor key support is 24x7.

While I can understand the vendors concerns, my goal is to focus on our
own system reliability and the needs of our end users; and any hard
failures in ISV products are an enemy of that goal.

Eric N. Bielefeld wrote:
...
> I think its interesting that so many sysprogs on the list hate keys so
> much. I think a lot of it is just poor business practices when you can't
> get a key in time. Yes, there are a few vendors who are only available
> 9-5 M-F, which could be a problem in a real disaster, but most of the
> major ones can respond 24 by 7.
>
> Eric Bielefeld
> Sr. z/OS Systems Programmer
> Lands End
> Dodgeville, Wisconsin
> 414-475-7434
...

--
Joel C. Ewing, Fort Smith, AR ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Binyamin Dissen]

On Sat, 24 Feb 2007 20:25:24 -0600 "Joel C. Ewing" <***@ACM.ORG> wrote:

:>Particularly in the case of processor upgrades, or in DR, there is no
:>reliable way for us to verify that new keys from the vendors are correct
:>and correctly installed until we are running on the new processor. If
:>they aren't and a hard failure results, there is a high likelihood that
:>this failure will be seen in some way by the end users, even if the
:>vendor key support is 24x7.

In the case of a processor upgrade: if you get a hard error during production
due to a bad ISV key, your testing criteria are way too lax.

In the case of DR: if you do test runs, you will be quite aware of this issue.
If you never do test runs, refer to the "processor upgrade" above. If you do
not test, this is not likely to be your only problem. Or a major one.

:>While I can understand the vendors concerns, my goal is to focus on our
:>own system reliability and the needs of our end users; and any hard
:>failures in ISV products are an enemy of that goal.

First, work on what you can change - get your accounting people up to speed.
Keep track of the ISV products and expirations, and follow up on them.

Improve those test procedures.

Am I a little harsh? Perhaps.

Yes, you would like to not have to worry about the ISV key, and the ISV would
love not having to worry about collecting.

But you should be aware that there is a bit of a partnership here.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Shane]

> Am I a little harsh? Perhaps.

Sounds suspiciously like platitude to me.
Being patronising to customers with broken systems is rarely
appreciated. Vendors with visions of forward sales would do well to be
cognisant of this.

Shane ...

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Binyamin Dissen]

On Sun, 25 Feb 2007 19:20:29 +1000 Shane <ibm-***@TPG.COM.AU> wrote:

:>> Am I a little harsh? Perhaps.

:>Sounds suspiciously like platitude to me.

No.

:>Being patronising to customers with broken systems is rarely
:>appreciated.

Nobody is suggesting that.

:> Vendors with visions of forward sales would do well to be
:>cognisant of this.

Would be great if all invoices were paid on time.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <***@aol.com>, on 02/17/2007
at 11:41 AM, Ed Finnell <***@AOL.COM> said:

>The silver bullet would be a magic decoder ring on the HMC that says
>this can run and this can't.

That doesn't solve the problem for either the customer or the vendor.
Consider DR.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>It complicates upgrades and DR but it's all doable with planning.

Planning isn't enough!
You also need execution.
We don't get much of that from our service provider and a couple of (nameless) vendors.

We end up long on planning; short on execution.


-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Finnell]

In a message dated 2/17/2007 10:57:26 A.M. Central Standard Time,
***@YAHOO.CA writes:

We don't get much of that from our service provider and a couple of
(nameless) vendors.




>>
Sounds like a management opportunity. Change the Service provider or replace
the vendors. Then you can do do do 'til the next planning cycle!

_http://www.dilbert.com/comics/dilbert/archive/dilbert-20070216.html_
(http://www.dilbert.com/comics/dilbert/archive/dilbert-20070216.html)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Sounds like a management opportunity. Change the Service provider or replace the vendors.

Love to.
Vendors are niche products.
Service provider has a few years to go on the contract, with penalties.

But, that wasn't my point.

IBM works with a 'trust' model.
Why can't the rest?
Planning is good.
Simplification is better!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Finnell]

In a message dated 2/17/2007 11:30:57 A.M. Central Standard Time,
***@YAHOO.CA writes:

IBM works with a 'trust' model.
Why can't the rest?



>>
License agreements, hardware, they pretty much got you by the ventricles.
The rest have to provide a service that is better or unique to their area of
expertise. It's a cold cruel world. Cottage industries copying everything from
CD's to Nuclear weapons spring up daily and with the big-I distribution is
only a click away. Sometimes state supported...

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>License agreements, hardware, they pretty much got you by the ventricles.

I tend to believe any professional and respected company will not screw their reputation.

If the do, do you want to deal with them?

By the way, ventricles are part of the heart.
I assume you meant a slightly lower set of body parts?

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>From: David Day <***@ibm-main.lst>
>If an ISV doesn't use a key tied to a date and a machine serial number,
>what other mechanism is there to insure there are no pilfered copies of the
>ISV's product running somewhere, and the ISV doesn't have a clue? From a
>user's perspective, if the ISV is timely in his delivery of license keys,
>why is it a big deal?

I don't see it as being a big deal either. When a customer licenses a
product, they are given a key. A year later (or shortly before the license
expires), the customer receives an invoice. If they pay the invoice, they
get a new key. The customer replaces the old key with the new key (e.g.
enters it in a flat file or ISPF table or whatever). Nothing needs to be to
compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to
enter the new key, and the customer is good to go for another year (or
whatever the renewal term is). How is that a big deal?

The only issue I can see is what happens when an unscheduled change of a
CPUID occurs, such as might occur in a disaster situation. If the software
is "mission critical" (i.e. needs to be up and running the very minute the
switchover to the new CPUID occurs), it should already be licensed to run at
the disaster site. Or, the software can display a message such as "This
product isn't licensed to run on this CPUID", but will still run anyway
(perhaps with limited functionality). This gives the customer time to
acquire a new key, and everyone is happy.

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Buy what you want when you want it on Sympatico / MSN Shopping
http://shopping.sympatico.msn.ca/content/shp/?ctId=2,ptnrid=176,ptnrdata=081805

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Joel C. Ewing]

Judging from the number of responses to this thread, there are obviously
many who do think keys are a big deal. It's a big deal because a
processor upgrade that takes less than 5 minutes of a System
Programmer's time to deal with the hardware and Operating System
aspects, requires hours to deal with keys from multiple vendors, each
with their own unique methods of acquiring and installing keys, and
requires weeks or even months of follow-up until all issues from the
last vendor are finally resolved. In the event of a real DR, in the
initial days there will be enough serious problems to deal with without
having immediate resolution of vendor keys be one of them - especially
true for any vendor not equipped to supply keys in a matter of minutes,
24x7. For DR testing, we consider proof of the ability to get must-have
keys from vendors in a timely fashion as part of the DR exercise.

In our experience, the vendors concept of "timely" key delivery too
often falls short of user needs. With the advent of dynamic CPU
upgrades, the turn-around for CPU upgrades is now so quick that almost
all such upgrades are "unscheduled" when compared to the turn-around for
contract negotiations with vendors to support the new CPU. Our CE can
"install" the new CPU in a few minutes; we may have to negotiate for
months with vendors, even those we have even done business with for
decades, before getting a new contract that we consider to have adequate
safeguards for us and which is satisfactory to lawyers and bean-counters
on both sides. In the mean time we may have to install temporary key
after temporary key for months on end, and even after a contract is
signed it may still be another month until we can finally get someone to
turn loose with a "permanent" key - about time to start the whole
process over again!

Someone made mention of CA's web site for LMP keys. Last time I
checked, 6 months after our last upgrade, it still only had the keys for
our old CPU. Most of CA's keys, thank goodness, are fail soft, but not
all. CA-Platinum DB2 utilities failed ungracefully without an EKG key
at our last DR test. CA is not the only vendor that has trouble keeping
all their databases correct on our current CPU - we received a "new" key
just last week from another vendor for a CPU serial that was 8 months
obsolete (yes they had been notified, and had previously sent us a good
key for the current CPU).

If vendors feel they have to implement key checking, then as a user I
would prefer they all be failsafe (nags). If the vendor insists on
implementing a hard failure, then there must be a grace period that at a
very minimum should be much longer than the time period for contract
re-negotiation. Rubber-stamping of a vendor-offered contract (seldom
advantageous to the user) is not an option for us, and I suspect we are
not alone. That grace period should automatically be restored when the
product runs on valid keys, without any manual resetting required
(ZEKE/ZEBB take note), so that the full grace period is assured to be in
place if, heaven forbid, one has to deal with a DR for real.

Vendors that can't meet these minimal requirements encourage us to look
for alternative products.


Dave Salt wrote:
>> From: David Day <***@ibm-main.lst>
>> If an ISV doesn't use a key tied to a date and a machine serial
>> number, what other mechanism is there to insure there are no pilfered
>> copies of the ISV's product running somewhere, and the ISV doesn't
>> have a clue? From a user's perspective, if the ISV is timely in his
>> delivery of license keys, why is it a big deal?
>
> I don't see it as being a big deal either. When a customer licenses a
> product, they are given a key. A year later (or shortly before the
> license expires), the customer receives an invoice. If they pay the
> invoice, they get a new key. The customer replaces the old key with the
> new key (e.g. enters it in a flat file or ISPF table or whatever).
> Nothing needs to be to compiled/linked/refreshed/IPL'd (etc). It just
> takes a couple of minutes to enter the new key, and the customer is good
> to go for another year (or whatever the renewal term is). How is that a
> big deal?
>
> The only issue I can see is what happens when an unscheduled change of a
> CPUID occurs, such as might occur in a disaster situation. If the
> software is "mission critical" (i.e. needs to be up and running the very
> minute the switchover to the new CPUID occurs), it should already be
> licensed to run at the disaster site. Or, the software can display a
> message such as "This product isn't licensed to run on this CPUID", but
> will still run anyway (perhaps with limited functionality). This gives
> the customer time to acquire a new key, and everyone is happy.
>
> Dave Salt
> SimpList(tm) - The easiest, most powerful way to surf a mainframe!
> http://www.mackinney.com/products/SIM/simplist.htm
...


--
Joel C. Ewing, Fort Smith, AR ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>I don't see it as being a big deal either. When a customer licenses a product, they are given a key. A year later (or shortly before the license
expires), the customer receives an invoice. If they pay the invoice, they
get a new key.

Really? Most of the time the customer has to discover the key is expired!

>The customer replaces the old key with the new key (e.g. enters it in a flat file or ISPF table or whatever). Nothing needs to be to compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to enter the new key, and the customer is good to go for another year

WRONGO! We have to compile/linked/refresh all of our keys!


-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

> >I don't see it as being a big deal either. When a customer licenses a
>product, they are given a key. A year later (or shortly before the license
>expires), the customer receives an invoice. If they pay the invoice, they
>get a new key.
>
>Really? Most of the time the customer has to discover the key is expired!

Even if you're not sent a new key ahead of time, the product should start
warning you before the key expires. If you're encountering situations where
you're not being sent a new key ahead of time and the product isn't warning
you a key is about to expire, something is seriously wrong.

> >The customer replaces the old key with the new key (e.g. enters it in a
>flat file or ISPF table or whatever). Nothing needs to be to
>compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to
>enter the new key, and the customer is good to go for another year
>
>WRONGO! We have to compile/linked/refresh all of our keys!

Not all products are like that. Maybe then the issue isn't so much that keys
are required, but the way they're sometimes implemented by the vendor? If
keys were always received well before the old ones expired, and all you had
to do was enter them in a flat file, would that be a big deal?

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Your Space. Your Friends. Your Stories. Share your world with Windows Live
Spaces. http://spaces.live.com/?mkt=en-ca

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Charles Mills]

I'm often the voice of dissent here. Let me throw out a few
counter-thoughts.

Bruno Sugliani wrote "we don't care (sorry about that) about the sharks
robbing the poor salesmen" and he's right, of course. It's not your (the
customers') problem if our (the vendors') salespeople have difficulties
doing their jobs. But there's a bar in San Francisco with a sign that says
"we cheat the other guy and pass the savings on to you." The converse is
also true. Every dollar that a software company fails to collect is a dollar
less that is available to fund enhancements, support staff, new hardware,
and yes, the profits that attract investment in a capitalist economy. To
some extent, you suffer from the software company's problems.

I basically did and do trust the customers. My theory was that few customers
would base a mission-critical process on stolen software, and few would pay
5-digit prices for software that was not for a mission-critical process, so
license keys at best prevented people from running copies of our software
that they would not have paid for anyway, such as a programmer who loved our
product so much that he took a copy with him for personal use when he
changed jobs. Such thefts may have impacted our pride, but not our bottom
line.

As I said in an earlier post, I put the keys in primarily to control trials,
not licensed customers. However, trust or not, several customers
subsequently came out of the woodwork with "we didn't know that group was
running your software on that box." I believed them, but I still cashed
their checks and used the money to help fund our company. Contrary to what
some of you may think, a small software company is not a license to print
money. We struggled many months, and came very close twice to shutting our
doors.

Another factor in license keys that many of you may not have considered:
distributors. Most small software companies sell overseas through
distributors. It is my impression that for some reason, the business of
distributing foreign software attracts a disproportionate number of outright
thieves. The software publisher needs keys to control the activities of the
distributor, who otherwise can sell software (to unsuspecting and
trustworthy customers) and pocket all of the money. We shared a British
distributor with a small software company whose name you would recognize in
a heartbeat, and that I think has a reputation with most of you as "nice
guys." We jointly discovered that our common distributor had stolen tens of
thousands of dollars from us (by selling and pocketing the revenue from
feature upgrades that were not protected by our key technology) and hundreds
and hundreds of thousands of dollars from this other company, which could
ill afford the loss. (It was not because their software was not protected by
keys, but rather because they had given him the key generator, that this was
possible, but the principle is the same.)

Was it Ronald Reagan who said "trust, but verify"? Hasn't even IBM gone to
less and less of a "trust" model? Are not the restrictions on z/OS.e, for
example, enforced by technology that is somewhat analogous to keys?

I would love to see a common, universally-accepted system that was easy to
use and presented little burden to all concerned. IBM sort-of tried with
their license manager. Even if a more technologically acceptable system were
to be developed, it would also face anti-trust hurdles, because the US
Department of Justice looks very unfavorably on any vendor collusion with
regards to terms of doing business. (That's one reason there is no single
common software license form that multiple companies all use -- wouldn't
THAT make life easier?) Until something better comes along, I think keys,
administered in an intelligent and customer-friendly manner, are the best
solution to a problem with no really good answers.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Of David Day
Sent: Saturday, February 17, 2007 5:27 AM
To: IBM-***@BAMA.UA.EDU
Subject: License keys for ISV products(What alternatives are there?)

The current discussion on license keys prompts this. If an ISV doesn't use
a key tied to a date and a machine serial number, what other mechanism is
there to insure there are no pilfered copies of the ISV's product running
somewhere, and the ISV doesn't have a clue? From a user's perspective, if l

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Charles Mills wrote:
[...]
> Was it Ronald Reagan who said "trust, but verify"? Hasn't even IBM gone to
> less and less of a "trust" model? Are not the restrictions on z/OS.e, for
> example, enforced by technology that is somewhat analogous to keys?

Lenin was first with that (dowieriaj no prowieriaj). AFAIR Lenin wasn't capitalist.

Software companies must have their incomes and profits, no doubt. It is discussed about the way their enforce it. Sometimes the way is very inconvenient to customer. IBM is big exception in the picture.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <009b01c752c3$28c15e10$***@Charles2006>, on 02/17/2007
at 10:40 AM, Charles Mills <***@MCN.ORG> said:

>We jointly discovered that our common distributor had stolen tens of
>thousands of dollars from us

>Was it Ronald Reagan who said "trust, but verify"?

He quoted an old Russian saying.

>Even if a more technologically acceptable system were
>to be developed, it would also face anti-trust hurdles, because the
>US Department of Justice looks very unfavorably on any vendor
>collusion with regards to terms of doing business.

Would that that were true. The DOJ basically let m$ off the hook and
has turned a blind eye on noncompliance.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>If I stopped locking my doors, I could throw away all my keys and just use the trust model

Bad analogy! The trust model is regarding software. NOT personal safety/security.

There is a difference between a home invasion and accessing software.

I work for a company that would not screw the vendor.
I have been in the field for a few years!

The company should be trusted.
Would I screw my reputation because I want 'free' software?

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>From: Ted MacNEIL <***@ibm-main.lst>
>I work for a company that would not screw the vendor.
>The company should be trusted.
>Would I screw my reputation because I want 'free' software?

I believe you wouldn't steal software, but I'm not so sure about the person
who sits next to you or the guy in Timbuktu.

My neighbour wouldn't screw me over. Despite this, I still lock my doors
every time I leave the house.

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Find what you need at prices you’ll love. Compare products and save at MSN®
Shopping.
http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[E***@ibm-main.lst]

In a message dated 2/17/2007 12:21:36 P.M. Central Standard Time,
***@YAHOO.CA writes:

If the do, do you want to deal with them?



>>
Yep and do. Can live without lower parts, chose ventricles on purpose to
simulate heart beat.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Not all products are like that. Maybe then the issue isn't so much that keys are required, but the way they're sometimes implemented by the vendor?

Sometimes? -- all the time. No vendor, that we use, has made keys easy to use!


>If keys were always received well before the old ones expired, and all you had to do was enter them in a flat file, would that be a big deal?

Hasn't happened yet!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

At 2/17/2007 02:55 PM, TMacNeil wrote:
> >Not all products are like that. Maybe then the issue isn't so much
> that keys are required, but the way they're sometimes implemented
> by the vendor?
>
>Sometimes? -- all the time. No vendor, that we use, has made keys easy to use!

Maybe "all the time" for you. Clearly not all the time for everybody.

As I implied in my prior post, maybe you need to lobby your vendor to
improve the usability of its licensing management.






> >If keys were always received well before the old ones expired, and
> all you had to do was enter them in a flat file, would that be a big deal?
>
>Hasn't happened yet!

You can't change vendors?

Then is there a user's group for your vendor's customers?

If not, do you want to start one?

If these issues matter so much to you, then put energy into
organizing pressure to get your vendors to improve their code.

One way to start with the pressure is to stop being vague, stop with
the unfocused aspersions, and start naming names.






>Too busy driving to stop for gas!

If you're too busy to do what you need to do, then maybe it's not all
that important to you after all.

Maybe instead you could put your own reminder into your own calendar
program to warn yourself enough ahead of time to get the relicensing
ball rolling within your own company. (Now there's a startling thought...)




Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Charles Mills]

Perhaps the problem is with the speed of your accounts payable department?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Of David Cole
Sent: Saturday, February 17, 2007 12:51 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

> >If keys were always received well before the old ones expired, and
> all you had to do was enter them in a flat file, would that be a big deal?
>
>Hasn't happened yet!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Charles Mills]

Do keep in mind that if mainframe software maintenance were labor-free, most
of the members of this list would not have jobs! <g>

If anyone has a better scheme, I'm all ears. IBM-MAIN members, design a
software control system for me. How would it work?

My needs are
- Expiration date
- Serial number check
- Feature control (that is, it is not all or nothing -- you can be licensed
for the product but not for optional feature X)
- Relatively difficult to hack (nothing is impossible, of course)

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Of Ted MacNEIL
Sent: Saturday, February 17, 2007 11:55 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

>Not all products are like that. Maybe then the issue isn't so much that
keys are required, but the way they're sometimes implemented by the vendor?

Sometimes? -- all the time. No vendor, that we use, has made keys easy to
use!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Feb 17, 2007, at 1:55 PM, Ted MacNEIL wrote:

>> Not all products are like that. Maybe then the issue isn't so much
>> that keys are required, but the way they're sometimes implemented
>> by the vendor?
>
> Sometimes? -- all the time. No vendor, that we use, has made keys
> easy to use!
>
>
>> If keys were always received well before the old ones expired, and
>> all you had to do was enter them in a flat file, would that be a
>> big deal?
------------SNIP------------------

This is a more of a what if issue but I have seen it happen in the
real world.

I have seen a system "frozen" no updates allowed for *any* reason.
The license expires (my memory says it was a CA product but its
immaterial) what does one do?

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Jeffrey D. Smith]

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
> Behalf Of Ed Gould
> Sent: Saturday, February 17, 2007 8:03 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: License keys for ISV products(What alternatives are there?)
>
> On Feb 17, 2007, at 1:55 PM, Ted MacNEIL wrote:
>
> >> Not all products are like that. Maybe then the issue isn't so much
> >> that keys are required, but the way they're sometimes implemented
> >> by the vendor?
> >
> > Sometimes? -- all the time. No vendor, that we use, has made keys
> > easy to use!
> >
> >
> >> If keys were always received well before the old ones expired, and
> >> all you had to do was enter them in a flat file, would that be a
> >> big deal?
> ------------SNIP------------------
>
> This is a more of a what if issue but I have seen it happen in the
> real world.
>
> I have seen a system "frozen" no updates allowed for *any* reason.
> The license expires (my memory says it was a CA product but its
> immaterial) what does one do?
>
> Ed

Couple of ideas pop:

1. Reclassify "license refresh" as a non-update.

2. Connect the production system to the outside world and let the
ISV product talk to the ISV website server thing to verify license
and dynamically update the license (e.g., "call home").

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Feb 17, 2007, at 9:53 PM, Jeffrey D. Smith wrote:
---------------
SNIP-------------------------------------------------------

>
> Couple of ideas pop:
>
> 1. Reclassify "license refresh" as a non-update.
Well in the real world where I was this is what happened. But the
people demanding a stable system system went ballistic. They really
raised holy H*LL about this (sorry darrin) I can't say I wasn't
unsympathetic to them. We should have threatened to turn loose the ca-
rep on them though. They would not have forgiven us for that but it
would have gotten the point across.
>
> 2. Connect the production system to the outside world and let the
> ISV product talk to the ISV website server thing to verify license
> and dynamically update the license (e.g., "call home").

I have never seen this in real life does it really happen?

Ed

>
> Jeffrey D. Smith
> Principal Product Architect
> Farsight Systems Corporation
> 700 KEN PRATT BLVD. #204-159
> LONGMONT, CO 80501-6452
> 303-774-9381 direct
> 303-484-6170 FAX
> http://www.farsight-systems.com/
> see my résumé at my website (yes, I am looking for employment)
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>From: Ted MacNEIL <***@ibm-main.lst>
>No vendor, that we use, has made keys easy to use!

If that's the case, I understand your frustration.

There are products that don't require jumping through hoops to enter a key,
and if you ever use one then maybe you'll feel differently about them. And
maybe you could then go back to the other vendors and say "why aren't your
keys as easy to use as this?".

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Your Space. Your Friends. Your Stories. Share your world with Windows Live
Spaces. http://spaces.live.com/?mkt=en-ca

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Shane]

On Sat, 2007-02-17 at 20:45 +0000, Dave Salt wrote:

> There are products that don't require jumping through hoops to enter a key,
> and if you ever use one then maybe you'll feel differently about them. And
> maybe you could then go back to the other vendors and say "why aren't your
> keys as easy to use as this?".

I can understand vendors wanting to protect their IP, and generate all
the legitimate income they can.
The problem I see is the plethora of schemes in use.

Some products only get used by individual users, and key updates for
them tend to be flat-file and picked up the next time the product is
"called". Easy.
Except it's the user that gets the expiry message, and that has to
filter up to the correct (contracts) team who have to verify/authorise
payment, and may even get the new key. Then it needs to filter back to
some-one who can do the update.
This may be a customer problem, but it's also a vendor problem if they
get dropped because all the agro isn't worth the effort.

That's the *easy* case - it's all downhill from there.

- License STCs that need to be bounced with every key update. In 24x7
production environments ???. Do these people have any idea what that
takes to get okay'ed ???.
- stop all updates, switch to batch mode, re-cycle. Huh ??? See comment
above.
- unpack the XMIT'd load module, copy to running system(s) ...

I have one customer that I do all of the above (and more) for.
Telling the customer to swap out these products is not an option.

Shane ...

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Few thoughts:
1. The most expensive software is not protected by any key. I mean z/OS, DB2, CICS, IMS and all the IBM code. Some code is even delivered to you without payment, look at IFAPRDxx.
2. Sometimes the keys expire without any warning, it can happen because there's no warning in the product, or the product is not used day by day. Such surprise usually occur according to Murphy's law.
3. IMHO vendors should provide new key in advance, before the current one expires. They should take care about it! (assumed the payments are done).
4. Sometimes the product requires restart to enter new keys. It can be product restart, LNKLST update, or CICS regions restart. The last one is equal to production downtime.
5. DR. Although most vendors provide the key for DR machine, those keys cannot be entered in advance. I would like to have both keys in "key member", so the product would restart in my DR center without any special procedure.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>>Hasn't happened yet!

>You can't change vendors?

Unfortunately not.
There are two products we have that are niche, and there are no competitors.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Maybe "all the time" for you. Clearly not all the time for everybody.

15 products that we are paying for, rather than our service provider.
15 different licensing scheme.
15 PITA's for key management.

It sounds like we're not going to agree.
Keys may be great for the vendor; they suck for the customer!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Russell Witt]

One reason you can NOT compare IBM to any ISV is that IBM knows what
hardware you have; how many box's you have and what size they are. They know
because they sold them to you and you don't have any alternative then to buy
from them (one reason for the ongoing suit). So, they don't have to worry
about you running it on some extra systems.

The ISV doesn't know any of this. How often do you invite your ISV into your
data center to analyze what size machines you have and what they are each
running. Not that the average ISV sales person could tell the difference
between a processor and an air conditioner.

My own point of view is that an expired license should NOT cause the product
to stop working. Messages, yes; to let you know that the license has expired
and you are running the product without legal authority to do so. But it
should not stop working and risk hurting any production activity. I do
remember when LMP (CA License Management Program) was first introduced back
in the early 90's. At the time, Charles indicated that if the license was
expired the software would stop functioning. Boy, just the threat brought
out all kinds of legal wolves. CA-LMP never did actually go into "fail
mode", and never did actually stop any mainframe software for an expired
license (at least to my knoweldge, I could be wrong). But if the license is
expired or the wrong CPU is detected a WTO or message to the user is issued.

Something should be done to simplify the keys however. Myself, I think that
CA should have something simple (web-based) were all the client has to do is
input their site-id and a flat-file is created with all LMP keys licensed in
a single file that can easily be downloaded (cut&paste, ftp, whatever) and
activated on the CPU. Of course, LMP is strong enough that no re-assemblies
are required (or IPL of course). Just re-run the CAS9 proc with the new keys
file and everything is taken care of. And of course there should also be a
simple DR model where you enter your site-id and an alternate CPU ID(s) and
temporary LMP keys would be generated for all licensed products for the new
CPU(s). And of course, this web-site would need 24-hour availability with
telephone support in case the DR site does not have internet connectivity.

Just my opinion;
Russell

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU]On
Behalf Of Ted MacNEIL
Sent: Saturday, February 17, 2007 4:44 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)


>Maybe "all the time" for you. Clearly not all the time for everybody.

15 products that we are paying for, rather than our service provider.
15 different licensing scheme.
15 PITA's for key management.

It sounds like we're not going to agree.
Keys may be great for the vendor; they suck for the customer!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Pinnacle]

>
> Something should be done to simplify the keys however. Myself, I think
> that
> CA should have something simple (web-based) were all the client has to do
> is
> input their site-id and a flat-file is created with all LMP keys licensed
> in
> a single file that can easily be downloaded (cut&paste, ftp, whatever) and
> activated on the CPU.

Russ,

You already provide this. I glom my CA keys off the web site.

Regards,
Tom Conley

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Bob Rutledge]

Russell,

It is already as you think it should be. I've been downloading my LMP keys from
SupportConnect and its predecessors for a Long Time--the file is indeed keyed
off site-id.

Bob

Russell Witt wrote:

..
> Something should be done to simplify the keys however. Myself, I think that
> CA should have something simple (web-based) were all the client has to do is
> input their site-id and a flat-file is created with all LMP keys licensed in
> a single file that can easily be downloaded (cut&paste, ftp, whatever) and
> activated on the CPU.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Schwarz, Barry A]

Unfortunately, at least for the four site IDs I manage, it is not kept
up to date. The last site I checked two weeks ago was two versions out
of date.

-----Original Message-----
From: Bob Rutledge [mailto:snip]
Sent: Saturday, February 17, 2007 4:05 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

Russell,

It is already as you think it should be. I've been downloading my LMP
keys from SupportConnect and its predecessors for a Long Time--the file
is indeed keyed off site-id.

Bob

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Russell Witt wrote:
> One reason you can NOT compare IBM to any ISV is that IBM knows what
> hardware you have; how many box's you have and what size they are. They know
> because they sold them to you and you don't have any alternative then to buy
> from them (one reason for the ongoing suit). So, they don't have to worry
> about you running it on some extra systems.

It's not true. It wasn't true. I hope it won't be true. In the past there were Amdahl, Hitachi, Comparex, Olivetti and other vendors which IBM didn't know about their sales.
Nowadays you some of the non-IBM CPCs are still in use, and last but definitely not least - you can purchase IBM CPC from broker. Even if all your CPCs are from IBM, they're not sure what machine is "cold reserve", what's for DR, and what products are run on this machine, not the other.
So, IBM don't know as well.


> The ISV doesn't know any of this. How often do you invite your ISV into your
> data center to analyze what size machines you have and what they are each
> running. Not that the average ISV sales person could tell the difference
> between a processor and an air conditioner.

That's why there is no need to invite anyone to my server room.
We can analyze everything on paper.
BTW: The most important thing to analyze is license agreement. There are so many gotchas prepared by ISV!
Again, IBM is not likely to negotiate the price for software (however it *IS* subject to negotiate), but I'm pretty sure, there is not "gotcha" in IBM license agreement.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Russell Witt]

Just because you bought the CPC from a broker; you still have maintenance.
Granted, there might be some companies that rely strictly on third-party
hardware support; but not many. If you have IBM hardware support; then again
IBM knows what you have. This is a very big advantage to them.

Russell

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU]On
Behalf Of R.S.
Sent: Saturday, February 17, 2007 6:13 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)


Russell Witt wrote:
> One reason you can NOT compare IBM to any ISV is that IBM knows what
> hardware you have; how many box's you have and what size they are. They
know
> because they sold them to you and you don't have any alternative then to
buy
> from them (one reason for the ongoing suit). So, they don't have to worry
> about you running it on some extra systems.

It's not true. It wasn't true. I hope it won't be true. In the past there
were Amdahl, Hitachi, Comparex, Olivetti and other vendors which IBM didn't
know about their sales.
Nowadays you some of the non-IBM CPCs are still in use, and last but
definitely not least - you can purchase IBM CPC from broker. Even if all
your CPCs are from IBM, they're not sure what machine is "cold reserve",
what's for DR, and what products are run on this machine, not the other.
So, IBM don't know as well.


> The ISV doesn't know any of this. How often do you invite your ISV into
your
> data center to analyze what size machines you have and what they are each
> running. Not that the average ISV sales person could tell the difference
> between a processor and an air conditioner.

That's why there is no need to invite anyone to my server room.
We can analyze everything on paper.
BTW: The most important thing to analyze is license agreement. There are so
many gotchas prepared by ISV!
Again, IBM is not likely to negotiate the price for software (however it
*IS* subject to negotiate), but I'm pretty sure, there is not "gotcha" in
IBM license agreement.


--
Radoslaw Skorupka
Lodz, Poland

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Russell,
You don't give up, but the battle is lost. <g>
I know many sites with unsupported CPCs. Unsupported at all. I also know companies which provide HW support for IBM CPCs. Even IBM doesn't know about installed CPCs. Even IBM doesn't know about real usage of "cold backup" machines. Even IBM does not control what OS is run on the machine: free Linux or expensive z/OS.
What IBM knows is partial view. It's more than nothing, but it's not complete picture.

Last but not least: mainframes are usually used by large companies. Large often means stock exchange quotation, banking, insurance, etc. No of the companies would like to be sued for software piracy. They can't afford it beacuse of the reputation.

--
Radoslaw Skorupka
Lodz, Poland


Russell Witt wrote:
> Just because you bought the CPC from a broker; you still have maintenance.
> Granted, there might be some companies that rely strictly on third-party
> hardware support; but not many. If you have IBM hardware support; then again
> IBM knows what you have. This is a very big advantage to them.
>
> Russell
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
> Behalf Of R.S.
> Sent: Saturday, February 17, 2007 6:13 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: License keys for ISV products(What alternatives are there?)
>
>
> Russell Witt wrote:
>> One reason you can NOT compare IBM to any ISV is that IBM knows what
>> hardware you have; how many box's you have and what size they are. They
> know
>> because they sold them to you and you don't have any alternative then to
> buy
>> from them (one reason for the ongoing suit). So, they don't have to worry
>> about you running it on some extra systems.
>
> It's not true. It wasn't true. I hope it won't be true. In the past there
> were Amdahl, Hitachi, Comparex, Olivetti and other vendors which IBM didn't
> know about their sales.
> Nowadays you some of the non-IBM CPCs are still in use, and last but
> definitely not least - you can purchase IBM CPC from broker. Even if all
> your CPCs are from IBM, they're not sure what machine is "cold reserve",
> what's for DR, and what products are run on this machine, not the other.
> So, IBM don't know as well.
>
>
>> The ISV doesn't know any of this. How often do you invite your ISV into
> your
>> data center to analyze what size machines you have and what they are each
>> running. Not that the average ISV sales person could tell the difference
>> between a processor and an air conditioner.
>
> That's why there is no need to invite anyone to my server room.
> We can analyze everything on paper.
> BTW: The most important thing to analyze is license agreement. There are so
> many gotchas prepared by ISV!
> Again, IBM is not likely to negotiate the price for software (however it
> *IS* subject to negotiate), but I'm pretty sure, there is not "gotcha" in
> IBM license agreement.
>



--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Robert Bardos]

Focussing on the client site administrator aspect, things that
used to annoy me were

- Licence expiration warnings that modified return codes in
production batch jobs
- Licence expiration warnings that went unnoticed
- The variety of expiration warning messages being issued
- The variety of places where theses messages were being sent to
- The variety of methods required to update licence expiration
keys [*1]

[*1 While I didn't have any objections against licence keys at
all]

What I'd like to see (or would have liked to see since I'm no
longer in a position where I do installs):

- unified (i.e. vendor-independent) message ids for licence
related things
(so as to easily automate them)
- site customisable "per-product" thresholds for licence
expiration warnings
(in addition to those being used/issued by product internal
mechanisms)
- the capability to "ask" each product when it will expire
- a tiny little licence management ISPF application
(focussing on the 'information/warning' aspect)


Just a few of those cents that came to my mind immediately. All of
them from the "small system environment" point of view.


Robert Bardos
Ansys AG, Zurich, Switzerland

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Perhaps the problem is with the speed of your accounts payable department?

Perhaps not.
And, perhaps I have had theses issues at more than one company?

And, their speed doesn't make the actual application of the keys easier.


-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>My needs are
>- Expiration date
>- Serial number check
>- Feature control (that is, it is not all or nothing -- you can be licensed
for the product but not for optional feature X)


What you need?
What about what the customers need?

IBM uses the 'trust' model.
Why can't you?

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Charles Mills]

Ted, if you haven't gotten why the trust model is inadequate from my past
posts, and David Cole's, and Dave Salt's, and Russell Witt's, then my
explaining it again probably won't do the trick either.

I didn't list the customers' needs because I assumed you customers whom I
was addressing would know what your needs were; that was the point of my
asking you to design a better approach for me. It's easy to criticize -- how
about a solution?

I hear a lot of input on how to make keys work well for the customer (plenty
of notice, no IPL or re-link, easy 24x7 access to emergency keys, no hard
cutoff [don't think I would do that one, but I hear you]) and believe me, I
will keep it in mind, but I have not heard anyone propose a better solution
than keys. Trust is not the answer, because not all customers (nor all of
their employees and contractors) are trustworthy, and even fewer are totally
diligent -- and many distributors, sadly, seemed to be intentional crooks.
The front door lock analogy is a good one: MOST of my neighbors are
trustworthy, too.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Ted MacNEIL
Sent: Saturday, February 17, 2007 4:00 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

>My needs are
>- Expiration date
>- Serial number check
>- Feature control (that is, it is not all or nothing -- you can be licensed
for the product but not for optional feature X)


What you need?
What about what the customers need?

IBM uses the 'trust' model.
Why can't you?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
>Of Ted MacNEIL
>IBM uses the 'trust' model.
>Why can't you?

It's easy to advocate the trust model when you have nothing to lose. I'm
willing to give the trust model a try, if you're willing to compensate me
for any losses. Deal?

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Buy what you want when you want it on Sympatico / MSN Shopping
http://shopping.sympatico.msn.ca/content/shp/?ctId=2,ptnrid=176,ptnrdata=081805

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <011501c752f2$5dc17030$***@Charles2006>, on 02/17/2007
at 04:18 PM, Charles Mills <***@MCN.ORG> said:

>Ted, if you haven't gotten why the trust model is inadequate from my
>past posts, and David Cole's, and Dave Salt's, and Russell Witt's,
>then my explaining it again probably won't do the trick either.

Which trust model? Why is it more unreasonable for you to trust the
customer than for the customer to trust you? Yes, there are dishonest
customers, but there are also vendors who fail to deliver what they
promise. Given a choice between three companies, one of which asks me
to trust him, one of which posts a performance bond and one of which
doesn't use a key at all, I'll pick the latter over the first two. I
haven't seen any of the second type,

>Trust is not the answer, because not all customers (nor all of their
>employees and contractors) are trustworthy,

Just as not all vendors are trustworthy.

>and even fewer are totally diligent

See above.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Wayne Driscoll]

Ted,
You keep claiming that IBM uses the "trust" model, however, that is
simply not true. If IBM simply trusted you, the machine wouldn't have
checks in it to ensure that the built in "spare" capacity couldn't be
enabled without the machine "phoning home" to verify that the upgrade
was legitimate. How about if you allow the vendor code to periodically
connect to a company web site and report on the STIFLE information found
on the machine, to ensure that it was being run a comparable sized
machine? Then it would follow IBM's "trust" model.
Wayne Driscoll
Product Developer
JME Software LLC
NOTE: All opinions are strictly my own.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Behalf Of Ted MacNEIL
Sent: Saturday, February 17, 2007 6:00 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

>My needs are
>- Expiration date
>- Serial number check
>- Feature control (that is, it is not all or nothing -- you can be
>licensed
for the product but not for optional feature X)


What you need?
What about what the customers need?

IBM uses the 'trust' model.
Why can't you?

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>if you haven't gotten why the trust model is inadequate from my past posts, and David Cole's, and Dave Salt's, and Russell Witt's, then my explaining it again probably won't do the trick either.

You still haven't explained why you are discouraging customers from buying your products.

I have lived the pain, to the point of production failing, and losing revenue from expired keys.

There a legal venues when a contract is not being honoured.

And, I don't buy your arguments, because of my past experience with key-based solutions.

I hope I never need your products, because if I do, I will search for a competitive product that doesn't shaft me (again) with keys.
I'm not saying yours does at all. I don't even know what it is.
What I am saying is I will not take a chance unless I absolutely have to.
Of course, you wouldn't like me as a customer; I have this annoying habit of honouring contracts.

BTW, I was not the only one with an opinion against software keys that chimed in on this list.

And, to put it on the other foot, if you don't understand why customers hate software keys, then there is no use in me trying to explain it to you (or Dave, or Russell).

PS: the crack about the accounts payable department was a cheap shot; it didn't add anything to the discussion.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark Morris]

On 17 Feb 2007 16:40:21 -0800, in bit.listserv.ibm-main you wrote:

>>if you haven't gotten why the trust model is inadequate from my past posts, and David Cole's, and Dave Salt's, and Russell Witt's, then my explaining it again probably won't do the trick either.
>
>You still haven't explained why you are discouraging customers from buying your products.
>
>I have lived the pain, to the point of production failing, and losing revenue from expired keys.
>
>There a legal venues when a contract is not being honoured.
>
>And, I don't buy your arguments, because of my past experience with key-based solutions.
>
>I hope I never need your products, because if I do, I will search for a competitive product that doesn't shaft me (again) with keys.
>I'm not saying yours does at all. I don't even know what it is.
>What I am saying is I will not take a chance unless I absolutely have to.
>Of course, you wouldn't like me as a customer; I have this annoying habit of honouring contracts.
>
>BTW, I was not the only one with an opinion against software keys that chimed in on this list.
>
>And, to put it on the other foot, if you don't understand why customers hate software keys, then there is no use in me trying to explain it to you (or Dave, or Russell).

There are various pains with any software. The keys described by both
Dave Cole and Russell Witt seem reasonable. The major problem may be
random disaster recovery site where the CPU-ID is not known in
advance. The proper management of keys and good disaster recovery
plans should take care of all keys needed if the schemes are like
those described by David and Russell. There are companies that play
games so I can sympathize with vendors like XDC. One of the customers
that tried doing that was the US government on some platform (maybe
PC).
>
>PS: the crack about the accounts payable department was a cheap shot; it didn't add anything to the discussion.

As someone who has never worked for an ISV and who has been very lucky
in the contracting firms he has chosen (they paid promptly), accounts
payable sometimes can get interesting. The quality of work,
promptness of payment and games played like taking prompt payment
discount for paying within 10 days while actually waiting the full 30
can vary even by division within an organization.
>
>-
>Too busy driving to stop for gas!
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Arthur T.]

On 17 Feb 2007 19:54:18 -0800, in bit.listserv.ibm-main
(Message-ID:<000001c75310$60674030$***@hhakcig>)
***@ibm-main.lst (Jeffrey D. Smith) wrote:

>Couple of ideas pop:
>
>1. Reclassify "license refresh" as a non-update.

An update is an update, and you can't reclassify it
as something else. (Paraphrase of old riddle: How many
legs does a dog have if you call a tail a leg? Still only
4; calling a tail a leg doesn't make it one.) If you tried
to reclassify it and fat-fingered a key, production might
stop. Then you get to explain to management how this
wasn't really an update.

>2. Connect the production system to the outside world and
>let the
>ISV product talk to the ISV website server thing to verify
>license
>and dynamically update the license (e.g., "call home").

Many of these check the license very early in the IPL
sequence, often before any communications is
possible. Also, I'd worry about spyware; I don't like the
idea of software calling home.

The methods I most agree with are fail-safe, grace
periods, flat files with multiple keys (for combinations of
dates, products, and serial numbers), and a quick response
for emergency keys.


--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Schmidt]

On Sat, 17 Feb 2007 22:02:15 -0600, Russell Witt wrote:

>Just because you bought the CPC from a broker; you still have maintenance.
>Granted, there might be some companies that rely strictly on third-party
>hardware support; but not many. If you have IBM hardware support; then
again
>IBM knows what you have. This is a very big advantage to them.


Well, there is IBM and then there is $IBM. While the service division
might be aware of what hardware an account has on site, the accounting unit
within IBM is notorious for not having the software inventory up to date
(and probably doesn't have the hardware inventory up to date, too).

For example, ShopzSeries can not be used by my present site for DB2 V8
because the IBMers have not successfully updated the account's inventory
although they have been trying for many months (maybe 6 or more?). Our
site also signed a new ELA back in October that included some new software
and we have not been able to download that software from ShopzSeries to
date because the ELA's updates have not made it into the inventory.

Don't even get me started on the invoices from IBM -- I have only been
looking at them for customers since 1985 and I have NEVER seen one be
completely correct from IBM.

So, no, don't use IBM as an example of a company with a clue how to deal
with keys. I suspect IBM does not use keys for that very reason.

--
Tom Schmidt
Madison, WI


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clark Morris]

On 17 Feb 2007 21:25:28 -0800, in bit.listserv.ibm-main you wrote:

>On Sat, 17 Feb 2007 22:02:15 -0600, Russell Witt wrote:
>
>>Just because you bought the CPC from a broker; you still have maintenance.
>>Granted, there might be some companies that rely strictly on third-party
>>hardware support; but not many. If you have IBM hardware support; then
>again
>>IBM knows what you have. This is a very big advantage to them.
>
>
>Well, there is IBM and then there is $IBM. While the service division
>might be aware of what hardware an account has on site, the accounting unit
>within IBM is notorious for not having the software inventory up to date
>(and probably doesn't have the hardware inventory up to date, too).
>
>For example, ShopzSeries can not be used by my present site for DB2 V8
>because the IBMers have not successfully updated the account's inventory
>although they have been trying for many months (maybe 6 or more?). Our
>site also signed a new ELA back in October that included some new software
>and we have not been able to download that software from ShopzSeries to
>date because the ELA's updates have not made it into the inventory.
>
>Don't even get me started on the invoices from IBM -- I have only been
>looking at them for customers since 1985 and I have NEVER seen one be
>completely correct from IBM.

Back around 1967, my boss got so enraged with the IBM billing
inaccuracy that he called Tom Watson. I don't know if he got through
but he did get a response and at least a temporary relief for the
problem.
>
>So, no, don't use IBM as an example of a company with a clue how to deal
>with keys. I suspect IBM does not use keys for that very reason.
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>If you have IBM hardware support; then again
IBM knows what you have. This is a very big advantage to them.

And, we don't tell the other vendors?
Even with the non-keyed software, we tell the vendor what it's running on.

I don't understand this comment, at all.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Then it would follow IBM's "trust" model.

Okay, I used the wrong term.
Would "non-keyed" suit it better?

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[E***@ibm-main.lst]

In a message dated 2/18/2007 12:32:37 P.M. Central Standard Time,
***@WANADOO.FR writes:

I wonder what people would say if Microsoft was putting an expiring license
key inside W2k or Office in our professional PC's
Although everybody knows forbidden usage happens , keys are normaly used
only in private PC's .
If it was not so , we would not be able to handle deploiement of thousands
of work stations . Software vendors recognise that and do
not stop us from installing or running products whether we have 1000 or
25000 PC's .They trust us in our yearly negotiation.



>>
I've seen a PC with seven dongles and during an upgrade the 3rd one was
dropped and lots of stuff quit working. The shame of it all! There's a license
key for all the new M$ stuff and must be reinstalled(most of the time) during
upgrades and replacements. Software piracy is a huge industry.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Bruno Sugliani]

On Sun, 18 Feb 2007 19:17:48 +0000, Dave Salt <***@HOTMAIL.COM> wrote:

>My product only costs a tiny fraction of the amounts you mentioned. But if I
>had to visit each customer site everytime a license came up for renewal, the
>price could easily double to a 5 figure number.
>
>IMO, any solution that takes into account keeping costs as low as possible
>should not require any kind of on-site inspection.

Yes Dave
and i agree with you .
(apart that if it doubles to a 5 figure number it is already half a five
figure number :-)) )
I never had an onsite inspection from any vendors ( including IBM who asks
me to sign on my honor or whatever that i do not fiddle with the records
for sysplex pricing for example )
But your product does not endanger a DR plan , your product does not affect
the production of 5000 users . Or does it ?
I agree on some non critical product , but having a scheduler ,a tape
management system ,an automation or a batch preparation tool with a key is
what bothers me too much .
Bruno
Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>From: Bruno Sugliani <***@WANADOO.FR>
>Yes Dave
>and i agree with you .
>(apart that if it doubles to a 5 figure number it is already half a five
>figure number :-)) )

Hmm; the licensing cost isn't a 2.5 figure number <g>. It's a 4 figure
number, which if doubled would become a 5 figure number. 4 doubles to 5,
right? ;-)

>your product does not endanger a DR plan , your product does not affect
>the production of 5000 users . Or does it ?

That's a good question, and I honestly don't know the answer. SimpList gives
mainframe users an alternative to the regular ISPF interface. If it suddenly
became unavailable, the regular interface would still be there. In that
sense, it's not 'critical'; i.e. people could still go back to using ISPF
option 3.4 (or whatever they previously used). In other words, SimpList is
nowhere near as mission critical as a tape management system or job
scheduler (etc).

OTOH, SimpList can dramatically impact the productivity of users. If it
suddenly became unavailable, people would have to stop using labels and
symbols (etc) and go back to doing things the old way. This is hardly ideal
in a disaster situation. To use an analogy, imagine if a disaster occurred
and you switched to a site where TSO was available but ISPF was not
available. You'd still be able to get things done, but not nearly at the
kind of pace you'd like.

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Buy what you want when you want it on Sympatico / MSN Shopping
http://shopping.sympatico.msn.ca/content/shp/?ctId=2,ptnrid=176,ptnrdata=081805

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Reda, John]

________________________________

From: IBM Mainframe Discussion List on behalf of Eric N. Bielefeld
Sent: Sun 2/18/2007 9:54 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)


<snip>

This has been a very interesting discussion. A few of the vendors have
givin very good reasons for having keys. This comes at a time when I was
givin the task to renew our Syncsort keys. I found that negotiating the
contract was part of the process, which is something I won't have to do,
fortuneatly for me. When they get the contract process done, I'll just have
to install the keys. By the way, does anyone know if Syncsort's key is a
hard fail key? I suspect it is after a grace period.

<snip>

Eric,

SyncSort will give up to 60 days of warning messages before a contract expires and 7 days afterwards. These messages can be written to the joblog for each sort and the system log twice a day. These messages can be turn off during the 60 days prior the expiration of the control if the customer does not want to see them but it is highly recommended that they do not do this. It is not possilbe to disable these messages during the 7 day grace period after the license has expired.

If a CPU change occurs the sort will continue to execute for 45 days. During this period message will be produced warning the customer of the situation. The customer having the ability to control whether the messages are produced or not for all but the final 7 days.

We offer multiple ways for the customer to install and maintain their license keys. The recommended method is having the keys in a sequential data set. This way modifications to the license keys can be as easy as updating a single data set. Using this method allows the update to be completed without any reassembly/relink/reloading of any modules. Nothing needs to be stopped or restarted. We have tried to make the process as easy as possible.

We provide 7x24 support and all analsyst can immediate help in a situation where a customer has a non-functioning product. I am responsible for customer service and technical support. If you are having difficutlies with our product and are not satisfied with the response you are getting from Syncsort, please contact me directly and I will see to it that whatever issue you are experiencing will get resolved as quickly as possible.

John Reda
Software Services Manager
Syncsort Inc.
201-930-8260





----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Timothy Sipples]

Charles Mills writes:
>Hasn't even IBM gone to
>less and less of a "trust" model? Are not the restrictions on z/OS.e, for
>example, enforced by technology that is somewhat analogous to keys?

Re: z/OS.e, I'd say not. A customer has control over IEASYSxx, subject
(legally) to their license. ("LICENSE=z/OSe" isn't a secret code that only
IBM can issue. :-)) Besides, the last release of z/OS.e is 1.8. Starting
with z/OS 1.9 there are different, still non-key, licensing rules (i.e.
zNALC).

I have to correct something I said earlier. While your product can cut SMF
type 89 records, SCRT may not pick them up. (I'm not 100% sure it will,
anyway, so I'm backing off saying it's so.)
But you can still do reference-based pricing. For example, if you're an
ISV with a DB2 tool, you can charge according to the DB2 MSUs that pop up
in SCRT. Any problems with this approach? It's how IBM charges, and you
can just ask for a "bcc" (blind copy) of the same report IBM gets. If your
customer isn't sending SCRT reports to IBM (isn't VWLC), not a problem: you
can require SCRT even if IBM doesn't.

With respect to distributors and fraud, that's why you ought to consider
providing support and subscription services directly. And why there ought
to be support and subscription services (i.e. active product development).
You can also put into the product installation documentation and even the
installation panels an admonition to "register" with you (the vendor) as
the sole source of "critical updates." (Just an admonition, not a key.)

There's another way to do this: proxy-price to some business metric that
makes sense for your product and forget machine/MIPS entirely. For any
publicly traded company this works quite well in the age of Sarbanes-Oxley.
For example, if your customer is a bank, charge a tiny amount per account.
For a credit card company, charge a tiny fraction of a penny per card
swipe. These business metrics appear in the companies' annual reports,
with high-priced auditors signing off on them, so they must be truthful
under penalty of executive prison sentences. I suppose you could even
price according to something that appears on the customer's tax statement
-- lying to the Internal Revenue Service is a bigger problem for the
customer. Or price according to the company's stock price. Or CEO's total
compensation. Or whatever. As long as it's publicly reported, verifiable,
and there's somebody else that can exact considerable pain if it isn't
correct, it'll probably work.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: ***@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Charles Mills]

Timothy -

Excellent points, and no one wants to hear us debate this ad nauseam. A few
thoughts:

- I'm not a z/OS.e expert. My point was that if you say it's z/OS.e, then
illegal products flat refuse to run. It's like a key in that way.

- I can see a real problem getting people to send us a report. Sounds
stupid, but getting anything out of a customer can be a problem, unless you
have real power of some sort (which IBM does). Heck, it can be a chore
getting a SYSOUT from a customer even when they are reporting a problem. I'm
serious. "This is a critical problem, it's killing us, you have to fix it
right away." "What was the exact message?" "Oh something about an error --
we already purged the SYSOUT."

- Charging by some business metric is the correct answer, except that it
won't work! Seriously, I agree with you that it would be the right way to
charge. I heard Scott McNealy talk one time about charging by corporate
headcount: pay us $50 (?) per month per body and you can have all of the Sun
software you want. It won't work for a small vendor. You can't change the
dominant paradigm. It's hard or impossible if you're big; it's certainly
impossible if you're small. If everyone is used to paying for software by
the MSU, they may bitch about it, but they want to pay some other way even
less. Often the "right" metric is some sort of business volume. For my file
transfer product, I wished we could charge by the kilobyte. The problem is,
any kind of "metering file" is as fraught with "trust" problems as a license
key file. You have to be authorized to cut SMF records -- is that right?
Requiring authorization is a sales obstacle.

- Sure, every software company would rather have sales reps than
distributors. Most small software companies are capital and
management-attention constrained. Overseas offices are VERY capital and
management-attention intensive. It's great to "require" the customers to
contact you, but if the distributor fails to mention that fact, you're right
back where you were. They have the customer's ear and speak his language;
you don't.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Of Timothy Sipples
Sent: Sunday, February 18, 2007 5:27 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

Charles Mills writes:
>Hasn't even IBM gone to
>less and less of a "trust" model? Are not the restrictions on z/OS.e, for
>example, enforced by technology that is somewhat analogous to keys?

Re: z/OS.e, I'd say not. A customer has control over IEASYSxx, subject
(legally) to their license. ("LICENSE=z/OSe" isn't a secret code that only
IBM can issue. :-)) Besides, the last release of z/OS.e is 1.8. Starting
with z/OS 1.9 there are different, still non-key, licensing rules (i.e.
zNALC).

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Eric N. Bielefeld]

Charles,

I sure hope they don't start charging for software by headcount. Every time
I see a headline about a company cutting thousands of workers, invariably
they say that the stock went up. If software costs go down whenever you
have a headcut, that will give management added incentives to cut workers.
They might decide to cut us - then the stock would really go up - at least
for a little while.

Eric Bielefeld
Sr. z/OS Systems Programmer
Lands End
Dodgeville, Wisconsin
414-475-7434

> - Charging by some business metric is the correct answer, except that it
> won't work! Seriously, I agree with you that it would be the right way to
> charge. I heard Scott McNealy talk one time about charging by corporate
> headcount: pay us $50 (?) per month per body and you can have all of the
> Sun
> software you want. >
> Charles

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <004601c75297$57c6bc90$***@yourze8cxvr8tt>, on 02/17/2007
at 07:27 AM, David Day <***@HOUSTON.RR.COM> said:

>From a user's perspective, if the ISV is timely in his delivery of
>license keys, why is it a big deal?

That's the wrong question. How can the user *know* that the ISV will
*always* be timely in his delivery of license keys. It's the lack of
assurance that's the big deal. That's not just hypothetical; CA failed
on that big time during Y2K testing.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[E***@ibm-main.lst]

In a message dated 2/19/2007 8:02:36 A.M. Central Standard Time,
shmuel+ibm-***@PATRIOT.NET writes:

That doesn't solve the problem for either the customer or the vendor.
Consider DR.



>>
Seems like if RSA cards are portable between cell phones should be able to
specify a backup decoder ring-waving his wand and chanting the runes.....

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Mark Zelden]

On Sun, 18 Feb 2007 19:02:38 -0500, Reda, John <***@SYNCSORT.COM> wrote:

<snip>
>We offer multiple ways for the customer to install and maintain their
license keys. The recommended method is having the keys in a sequential
data set. This way modifications to the license keys can be as easy as
updating a single data set.
<snip>

John,

We migrated to the key data set some time ago. I don't think it was
documented when / how often the data set was checked. Is it for every
sort invocation? I don't think I found evidence that it was.

Thanks,

Mark

BTW... as far as the rest of this discussion, I totally sympathize with
the vendors. As someone who consulted full time for many years and also
worked with a vendor directly whose product was abused due to no license
control, I understand. While a lot of the abuse was not intentional
(data center consolidations, then copying libraries from one environment
to the other), a good deal of it was also done just because someone could.
For example, it is very easy for a sysprog to copy a product like FDR
from one system to another because they are more familiar with it
than DFDSS (I saw lots of examples like this in data centers that
went though consolidations).

It would be nice if there was a common method of doing this, but not all
vendors needs and pricing models are the same nor are the way their
products work. Some vendors now do LPAR (size) pricing, some do only
site licensing, some license by the box, the size of the box and the
number of engines. You might as well ask for common installation
method for all products too. I'm not holding my breath.

License keys are a fact of life just like spam. Get over it. What you
need to do is create good documentation for the products that require
them, note whether they are date sensitive, CPU sensitive, or both
and document exactly how to update them - including who to contact
for scheduled updates and emergency updates (phone numbers, web sites,
etc.). Manage that information / documentation how ever it suits your
environment, but it does need to be managed in a modern data center.


--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group: G-ITO
mailto:***@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html






----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <LISTSERV%***@BAMA.UA.EDU>, on 02/19/2007
at 09:35 AM, Mark Zelden <***@ZURICHNA.COM> said:

>License keys are a fact of life just like spam. Get over it.

You could say the same thing about arson, battery, counterfeiting, DOS
attacks, etc. I don't consider it to be a healthy attitude.
Improvements come from those who don't "get over it", but instead
fight evils that they see.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Jon Brock]

I realize this is heresy, but I like the way CA does it. Parts of it, anyway. We get warnings before a key expires. Once we get a new key, we add it to our options file in Common Services (formerly CA-90's, etc.) and rerun CAS9 -- no pain, no downtime.

I have no problem with vendor implementing a license key strategy as long as it is done properly.

Jon


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Thompson, Steve]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Behalf Of Ted MacNEIL
Sent: Saturday, February 17, 2007 6:45 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: License keys for ISV products(What alternatives are there?)

<SNIP>
I have lived the pain, to the point of production failing, and losing
revenue from expired keys.

There a legal venues when a contract is not being honoured.

<SNIP>

So here I am, a start-up vendor. You have decided that me taking you to
court for breach (non-payment) is a good thing, because you don't want
to pay for the software that we've been supporting...

3 years later, in a FED court (because of us not being in the same
state, or whatever) we still haven't been paid, but we're having to fork
out money for a lawsuit after having shutdown the company.

From my perspective, as a vendor, an ounce of prevention is worth more
than the grief and headache of such a lawsuit (let's see, there are the
depositions, the meetings with attorneys to respond to various motions
(rather than doing things that generate CASH FLOW), the experts who have
to look at our financials and determine how much you have hurt us, then
hopefully we can demonstrate fraud (very tough), etc. -- It does happen,
I WAS an officer in a company that is in the middle of this -- however,
not in mainframe software, no one in mainframes would do this, right?).

Later,
Steve Thompson

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Al Sherkow]

SCRT definitely only reports the IBM sub-capacity products for which it is
programmed. No ISV products are reported by SCRT today.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax.

Scenario:
1. Vendor delivers key.
2. Key cannot be installed until the upgrade.
3. Upgrade cannot be done until the weekend.
4. Key fails.
5. Vendor support is only available M-F/9-5 (local time).
6. Asia Pacific Region's Monday Day Shift starts mid-day Sunday (local time).
7. Now what? And, where did my testing fail?


-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Binyamin Dissen]

On Sun, 25 Feb 2007 09:02:40 +0000 Ted MacNEIL <***@YAHOO.CA> wrote:

:>>In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax.

:>Scenario:
:>1. Vendor delivers key.
:>2. Key cannot be installed until the upgrade.
:>3. Upgrade cannot be done until the weekend.
:>4. Key fails.
:>5. Vendor support is only available M-F/9-5 (local time).

That is the problem.

:>6. Asia Pacific Region's Monday Day Shift starts mid-day Sunday (local time).
:>7. Now what? And, where did my testing fail?

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

>From: Ted MacNEIL <***@ibm-main.lst>
>1. Vendor delivers key.
>2. Key cannot be installed until the upgrade.

Why? If the product is designed properly, you should be able to specify more
than one key. If the first key fails, the product tests the second key (and
so on) until a working key is found. This allows you to install keys way
ahead of time (e.g. long before cutting over to a new CPUID). SimpList
allows up to 3 keys; a number of other MacKinney products allow up to 6.

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
Don’t waste time standing in line—try shopping online. Visit Sympatico / MSN
Shopping today! http://shopping.sympatico.msn.ca

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Jeffrey D. Smith]

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
> Behalf Of Dave Salt
> Sent: Sunday, February 25, 2007 10:47 AM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: License keys for ISV products(What alternatives are there?)
>
> >From: Ted MacNEIL <***@YAHOO.CA>
> >1. Vendor delivers key.
> >2. Key cannot be installed until the upgrade.
>
> Why? If the product is designed properly, you should be able to specify
> more
> than one key. If the first key fails, the product tests the second key
> (and
> so on) until a working key is found. This allows you to install keys way
> ahead of time (e.g. long before cutting over to a new CPUID). SimpList
> allows up to 3 keys; a number of other MacKinney products allow up to 6.
>
> Dave Salt

Even in that scenario, how do you know that the key for the new CPUID
will actually work when the CPU is upgraded? There should be some kind
of key test mode thing to be sure the key will work on an anticipated
CPUID.

Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Bruno Sugliani]

Looks like introducing knowingly a single point of failure into a system
without any way out .
This was my point earlier on
I was caught 3 years ago despite warning the vendor of the differences in
STSI and STIDP on z/990 but indeed they ignored me and no batch would run
i had to call someone in Texas ( sorry guys but the Texas or Florida accent
mixed with my own exasperated french accent brought some extra delays
to our batch window )
It added latency like some new managers call it :-))
Bruno
Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr


On Sun, 25 Feb 2007 09:02:40 +0000, Ted MacNEIL <***@YAHOO.CA> wrote:

>>In the case of a processor upgrade: if you get a hard error during
production due to a bad ISV key, your testing criteria are way too lax.
>
>Scenario:
>1. Vendor delivers key.
>2. Key cannot be installed until the upgrade.
>3. Upgrade cannot be done until the weekend.
>4. Key fails.
>5. Vendor support is only available M-F/9-5 (local time).
>6. Asia Pacific Region's Monday Day Shift starts mid-day Sunday (local time).
>7. Now what? And, where did my testing fail?
>
>
>-
>Too busy driving to stop for gas!
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>=========================================================================

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Would be great if all invoices were paid on time.

Would be great if vendors delivered working keys all the time!
Would be great if vendors were available 7-24!

Neither of the two above have anything to do with timely payments.
AND, the scenario I proposed, I lived through.

Without naming names, the product in question only had two vendors and one was a work-alike for another.
Both vendors have/had M-F/9-5 support.

Keys failed on a weekend.
Company works in many time-zones.
Support didn't.
Bill was payed.
Keys failed.

As I said: "Now what"?

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Binyamin Dissen]

On Sun, 25 Feb 2007 13:57:34 +0000 Ted MacNEIL <***@YAHOO.CA> wrote:

:>>Would be great if all invoices were paid on time.

:>Would be great if vendors delivered working keys all the time!

Yes

:>Would be great if vendors were available 7-24!

Yes.

:>Neither of the two above have anything to do with timely payments.
:>AND, the scenario I proposed, I lived through.

:>Without naming names, the product in question only had two vendors and one was a work-alike for another.
:>Both vendors have/had M-F/9-5 support.

:>Keys failed on a weekend.
:>Company works in many time-zones.
:>Support didn't.
:>Bill was payed.
:>Keys failed.

:>As I said: "Now what"?

Since you recognized the problem in advance, you had the opportunity to
request for someone to be on-call during the testing interval.

I would find it hard to believe that the unnamed vendor with 9-5 support would
have strongly objected for a "one of" weekend support.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

-------------------------<snip>-----------------------
I would find it hard to believe that the unnamed vendor with 9-5 support
would have strongly objected for a "one of" weekend support.
----------------------<unsnip>-----------------------
You'd be amazed at the number of vendors that will NOT provide support
outside the 9-5 M-F window. I even had a vendor rep hang up on me in the
middle of a call because it was now 5:00 PM where he was. Some of those
(unprintables) are unionized and unions havee INCREDIBLE power here.
Needless to say, our business relationship with that particular vendor
ended the next day. We learned how to manage without his package and
saved ourselves a bundle of $$$ besides.

Names deleted to protect the incompetant. And stoopid!!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ed Gould]

On Feb 25, 2007, at 11:04 AM, Rick Fochtman wrote:

> -------------------------<snip>-----------------------
> I would find it hard to believe that the unnamed vendor with 9-5
> support would have strongly objected for a "one of" weekend support.
> ----------------------<unsnip>-----------------------
> You'd be amazed at the number of vendors that will NOT provide
> support outside the 9-5 M-F window. I even had a vendor rep hang up
> on me in the middle of a call because it was now 5:00 PM where he
> was. Some of those (unprintables) are unionized and unions havee
> INCREDIBLE power here. Needless to say, our business relationship
> with that particular vendor ended the next day. We learned how to
> manage without his package and saved ourselves a bundle of $$$
> besides.
>
> Names deleted to protect the incompetant. And stoopid!!
Rick,

Agreed. But that is usually after the fact. "we" are not included in
license negotiations so we are typically get to work on the SH*T that
is handed us to install and maintain. I think I have had to deal with
the 9-5 product that is being talked about. IIRC we almost had to
back out a CPU upgrade because of a key failure. Talk about fingers
being pointed (all our way btw). Of course there are others (CA-1 as
an example) that provides excellent coverage at 2 AM btw.

Its bad enough with a single product / vendor. But (in the case of
CA) you can threaten to eliminate all of their products but it will
be a multi year and probably high $$ cost to do so. I know we did it
with one other vendor, Compuware. We did save money and almost no
lost of functionality. As I said one vendor product is usually no
problem its the multi product vendor that is usually the issue (hard
one).

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a "one of" weekend support.

ITYM "one off".

Objected, no.
Refused, yes!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Why? If the product is designed properly, you should be able to specify more
than one key.

Woulda! Coulda! Shoulda!

It wasn't!
That's my main objections to keys!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

> >If the product is designed properly, you should be able to specify more
>than one key.
>
>Woulda! Coulda! Shoulda!
>It wasn't!
>That's my main objections to keys!

Don't you mean "that's my main objection to the way a particular vendor has
implemented his keys"?

I understand that your experience with keys has been less than ideal. But,
there are vendors out there who design keys so that:

a) A warning message is displayed long before a key expires.
b) A new key is sent to you long before a key expires.
c) The keys can be entered in a flat file (i.e. nothing to
compile/link/refresh etc).
d) Multiple keys can be stored so that new keys can be entered way ahead of
time.

It takes 2 minutes to enter a key in a flat file. It's not a big deal.

In an ideal world, it would be nice not to bother with keys. If I lose my
keys and lock myself out of my car, it's a pain. Carrying grocery bags and
struggling to unlock my front door is a pain. I'd like to throw away all my
keys and leave everything unlocked. But that's not the world we live in.

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
http://local.live.com/default.aspx?v=2&cp=43.658648~-79.383962&style=r&lvl=15&tilt=-90&dir=0&alt=-1000&scene=3702663&cid=7ABE80D1746919B4!1329

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

At 2/25/2007 01:15 PM, TMacNeil wrote:
>>Why? If the product is designed properly, you should be able to
>>specify more than one key.
>
>Woulda! Coulda! Shoulda!
>
>It wasn't!
>That's my main objections to keys!

Your objection is misplaced, Ted. It should not be against keys. It
should be against badly implemented keys, as done by specific vendors.

Every one of the objections expressed by you over these past several
weeks can be addressed by intelligent programming and careful support
on the vendor's part. Not every vendor is guilty of the problems you
continually allege.




Good programming is an art requiring extreme precision.
So is good discussion!


Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Binyamin Dissen]

On Sun, 25 Feb 2007 18:09:27 +0000 Ted MacNEIL <***@YAHOO.CA> wrote:

:>>I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a "one of" weekend support.

:>ITYM "one off".

:>Objected, no.
:>Refused, yes!

Even to support installing the product off hours?

If so, I am quite amazed.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Not every vendor is guilty of the problems you
continually allege.


I'm not the only one that 'continually' alleges.
And, if there are vendors with better practices, I have only met two. I may not have travelled as many miles as some of you, but key management for the mainframe is the second worst idea that I have seen for software asset management.
The worst was tier-based pricing.

Every vendor I have dealt with has caused us key issues at least once in the last year, except one.
We have 15 products that we are paying for directly, rather than through our service provider.

7 of them have keys.
Even the 'perpetual' keys have caused us problems.

I am (obviously) NOT a fan of them.
If I could find a work-alike, I would.
(I have for two).
In both cases, one is key-based the other is not.

We are in the process of evaluating application change management software and I have recommended against two vendors because they are key-based.

We have only two vendors that have implemented 'good' key-based solutions.
One is SYNCHSORT - the grace period is so long, it doesn't cause us issues.
The other will remain nameless because naming it will name the competitor that has lousy support, poor key management, M-F/9-5, and no grace period.
We switched to this 'other', because of better support and the potential to develop emergency keys at their support web-site.
If I have to have keys, that's the best option out of a bad licence enforcement methodology.

Many vendors manage their licencing without the introduction of points of instability into the customers environment.
Also, as somebody pointed out, no large company wants bad press! Most mainframe shops are large companies.
So, why would they/we want to be outed for bad practices like this?

We have been tarred with the brush that has been used on the Windows types and their poor practices.

It is irrelevant that not all vendors have such bad ways of implementation.
It is relevant that the ones we are forced to use do.
Some of it is poor process (A/R or key management), poor implementation, poor communication, or fat fingers.
It's nice that some have good implementation.
But, we are not their customers.
You have to play the hand your dealt.
The better draw comes when you can get rid of the keys.

Who, in their right mind, wants to add single points of vulnerability in an already complex environment?
Especially, one where management is seriously looking for alternatives, at many companies.

You keep up with complex/confusing implementations, and we can argue about the temperature of a burning house!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Don't you mean "that's my main objection to the way a particular vendor has
implemented his keys"?

Many more than one vendor!

>I understand that your experience with keys has been less than ideal. But, there are vendors out there who design keys so that:

Only two (soon to be three), so far.

>a) A warning message is displayed long before a key expires.

Not many, in my experience.

>b) A new key is sent to you long before a key expires.

Since when? We've always had to ask!
Even SYNCSORT.

>c) The keys can be entered in a flat file (i.e. nothing to compile/link/refresh etc).

Only one vendor, so far. And, we are only in the evaluation phase, so it's not in production, yet.

>d) Multiple keys can be stored so that new keys can be entered way ahead of time.

None of our vendors; including the one we are evaluating.

>It takes 2 minutes to enter a key in a flat file. It's not a big deal.

Have you ever heard of the large bureacracy called 'Change Control'? The most ironic aspect of IT. The number one responsibility of C/C is to slow down the rate of change.
The number one task of IT is to facilitate change.


>In an ideal world, it would be nice not to bother with keys.

This analagy is weak and irrelevant to the discussion at hand.
Computers are not garages.
Software products are not cars!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Salt]

> >Don't you mean "that's my main objection to the way a particular vendor
>has
>implemented his keys"?
>
>Many more than one vendor!

Okay, lot's of vendors have bad keys. Lot's of restaurants are unhygienic.
This doesn't mean all restaurants are unhygienic.

If it were not for keys, some customers wouldn't pay on time (or wouldn't
pay at all). This means ISV's would need to take customers to court (at
significant cost, both in terms of time and money), or they'd have to
increase the prices paid by other customers. Either way, these costs would
be passed on to other customers (e.g. you). So, whether you like them or
not, keys save your company money.

> >In an ideal world, it would be nice not to bother with keys.
>
>This analagy is weak and irrelevant to the discussion at hand.
>Computers are not garages.
>Software products are not cars!

A metal key is used to protect a metal car. A software key is used to
protect a software product. Property is property, and keys are designed to
protect property. I'm sorry you don't see the analogy.

Dave Salt
SimpList - the easiest. most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________
http://local.live.com/default.aspx?v=2&cp=43.658648~-79.383962&style=r&lvl=15&tilt=-90&dir=0&alt=-1000&scene=3702663&cid=7ABE80D1746919B4!1329

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>Even to support installing the product off hours?

>If so, I am quite amazed.

The product was/is key to our environment, but only cost $5K/annum.
Not worth the vendor's time/$.
There are few alternatives, and if they lose us, it's not like they lose a large revenue stream.

We have since switched to a work-alike product that the vendor has a self-service web-site to get a temporary key (4 days), so we can move on.

If you MUST have keys, this is a better choice.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>If it were not for keys, some customers wouldn't pay on time (or wouldn't pay at all).

THAT is my point of disagreement!

Most shops that are mainframe shops are large companies.
Large companies do NOT want their names in the press.
Ergo, they will do everything they can to pay on time.
Yes, we have process problems, but so do the vendors.

We have a gross revenue of $30BUS, net of $1.3BUS.
Do you think we are going to dick you around for even a $50K contract?

Call the press and tell them!

But, no, the vendor would rather complicate our environment, introduce single points of failure, and make us look for alternatives.
WHICH we are doing!

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html