Re: SV: cpu / machine identification

[Scott Ford]

Rick,
Like your style


Sent from my iPad

On Jan 3, 2012, at 5:23 PM, Rick Fochtman  wrote:

> ---:
>  
>> Zman,
>> In that case a .45 automatic and a big dog comes in handy, lol , sorry just 
>> couldn't resist..
>> 
>> Regards,
>> Scott
> ---
> Screw the dog. My .44 AutoMag will suffice. And I don't have to walk it twice 
> a day, or feed it daily. :-)
> 
> Rick
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SV: cpu / machine identification

[Rick Fochtman]

---: 


Zman,
In that case a .45 automatic and a big dog comes in handy, lol , sorry just 
couldn't resist..

Regards,
Scott

---
Screw the dog. My .44 AutoMag will suffice. And I don't have to walk it 
twice a day, or feed it daily. :-)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re; cpu / machine identification

[Dale Miller]

Scott Ford wrote: "Been on the phone with a certain ISP and had to  
tell them how to shoot the problem."  I worked for a company whose  
business involved processing records of pharmaceutical sales. We had   
processing centers in diverse locations which entailed a lot of data  
transmission. The implementation of HIPAA required that we start  
encrypting our data transmissions. When we read about HIPAA, we  
realized we needed encryption facilities and tried to make the  
corporate head shed aware that we would need some hardware/software.  
Others in the company had already written a C routine to do AES  
encryption/decryption for their UNIX boxes, but our processing was  
mostly in MVS (75 % of the processing for less than 50% of the  
budget). I suggested we get the IBM or SAS C compiler for our system,  
but their decision was to use a vendor-provided AES utility which  
required periodic key updates and a lot more expense. I've given away  
the punch line, but some time later, our nightly processing died with  
an RC12 from the AES utility. I went through the documentation but the  
listed cause of an RC12 was just not applicable. After spending a day  
on the phone with the vendor's support staff who obviously didn't have  
a clue, one of our brighter (very bright) applications people Googled  
upon an updated manual which included "expired key" as the cause of an  
RC12. I can understand support staff having a difficult time debugging  
an obscure problem on a complex system, but this support staff's not  
bothering to read the manual (or not having a current manual) is a  
little too much. Of course, I don't have a good excuse for not  
Googling for a more current manual, either.


Dale Miller

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SV: cpu / machine identification

[Scott Ford]

Zman,
In that case a .45 automatic and a big dog comes in handy, lol , sorry just 
couldn't resist..

Regards,
Scott

Sent from my iPad

On Jan 3, 2012, at 1:17 PM, zMan  wrote:

> Yes. I know folks who live near prisons: they leave cars unlocked with
> keys in them, on the theory that if someone breaks out, they'd rather
> they take the car and go than come into the house...
> 
> On Tue, Jan 3, 2012 at 11:57 AM, Bill Fairchild
>  wrote:
>> I have had two different cars of mine broken into with considerable damage 
>> in both cases.  But I still leave them locked.  I guess this would depend on 
>> the crime level where one lives.
>> 
>>  I also had a car hotwired and stolen once.  Since hotwiring could easily 
>> cause damage, are there also some who leave their cars unlocked with the key 
>> in the ignition in order to avoid damage if someone wants to steal the car?--
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SV: cpu / machine identification

[zMan]

Yes. I know folks who live near prisons: they leave cars unlocked with
keys in them, on the theory that if someone breaks out, they'd rather
they take the car and go than come into the house...

On Tue, Jan 3, 2012 at 11:57 AM, Bill Fairchild
 wrote:
> I have had two different cars of mine broken into with considerable damage in 
> both cases.  But I still leave them locked.  I guess this would depend on the 
> crime level where one lives.
>
>  I also had a car hotwired and stolen once.  Since hotwiring could easily 
> cause damage, are there also some who leave their cars unlocked with the key 
> in the ignition in order to avoid damage if someone wants to steal the car?--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SV: cpu / machine identification

[Bill Fairchild]

I have had two different cars of mine broken into with considerable damage in 
both cases.  But I still leave them locked.  I guess this would depend on the 
crime level where one lives.

 I also had a car hotwired and stolen once.  Since hotwiring could easily cause 
damage, are there also some who leave their cars unlocked with the key in the 
ignition in order to avoid damage if someone wants to steal the car?

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Brian Westerman
Sent: Friday, December 30, 2011 6:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SV: cpu / machine identification

Seems sort of counter-intuitive. :)

Brian

On Thu, 29 Dec 2011 10:35:21 +0100, Thomas Berg  wrote:

>> -Ursprungligt meddelande-
>> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För 
>> Brian Westerman
>> Skickat: den 29 december 2011 03:10
>> Till: IBM-MAIN@bama.ua.edu
>> Ämne: Re: cpu / machine identification
>>
>...
>> I'm sure you lock your car, why do that if you have the only key?  :)
>>
>> Brian
>
>I know of people that don't lock their cars - to avoid damage if someone wants 
>to get into the car.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Scott Ford]

Brian,

I am used to that type of support structure. I have noticed a more of a 
reliance on the vendor for a lot more than the actual product the support. 

Regards,
Scott


Sent from my iPad

On Jan 3, 2012, at 1:11 AM, Brian Westerman  
wrote:

> I agree,
> 
> We make sure that when we say we are staffed, that we mean on site at one of 
> our 3 branches, not by some company that just answers the phone.  The way we 
> handle it in times when no one is around is that the support line phone 
> system will automatically page someone after 5 minutes if no one physically 
> takes the call, and after 10 minutes two people are paged, and at 15 minutes 
> a third is added.  After 30 minutes, the upper management people get added, 
> so it's really rare to have more too much time go by.  Unfortunately, we 
> don't have the same feature on our web site. :(
> 
> Brian
> 
> On Mon, 2 Jan 2012 12:27:39 -0500, Scott Ford  wrote:
> 
>> John,
>> Me either ,  I would have thought the vendor had the tools. Sounds like they 
>> want u to pay to have it done.
>> 
>> Regards,
>> Scott ford
>> 
>> Sent from my iPad
>> 
>> On Jan 1, 2012, at 9:01 PM, John McKown  wrote:
>> 
>>> On Sun, 2012-01-01 at 12:23 -0500, Scott Ford wrote:
 Brian,
 Yep the India support get back to you doesn't set well with me as a vendor.
 We get back to our customers ASAP. Also want to add, don't expect the
 Support to know anything. Been on the phone with a certain ISP and had
 to tell them how to shoot the problem.
 
 Regards,
 Scott
 
 Sent from my iPad
 
>>> 
>>> Not just India, per se. It's the vendor, regardless of country.
>>> 
>>> We in z/OS support, for some reason, are tasked with a distributed
>>> application, which replaced a z/OS application. It runs on a Tomcat
>>> server on Linux, and a Windows server. It uses Oracle as some sort of
>>> "index" for data files kept on a NAS box. They also support the
>>> application using MS SQL. We want to convert from Tomcat/Linux with
>>> Oracle to Tomcat/Windows with MS SQL (I don't know why). The vendor DOES
>>> NOT KNOW HOW TO DO THIS! They are asking us for things like the Oracle
>>> schema ( or maybe its the data: 3 Terabytes). WHAT??? It's __their__
>>> schema. They don't know how to copy the data in the Oracle database into
>>> an MS SQL database. I'm not really in this discussion, so maybe I'm
>>> missing something. And don't intend to try getting into, because our
>>> DBAs are now outsourced. I really don't want to bother with that
>>> headache of talking to the US reps of a Dutch company to tell an
>>> outsourced DBA what needs to be done. Oh, my. I'm would be homicidal in
>>> about 5 minutes. I don't suffer fools gladly.
>>> 
>>> 
>>> 
>>> --
>>> John McKown
>>> Maranatha! <><
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

I agree,

We make sure that when we say we are staffed, that we mean on site at one of 
our 3 branches, not by some company that just answers the phone.  The way we 
handle it in times when no one is around is that the support line phone system 
will automatically page someone after 5 minutes if no one physically takes the 
call, and after 10 minutes two people are paged, and at 15 minutes a third is 
added.  After 30 minutes, the upper management people get added, so it's really 
rare to have more too much time go by.  Unfortunately, we don't have the same 
feature on our web site. :(

Brian

On Mon, 2 Jan 2012 12:27:39 -0500, Scott Ford  wrote:

>John,
>Me either ,  I would have thought the vendor had the tools. Sounds like they 
>want u to pay to have it done.
>
>Regards,
>Scott ford
>
>Sent from my iPad
>
>On Jan 1, 2012, at 9:01 PM, John McKown  wrote:
>
>> On Sun, 2012-01-01 at 12:23 -0500, Scott Ford wrote:
>>> Brian,
>>> Yep the India support get back to you doesn't set well with me as a vendor.
>>> We get back to our customers ASAP. Also want to add, don't expect the
>>> Support to know anything. Been on the phone with a certain ISP and had
>>> to tell them how to shoot the problem.
>>>
>>> Regards,
>>> Scott
>>>
>>> Sent from my iPad
>>>
>>
>> Not just India, per se. It's the vendor, regardless of country.
>>
>> We in z/OS support, for some reason, are tasked with a distributed
>> application, which replaced a z/OS application. It runs on a Tomcat
>> server on Linux, and a Windows server. It uses Oracle as some sort of
>> "index" for data files kept on a NAS box. They also support the
>> application using MS SQL. We want to convert from Tomcat/Linux with
>> Oracle to Tomcat/Windows with MS SQL (I don't know why). The vendor DOES
>> NOT KNOW HOW TO DO THIS! They are asking us for things like the Oracle
>> schema ( or maybe its the data: 3 Terabytes). WHAT??? It's __their__
>> schema. They don't know how to copy the data in the Oracle database into
>> an MS SQL database. I'm not really in this discussion, so maybe I'm
>> missing something. And don't intend to try getting into, because our
>> DBAs are now outsourced. I really don't want to bother with that
>> headache of talking to the US reps of a Dutch company to tell an
>> outsourced DBA what needs to be done. Oh, my. I'm would be homicidal in
>> about 5 minutes. I don't suffer fools gladly.
>>
>>
>>
>> --
>> John McKown
>> Maranatha! <><
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Scott Ford]

John,
Me either ,  I would have thought the vendor had the tools. Sounds like they 
want u to pay to have it done.

Regards,
Scott ford

Sent from my iPad

On Jan 1, 2012, at 9:01 PM, John McKown  wrote:

> On Sun, 2012-01-01 at 12:23 -0500, Scott Ford wrote:
>> Brian,
>> Yep the India support get back to you doesn't set well with me as a vendor.
>> We get back to our customers ASAP. Also want to add, don't expect the
>> Support to know anything. Been on the phone with a certain ISP and had
>> to tell them how to shoot the problem.
>> 
>> Regards,
>> Scott
>> 
>> Sent from my iPad
>> 
> 
> Not just India, per se. It's the vendor, regardless of country. 
> 
> We in z/OS support, for some reason, are tasked with a distributed
> application, which replaced a z/OS application. It runs on a Tomcat
> server on Linux, and a Windows server. It uses Oracle as some sort of
> "index" for data files kept on a NAS box. They also support the
> application using MS SQL. We want to convert from Tomcat/Linux with
> Oracle to Tomcat/Windows with MS SQL (I don't know why). The vendor DOES
> NOT KNOW HOW TO DO THIS! They are asking us for things like the Oracle
> schema ( or maybe its the data: 3 Terabytes). WHAT??? It's __their__
> schema. They don't know how to copy the data in the Oracle database into
> an MS SQL database. I'm not really in this discussion, so maybe I'm
> missing something. And don't intend to try getting into, because our
> DBAs are now outsourced. I really don't want to bother with that
> headache of talking to the US reps of a Dutch company to tell an
> outsourced DBA what needs to be done. Oh, my. I'm would be homicidal in
> about 5 minutes. I don't suffer fools gladly. 
> 
> 
> 
> -- 
> John McKown
> Maranatha! <><
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Martin Packer]

One of the things I've been injecting into my code (the SMF analysis code 
I inherited and now maintain) in recent years has been more nosiness. :-) 
More nosiness in this case means recognising software product related 
footprints in the sand. It's a fun game. :-)

Cheers, Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:
Barry Merrill 
To:
IBM-MAIN@bama.ua.edu, 
Date:
01/01/2012 17:53
Subject:
Re: cpu / machine identification
Sent by:
IBM Mainframe Discussion List 



I was involved in an audit of a VERY large outsourcer on behalf
of a VERY large software vendor, some time ago.

The only data required for the audit was the site's SMF data
(and a smart program to read the SMF file!), plus a program that
allocated and grazed the disk farm to capture all DSNAMES and
attributes (which DCOLLECT would do now).

>From an intelligent examination of the names of datasets, which 
clearly indicated/suggested they were the software company's 
property, along with a listing of the names of the members of
those load libraries, and a comparison to the SMF program names 
that had been executed, which demonstrated those programs were 
being executed from those libraries, the two companies withdrew
their suit and countersuit, and reached agreements on licensing.

And, after only the very FIRST report was reviewed by both parties!

Quite a bit of additional analysis software had been prepared to
tighten up the SMF-to-LoadLib connection, which would have analyzed
the DDNAMEs used by these programs, but those programs were never used.


Merrilly New Year,
Barry Merrill

Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
214 351 1966 tel
214 350 3694 fax
http://www.mxg.com
ba...@mxg.com

MXG Support:   supp...@mxg.com
MXG Admin:  ad...@mxg.com

Standard Answers: http://www.mxg.com/administration
What's Supported:   http://www.mxg.com/changes









-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
Of Shmuel Metz (Seymour J.)
Sent: Sunday, January 01, 2012 9:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: cpu / machine identification

In <9693770902631563.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/31/2011
   at 06:51 PM, Brian Westerman  said:

>Sorry Shmuel, I mind works on a different level than my fingers 
>sometimes.  I apologize for the mistake on your name.

That's why I try to remember to cut and paste rather than retyping names. 
Of
course, I sometimes slip :-(

>I'm still not too sure that there is a way to conduct an audit that 
>would satisfy the vendor, that the site would agree to.

Providing SMF data? Proving a userid with limited authority specifically 
for
auditing?

>but if you limit the audit, then it's not an audit.

Doesn't that depend on what the limitations are?

>The audit would have to allow a search of all load libraries at a 
>minimum, and would entail loading each and every module to check 
>internally, not doesn't that sound like a lot of fun, it would be cost 
>prohibitive for both the vendor and the site.

That would be more of a hassle for the vendor than for the site. I would
expect a vendor to do random spot checks rather than running an audit, 
e.g.,
every 30 days.

>I think most would go for the key after that.

I've seen products thrown out because of the keys.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

SV: SV: cpu / machine identification

[Thomas Berg]

Seems Yes, but is not.  Many are just after valuables and not the car.  So with 
not locking (and not have any valuables in the car), You usually don't have any 
damage.

 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 



> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> Brian Westerman
> Skickat: den 31 december 2011 01:08
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: SV: cpu / machine identification
> 
> Seems sort of counter-intuitive. :)
> 
> Brian
> 
> On Thu, 29 Dec 2011 10:35:21 +0100, Thomas Berg 
> wrote:
> 
> >> -Ursprungligt meddelande-
> >> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> >> Brian Westerman
> >> Skickat: den 29 december 2011 03:10
> >> Till: IBM-MAIN@bama.ua.edu
> >> Ämne: Re: cpu / machine identification
> >>
> >...
> >> I'm sure you lock your car, why do that if you have the only key?  :)
> >>
> >> Brian
> >
> >I know of people that don't lock their cars - to avoid damage if someone
> wants to get into the car.
> >
> >
> >
> >Regards,
> >Thomas Berg
> >_
> >Thomas Berg   Specialist   A M   SWEDBANK
> >
> >
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[John McKown]

On Sun, 2012-01-01 at 12:23 -0500, Scott Ford wrote:
> Brian,
> Yep the India support get back to you doesn't set well with me as a vendor.
> We get back to our customers ASAP. Also want to add, don't expect the
> Support to know anything. Been on the phone with a certain ISP and had
> to tell them how to shoot the problem.
> 
> Regards,
> Scott
> 
> Sent from my iPad
> 

Not just India, per se. It's the vendor, regardless of country. 

We in z/OS support, for some reason, are tasked with a distributed
application, which replaced a z/OS application. It runs on a Tomcat
server on Linux, and a Windows server. It uses Oracle as some sort of
"index" for data files kept on a NAS box. They also support the
application using MS SQL. We want to convert from Tomcat/Linux with
Oracle to Tomcat/Windows with MS SQL (I don't know why). The vendor DOES
NOT KNOW HOW TO DO THIS! They are asking us for things like the Oracle
schema ( or maybe its the data: 3 Terabytes). WHAT??? It's __their__
schema. They don't know how to copy the data in the Oracle database into
an MS SQL database. I'm not really in this discussion, so maybe I'm
missing something. And don't intend to try getting into, because our
DBAs are now outsourced. I really don't want to bother with that
headache of talking to the US reps of a Dutch company to tell an
outsourced DBA what needs to be done. Oh, my. I'm would be homicidal in
about 5 minutes. I don't suffer fools gladly. 



-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Edward Jaffe]

On 1/1/2012 6:37 AM, Mike Schwab wrote:

On Sat, Dec 31, 2011 at 11:16 PM, Edward Jaffe
  wrote:

This checking by various products leads to quite a bit of redundancy. A
centralized approach to license compliance would seem superior--reasoning
that led to the creation of the 'IBM License Manager for z/OS' debacle.

http://www.computerworld.com/s/article/76517/IBM_drops_mainframe_license_manager_tool


Exactly! After all that effort--by IBM and numerous ISVs--to make ILM for z/OS a 
reality, we ended up no further ahead that before we started. Well, not quite. 
At least, we all now have a better understanding of the enormity of the project. 
Another side benefit are nice System z capacity query capabilities--far better 
than what existed before. Also, the need for license compliance management 
didn't go away just because the ILM for z/OS project failed. Software producers 
seized on the opportunity to produce priced products to help. For example:


http://www.ibm.com/software/tivoli/products/license-compliance-mgr/

Of course, the downside is that product license keys themselves are still 
managed and applied using a hodge-podge of techniques. But, license compliance 
products are still a big step in the right direction.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Barry Merrill]

I was involved in an audit of a VERY large outsourcer on behalf
of a VERY large software vendor, some time ago.

The only data required for the audit was the site's SMF data
(and a smart program to read the SMF file!), plus a program that
allocated and grazed the disk farm to capture all DSNAMES and
attributes (which DCOLLECT would do now).

>From an intelligent examination of the names of datasets, which 
clearly indicated/suggested they were the software company's 
property, along with a listing of the names of the members of
those load libraries, and a comparison to the SMF program names 
that had been executed, which demonstrated those programs were 
being executed from those libraries, the two companies withdrew
their suit and countersuit, and reached agreements on licensing.

And, after only the very FIRST report was reviewed by both parties!

Quite a bit of additional analysis software had been prepared to
tighten up the SMF-to-LoadLib connection, which would have analyzed
the DDNAMEs used by these programs, but those programs were never used.


Merrilly New Year,
Barry Merrill

Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
214 351 1966 tel
214 350 3694 fax
http://www.mxg.com
ba...@mxg.com

MXG Support:   supp...@mxg.com
MXG Admin:  ad...@mxg.com

Standard Answers: http://www.mxg.com/administration
What's Supported:   http://www.mxg.com/changes









-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Sunday, January 01, 2012 9:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: cpu / machine identification

In <9693770902631563.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/31/2011
   at 06:51 PM, Brian Westerman  said:

>Sorry Shmuel, I mind works on a different level than my fingers 
>sometimes.  I apologize for the mistake on your name.

That's why I try to remember to cut and paste rather than retyping names. Of
course, I sometimes slip :-(

>I'm still not too sure that there is a way to conduct an audit that 
>would satisfy the vendor, that the site would agree to.

Providing SMF data? Proving a userid with limited authority specifically for
auditing?

>but if you limit the audit, then it's not an audit.

Doesn't that depend on what the limitations are?

>The audit would have to allow a search of all load libraries at a 
>minimum, and would entail loading each and every module to check 
>internally, not doesn't that sound like a lot of fun, it would be cost 
>prohibitive for both the vendor and the site.

That would be more of a hassle for the vendor than for the site. I would
expect a vendor to do random spot checks rather than running an audit, e.g.,
every 30 days.

>I think most would go for the key after that.

I've seen products thrown out because of the keys.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Scott Ford]

Brian,
Yep the India support get back to you doesn't set well with me as a vendor.
We get back to our customers ASAP. Also want to add, don't expect the Support 
to know anything. Been on the phone with a certain ISP and had to tell them how 
to shoot the problem.

Regards,
Scott

Sent from my iPad

On Dec 31, 2011, at 9:19 PM, Brian Westerman  
wrote:

> I 100% agree.  Having been a systems programmer for most of my life, I'm used 
> to the 24x7 mode of support.  A lot of vendors are not.  Or even worse, have 
> a support number in India that will "page" someone, to get back to you.
> 
> Brian
> 
> On Sat, 31 Dec 2011 17:57:44 -0500, Shmuel Metz (Seymour J.) 
>  wrote:
> 
>> In <9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>> 12/29/2011
>>  at 08:29 PM, Brian Westerman  said:
>> 
>>> The one thing I do know is that vendors have the right to protect
>>> their software and as long as it's reasonable protection, I don't see
>>> why a site would complain about it.
>> 
>> What do you mean by reasonable protection? From a customer
>> perspective, it's not reasonable if it interferes with anything that's
>> permitted by the license. That's why it's important for a vendor to
>> consider failure modes and to have 24x366 coverage if he's going to
>> use any sort of license-key mechanism.
>> 
>> --
>>Shmuel (Seymour J.) Metz, SysProg and JOAT
>>ISO position; see 
>> 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <9693770902631563.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/31/2011
   at 06:51 PM, Brian Westerman  said:

>Sorry Shmuel, I mind works on a different level than my fingers
>sometimes.  I apologize for the mistake on your name.

That's why I try to remember to cut and paste rather than retyping
names. Of course, I sometimes slip :-(

>I'm still not too sure that there is a way to conduct an audit that
>would satisfy the vendor, that the site would agree to.

Providing SMF data? Proving a userid with limited authority
specifically for auditing?

>but if you limit the audit, then it's not an audit.

Doesn't that depend on what the limitations are?

>The audit would have to allow a search of all load libraries at a
>minimum, and would entail loading each and every module to check
>internally, not doesn't that sound like a lot of fun, it would be
>cost prohibitive for both the vendor and the site.

That would be more of a hassle for the vendor than for the site. I
would expect a vendor to do random spot checks rather than running an
audit, e.g., every 30 days.

>I think most would go for the key after that.

I've seen products thrown out because of the keys.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <9920027903334789.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/31/2011
   at 06:43 PM, Brian Westerman  said:

>So the question should be, who should bear the cost of that?  The
>vendor, who has no control over the choices,

The vendor *does* have control. Specifically, the vendor controls
whether there will be license keys, how they are implemented and how
they are supported. The customer has no say in the matter, so why
should the customer bear the cost?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Mike Schwab]

On Sat, Dec 31, 2011 at 11:16 PM, Edward Jaffe
 wrote:
>
> Many years ago, one of our largest customers, with a complex and
> ever-changing configuration, requested that we perform robust and exhaustive
> checking of the execution environment in which (E)JES executes. This
> checking includes CPU serial/type/model, LPAR names, z/VM guest names, etc.
> Violations begin with subtle warnings and escalate over time (days) to
> eventually become a non-scrolling console message.
>
> Apparently, they made similar requests to other vendors as well. Their
> intent was to automate license compliance and limit liability. They argued
> that such messages would ensure no out-of-policy product execution could go
> unnoticed by their operators and system administrators. They have been very
> pleased with our implementation.
>
> This checking by various products leads to quite a bit of redundancy. A
> centralized approach to license compliance would seem superior--reasoning
> that led to the creation of the 'IBM License Manager for z/OS' debacle.
>
> --
> Edward E Jaffe

http://www.computerworld.com/s/article/76517/IBM_drops_mainframe_license_manager_tool
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shane]

On Sat, 31 Dec 2011 21:16:17 -0800 Edward Jaffe wrote:

> --reasoning that led to the creation of the 'IBM License
> Manager for z/OS' debacle.

Wash your mouth out fella    ;-)
Well that's just ruined a potentially wonderful nascent year.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Edward Jaffe]

On 12/27/2011 5:55 AM, Mark Zelden wrote:

In my own personal experience as a sysprog, I know some of the
same things have happened unintentionally.   Consolidations, moving
LPARs around, creating / cloning new LPARs can lead to this and
when the software doesn't check it's easy for the "techies" to
make mistakes since they often (usually?) don't know the T's and
C's of all the software contracts.

So even though it can be a pain, I actually prefer that any vendor that
cares, checks the CPU id for authorization.


Many years ago, one of our largest customers, with a complex and ever-changing 
configuration, requested that we perform robust and exhaustive checking of the 
execution environment in which (E)JES executes. This checking includes CPU 
serial/type/model, LPAR names, z/VM guest names, etc. Violations begin with 
subtle warnings and escalate over time (days) to eventually become a 
non-scrolling console message.


Apparently, they made similar requests to other vendors as well. Their intent 
was to automate license compliance and limit liability. They argued that such 
messages would ensure no out-of-policy product execution could go unnoticed by 
their operators and system administrators. They have been very pleased with our 
implementation.


This checking by various products leads to quite a bit of redundancy. A 
centralized approach to license compliance would seem superior--reasoning that 
led to the creation of the 'IBM License Manager for z/OS' debacle.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shane]

A while back (years) as part of an install we asked for a phone link
for the "dial-home" on the machine.
No - and take the dialing mechanism out of the machine.
Say what ???.

Being a new customer site (a bank), they were accommodated. Later on
they needed factory support for a hardware issue. The factory wanted to
dial *into* the machine. This was (eventually) acceded to.

So you just never know which way customers are going to jump.

Shane ...

On Sat, 31 Dec 2011 22:24:41 -0500 zMan wrote:

> Uh. And then of course you'll find that your request (a) doesn't work
> because it's blocked and (b) triggers IDS alarms, which you then get
> to explain. Not something I'd recommend trying.
> 
> > Actually, we had thought of putting in a module to request the key
> > automatically, the code was fairly simple to request a new key from
> > our server via TCP, and as long as the product had not expired the
> > whole thing could be generated within a short transaction.  When we
> > floated it to some of our customers, they mostly responded back
> > with  "why?".
> >
> > So it wasn't worth the time to finish the code, but I kept the
> > original prototype just in case we changed our minds later.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

Uh. And then of course you'll find that your request (a) doesn't work
because it's blocked and (b) triggers IDS alarms, which you then get
to explain. Not something I'd recommend trying.

On Sat, Dec 31, 2011 at 9:25 PM, Brian Westerman
 wrote:
> Actually, we had thought of putting in a module to request the key 
> automatically, the code was fairly simple to request a new key from our 
> server via TCP, and as long as the product had not expired the whole thing 
> could be generated within a short transaction.  When we floated it to some of 
> our customers, they mostly responded back with  "why?".
>
> So it wasn't worth the time to finish the code, but I kept the original 
> prototype just in case we changed our minds later.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Actually, we had thought of putting in a module to request the key 
automatically, the code was fairly simple to request a new key from our server 
via TCP, and as long as the product had not expired the whole thing could be 
generated within a short transaction.  When we floated it to some of our 
customers, they mostly responded back with  "why?".

So it wasn't worth the time to finish the code, but I kept the original 
prototype just in case we changed our minds later.

Brian

On Sat, 31 Dec 2011 20:11:17 -0600, Mike Schwab  wrote:

>Here is an idea:  How about the message to the operator has reply
>value of ACK or ENTER.
>ACK would stand for acknowledge that you need a new key.
>ENTER would start a dialog to enter a new key.
>Reply with a 800 number to call and a customer number for the company.
>When the operator calls, you look them up and give them a license key
>for the new machine.
>
>On Sat, Dec 31, 2011 at 6:43 PM, Brian Westerman
> wrote:
>> So the question should be, who should bear the cost of that?  The vendor, 
>> who has no control over the choices, or the site that wants to run the 
>> software?
>>
>> Unfortunately, this whole thread has sparked a heated debate internally 
>> here.  There are those that are for scrapping the licensing code, and those 
>> that want it increased so that it's tighter with an easier way to extend 
>> things, (which seems counter productive to me).  As with most arguments, the 
>> ones that develop the code have one mindset, and the ones that support the 
>> code have another, with the one that don't do either sitting on the fence 
>> cheering for blood:).
>>
>> Brian
>>
>>
>> On Fri, 30 Dec 2011 21:55:37 -0500, Robert A. Rosenberg  
>> wrote:
>>
>>>At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu /
>>>machine identification:
>>>
>>>>We have  DR support in our software, but I was under the impression
>>>>that most of the DR sites were running the OS under VM and they
>>>>simulated the serial anyway.
>>>>
>>>>I suppose their are sites that do not run the DR under VM, but don't
>>>>the sites who don't run under VM know the serial number ahead of
>>>>time, and wouldn't it be already built into the software, or they
>>>>have a already setup job to enter the new serial(s)?  I know I would
>>>>have it set up if it were me.
>>>
>>>Knowing the Serial Number of the machine you are going to run DR on
>>>and having it already built into the software is being too
>>>optimistic. Not only can you have multiple DR Sites to go to and
>>>choosing one based on who can service you when you need DR Services
>>>but even if it was only one site, I am sure that they have multiple
>>>machines and you would not want to list all of them. Until you get
>>>there, you would not know which machine that is going to be assigned
>>>to you.
>>>
>>>--
>>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>Mike A Schwab, Springfield IL USA
>Where do Forest Rangers go to get away from it all?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Apparently we seem to be getting closer and closer to that.

Brian

On Sat, 31 Dec 2011 18:36:52 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In
>,
>on 12/29/2011
>   at 11:11 PM, Mike Schwab  said:
>
>>Would some of the macro worms be possible to infect some Linux
>>products with macros on x86 and x64 and S390x?
>
>That's a concern for workstations, but who runs, e.g., Firefox,
>OpenOffice on z?
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

I 100% agree.  Having been a systems programmer for most of my life, I'm used 
to the 24x7 mode of support.  A lot of vendors are not.  Or even worse, have a 
support number in India that will "page" someone, to get back to you.

Brian

On Sat, 31 Dec 2011 17:57:44 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>12/29/2011
>   at 08:29 PM, Brian Westerman  said:
>
>>The one thing I do know is that vendors have the right to protect
>>their software and as long as it's reasonable protection, I don't see
>>why a site would complain about it.
>
>What do you mean by reasonable protection? From a customer
>perspective, it's not reasonable if it interferes with anything that's
>permitted by the license. That's why it's important for a vendor to
>consider failure modes and to have 24x366 coverage if he's going to
>use any sort of license-key mechanism.
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Mike Schwab]

Here is an idea:  How about the message to the operator has reply
value of ACK or ENTER.
ACK would stand for acknowledge that you need a new key.
ENTER would start a dialog to enter a new key.
Reply with a 800 number to call and a customer number for the company.
When the operator calls, you look them up and give them a license key
for the new machine.

On Sat, Dec 31, 2011 at 6:43 PM, Brian Westerman
 wrote:
> So the question should be, who should bear the cost of that?  The vendor, who 
> has no control over the choices, or the site that wants to run the software?
>
> Unfortunately, this whole thread has sparked a heated debate internally here. 
>  There are those that are for scrapping the licensing code, and those that 
> want it increased so that it's tighter with an easier way to extend things, 
> (which seems counter productive to me).  As with most arguments, the ones 
> that develop the code have one mindset, and the ones that support the code 
> have another, with the one that don't do either sitting on the fence cheering 
> for blood:).
>
> Brian
>
>
> On Fri, 30 Dec 2011 21:55:37 -0500, Robert A. Rosenberg  
> wrote:
>
>>At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu /
>>machine identification:
>>
>>>We have  DR support in our software, but I was under the impression
>>>that most of the DR sites were running the OS under VM and they
>>>simulated the serial anyway.
>>>
>>>I suppose their are sites that do not run the DR under VM, but don't
>>>the sites who don't run under VM know the serial number ahead of
>>>time, and wouldn't it be already built into the software, or they
>>>have a already setup job to enter the new serial(s)?  I know I would
>>>have it set up if it were me.
>>
>>Knowing the Serial Number of the machine you are going to run DR on
>>and having it already built into the software is being too
>>optimistic. Not only can you have multiple DR Sites to go to and
>>choosing one based on who can service you when you need DR Services
>>but even if it was only one site, I am sure that they have multiple
>>machines and you would not want to list all of them. Until you get
>>there, you would not know which machine that is going to be assigned
>>to you.
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

So the question should be, who should bear the cost of that?  The vendor, who 
has no control over the choices, or the site that wants to run the software?

Unfortunately, this whole thread has sparked a heated debate internally here.  
There are those that are for scrapping the licensing code, and those that want 
it increased so that it's tighter with an easier way to extend things, (which 
seems counter productive to me).  As with most arguments, the ones that develop 
the code have one mindset, and the ones that support the code have another, 
with the one that don't do either sitting on the fence cheering for blood:).

Brian 


On Fri, 30 Dec 2011 21:55:37 -0500, Robert A. Rosenberg  
wrote:

>At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu /
>machine identification:
>
>>We have  DR support in our software, but I was under the impression
>>that most of the DR sites were running the OS under VM and they
>>simulated the serial anyway.
>>
>>I suppose their are sites that do not run the DR under VM, but don't
>>the sites who don't run under VM know the serial number ahead of
>>time, and wouldn't it be already built into the software, or they
>>have a already setup job to enter the new serial(s)?  I know I would
>>have it set up if it were me.
>
>Knowing the Serial Number of the machine you are going to run DR on
>and having it already built into the software is being too
>optimistic. Not only can you have multiple DR Sites to go to and
>choosing one based on who can service you when you need DR Services
>but even if it was only one site, I am sure that they have multiple
>machines and you would not want to list all of them. Until you get
>there, you would not know which machine that is going to be assigned
>to you.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Sorry Shmuel, I mind works on a different level than my fingers sometimes.  I 
apologize for the mistake on your name.

I'm still not too sure that there is a way to conduct an audit that would 
satisfy the vendor, that the site would agree to.  I don't think disrupting a 
site is what the vendor would be trying to do, but if you limit the audit, then 
it's not an audit.  i.e. I have a dollar in my pocket, but if you can't see the 
dollar then I am broke and you can look at me to prove that I am broke, but you 
cannot look into my pocket, because that might be disruptive. :}

The audit would have to allow a search of all load libraries at a minimum, and 
would entail loading each and every module to check internally, not doesn't 
that sound like a lot of fun, it would be cost prohibitive for both the vendor 
and the site.

The cost (in manpower) to enter a new license key is trivial compared to the 
cost of preparing for the audit.  Then you would have to multiply it by the 
total software vendor base.  I think most would go for the key after that.

Brian


On Sat, 31 Dec 2011 17:47:17 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <8724193196442157.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>12/29/2011
>   at 08:03 PM, Brian Westerman  said:
>
>>I'm sorry Schmuel,
>
>That's Shmuel!
>
>>giving a vendor access to their site
>
>There's a difference between permitting an audit and allowing
>unrestricted access. I've certainly been at sites that allowed audits,
>but the auditors were limited to the relevant data.
>
>>In this case I hardily agree with the view that the the vendor would
>>be told to go pound salt.
>
>Perhaps by the bean counters, although I haven't seen that happen.
>What I have seen is shops where the presence of a licensing key is a
>deal breaker[1].
>
>>Imagine the security issues
>
>BTDTGTTS. The Devil is in the details, and it's not rocket science.
>
>There is a type of "audit" that I'd consider unacceptable: when trade
>organizations threaten to get a court order and conduct a deliberately
>disruptive search in order to extort payment of money that is not due.
>But that's not what is under discussion here.
>
>[1] In the sense that they would only license the product if there
>were contract terms that no vendor would ever agree to.
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

You may have a point, but our view is that good software shouldn't have to cost 
an arm and a leg to be good.  Mainly we are a consulting firm, and software 
started as a "sideline", but once you get over a couple hundred clients, you 
have to devote more time and people resources to it, so now it's a whole 
separate "division".  We make sure that our software does what "theirs" does 
plus extra features.  We have a good number of clients running it, but IBM and 
CA, even though they are far more expensive, and with less features in some 
cases, still has a far greater market share.

I'm not sure hiking the price will help in this case.  We try to cater to the 
sites that want value, and we would be only hurting them by upping to price to 
see if it would increase our market share.

We have two new products coming out this year, maybe since neither one has any 
competition we should put a outrageously high price on them:).  I seriously 
doubt that we will do that though, it just isn't the way we work.

Brian



On Fri, 30 Dec 2011 18:48:14 -0600, Chase, John  wrote:


>
>There still exists a mindset that believes, for example, that since
>functionality ABC "normally" costs between $xxxK and $yyyK, then "your"
>offer of functionality ABC at $xxxK/20 "can't be very good", or "you
>don't have the resources to provide the kind of support we need", etc.
>
>IOW, maybe your product's price is "too cheap".
>
>-jc-
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/29/2011
   at 08:29 PM, Brian Westerman  said:

>The one thing I do know is that vendors have the right to protect
>their software and as long as it's reasonable protection, I don't see
>why a site would complain about it.

What do you mean by reasonable protection? From a customer
perspective, it's not reasonable if it interferes with anything that's
permitted by the license. That's why it's important for a vendor to
consider failure modes and to have 24x366 coverage if he's going to
use any sort of license-key mechanism.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <0713029417803027.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/29/2011
   at 08:42 PM, Brian Westerman  said:

>I suppose their are sites that do not run the DR under VM, but don't
>the sites who don't run under VM know the serial number ahead of
>time, and wouldn't it be already built into the software, or they
>have a already setup job to enter the new serial(s)?  I know I would
>have it set up if it were me.

You can't set it up; you can only ask your vendor to set it up. Then
when it doesn't work at the DR site you get to call your vendor and
try to get it taken care of. I didn't get a tee shirt, only scars.

>This also has nothing to do with the question, but I have always
>thought that the vendor should be compensated for support of the DR
>testing anyway.  (this will probably cause a lot of angry
>responses).

I'm sure that it will. The customer only uses the DR site a few days a
year, and the only significant support he normally needs is for bugs
in the licensing keys that are not for the customers' benefit in the
first place.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In
,
on 12/29/2011
   at 11:11 PM, Mike Schwab  said:

>Would some of the macro worms be possible to infect some Linux
>products with macros on x86 and x64 and S390x?

That's a concern for workstations, but who runs, e.g., Firefox,
OpenOffice on z?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <8724193196442157.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/29/2011
   at 08:03 PM, Brian Westerman  said:

>I'm sorry Schmuel, 

That's Shmuel!

>giving a vendor access to their site

There's a difference between permitting an audit and allowing
unrestricted access. I've certainly been at sites that allowed audits,
but the auditors were limited to the relevant data.

>In this case I hardily agree with the view that the the vendor would
>be told to go pound salt. 

Perhaps by the bean counters, although I haven't seen that happen.
What I have seen is shops where the presence of a licensing key is a
deal breaker[1].

>Imagine the security issues

BTDTGTTS. The Devil is in the details, and it's not rocket science.

There is a type of "audit" that I'd consider unacceptable: when trade
organizations threaten to get a court order and conduct a deliberately
disruptive search in order to extort payment of money that is not due.
But that's not what is under discussion here.

[1] In the sense that they would only license the product if there 
were contract terms that no vendor would ever agree to.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Robert A. Rosenberg]

At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu / 
machine identification:


We have  DR support in our software, but I was under the impression 
that most of the DR sites were running the OS under VM and they 
simulated the serial anyway.


I suppose their are sites that do not run the DR under VM, but don't 
the sites who don't run under VM know the serial number ahead of 
time, and wouldn't it be already built into the software, or they 
have a already setup job to enter the new serial(s)?  I know I would 
have it set up if it were me.


Knowing the Serial Number of the machine you are going to run DR on 
and having it already built into the software is being too 
optimistic. Not only can you have multiple DR Sites to go to and 
choosing one based on who can service you when you need DR Services 
but even if it was only one site, I am sure that they have multiple 
machines and you would not want to list all of them. Until you get 
there, you would not know which machine that is going to be assigned 
to you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Brian Westerman
> 
> We have  DR support in our software, but I was under the impression
that most of the DR sites were
> running the OS under VM and they simulated the serial anyway.
> 
> I suppose their are sites that do not run the DR under VM, but don't
the sites who don't run under VM
> know the serial number ahead of time, and wouldn't it be already built
into the software, or they have
> a already setup job to enter the new serial(s)?  I know I would have
it set up if it were me.
> 
> This also has nothing to do with the question, but I have always
thought that the vendor should be
> compensated for support of the DR testing anyway.  (this will probably
cause a lot of angry
> responses).  It's a separate processor and the vendor has to support a
problem that might occur on it
> just like they would if it were the primary processor, which may not
have the issue.  If that were the
> case, then the vendor has to support your DR test for free.  Now if
you are paying $50k for the
> software, it's probably a reasonable expectation, but if you are
paying $2K to $5K it's not as
> reasonable.

There still exists a mindset that believes, for example, that since
functionality ABC "normally" costs between $xxxK and $yyyK, then "your"
offer of functionality ABC at $xxxK/20 "can't be very good", or "you
don't have the resources to provide the kind of support we need", etc.

IOW, maybe your product's price is "too cheap".

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Okay,

Snipping the other stuff makes sense, but I'll keep my reply on top.  I hate 
trying to skip through only to find that the person interspersed the comments.

Brian

On Fri, 30 Dec 2011 07:48:55 -0600, Tom Marchant  
wrote:

>On Thu, 29 Dec 2011 20:29:02 -0600, Brian Westerman wrote:
>
>>I found out that the quote is not on by default (the hard way :))
>>and also that I have to click on it BEFORE I enter any data.
>
>I'm glad that you've figured out how to quote the message that
>you are replying to.  Now, I'd like to ask you to delete most of
>the message you are replying to, leaving enough to establish
>context for your remarks.
>
>I would also suggest that you post your comments AFTER the material
>that you quote.  It make a difference if there is more than one point
>that you would like to reply to, as I do in this reply.  It also makes a
>difference if someone would like to reply to more than one thing in your
>post.
>..snip

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

I think I know that guy.  He must work at just about every mainframe site in 
the world.  :)

Brian

On Thu, 29 Dec 2011 21:14:13 -0600, John McKown  wrote:

>On Thu, 2011-12-29 at 20:32 -0600, Brian Westerman wrote:
>> I didn't realize that a employee can bind the site, but I can see where that 
>> might actually be the case.
>>
>> I can imagine what would happen to a site like IBM in Dallas, should
>> Microsoft or Corel say, "we're coming on Tuesday to check every one of
>> your machines".  That would be very interesting.
>>
>> Brian
>>
>
>Reminds me vaguely of an internal auditor who wanted access to the z/OS
>system in order to verify that it was not compromised by Windows
>viruses. Was incensed that z/OS did not have any virus scanning software
>installed. Literally __could not__ understand why a Windows virus
>couldn't infect the mainframe. "software is software" and "a system is a
>system". Didn't understand that the z wasn't Intel compatible. Complete
>IT idiot.
>
>--
>John McKown
>Maranatha! <><
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SV: cpu / machine identification

[Brian Westerman]

Seems sort of counter-intuitive. :)

Brian

On Thu, 29 Dec 2011 10:35:21 +0100, Thomas Berg  wrote:

>> -Ursprungligt meddelande-
>> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
>> Brian Westerman
>> Skickat: den 29 december 2011 03:10
>> Till: IBM-MAIN@bama.ua.edu
>> Ämne: Re: cpu / machine identification
>>
>...
>> I'm sure you lock your car, why do that if you have the only key?  :)
>>
>> Brian
>
>I know of people that don't lock their cars - to avoid damage if someone wants 
>to get into the car.
>
>
> 
>Regards,
>Thomas Berg
>_
>Thomas Berg   Specialist   A M   SWEDBANK
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Tom Marchant]

On Thu, 29 Dec 2011 20:29:02 -0600, Brian Westerman wrote:

>I found out that the quote is not on by default (the hard way :)) 
>and also that I have to click on it BEFORE I enter any data.

I'm glad that you've figured out how to quote the message that 
you are replying to.  Now, I'd like to ask you to delete most of 
the message you are replying to, leaving enough to establish 
context for your remarks.

I would also suggest that you post your comments AFTER the material 
that you quote.  It make a difference if there is more than one point 
that you would like to reply to, as I do in this reply.  It also makes a 
difference if someone would like to reply to more than one thing in your 
post.

Also, when top posting, it is easy to forget to trim the message that you 
are replying to.

> On Thu, 29 Dec 2011 15:02:14 +, Pommier, Rex R. 
>  wrote:
>>
>>I see your point, but have a request for you.  Don't get quite so aggressive 
>>with the electronic scissors on snipping away the context.  The beginning of 
>>your comment below says it all - "That works...".  What's "that"?  Since 
>>there have been several comments/points of view made, it would be much easier 
>>to leave the comment you are replying to in your reply.
>>
>>The information contained in this e-mail may contain confidential ...
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Above is an example of text that should have been deleted from this post. 
I left it in to illustrate the point of the need to delete those parts of the 
post that are not relevant to your reply.  Perhaps you can also see why 
bottom posting is better.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Ed Gould]

On Dec 26, 2011, at 3:11 PM, zMan wrote:


OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.


OK,

I have run into two companies and one was just cheapness and the  
other was well dishonest.
Both knew better but until a hammer is applied at the head nothing  
was accomplished.

I pointed out the issue and was told to shut up.
The other company claimed stupidity and I was told to shut up.
Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Ed Gould]

Sam:

From some experience. We were constantly adding/changing cpu's over  
just a two year period I remember going through at least 15 changes  
and it could have been more. From past experience PLEASE allow some  
amount of time (execution wise) if the serial number(s) do not agree.  
We would get the serial numbers invariably on Friday and have to make  
30-40 (it was spread out over several people) phone calls. INVARIABLY  
a number was either misread or mis-keyed or whatever and we had to  
make emergency phone calls in the middle of the night to the software  
company asking for a temporary number until the morning.
Also please do not keep the keys in storage (or if you do allow a  
simple way to update them).
We had one vendor who will remain nameless who didn't have 24 hour  
support and it was a critical piece of software and we had to back  
out the upgrade what a disaster. Needless to say the vendor got  
kicked out of the shop as soon as we found a replacement.


Ed

On Dec 26, 2011, at 3:19 PM, Sam Siegel wrote:


zMan - Thanks for the reply.  It is a new product - No customers yet.

I would like enough licensing to keep honest people honest and an
operationally oriented reminder for the annual renewal.

Sam

On Mon, Dec 26, 2011 at 1:11 PM, zMan  wrote:


Gahh, "IF BibBox, Inc".

On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:

On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:
Hello List - I'm attempting to create a licensing mechanism for  
a bit

of software.  I would like to be able to use a unique and
non-modifiable identifier as part of the mechanism.

The CSRSI callable service and STSI instruction provide a  
variety of

hardware related identifiers.

CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.

 These
appear directly related to PCCACPID (PCCA control block) and  
Sequence

Code

(STSI basic machine configuration)..

Is there any preference to using one field over the other?  What  
are the

advantages and disadvantages of using each field?

Are there other fields (in same or other control blocks) that  
should be

used?

Please feel free to treat this as an open ended question related to
licensing mechanism and provided any related advice and tips  
based on

experience.


OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the  
mainframe

software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.

Having said that, I would expect that any CPUID processing would  
work

off, well, the CPUID. That's what customers understand.

SAS Institute used to have a nice CPUID system for their C compiler
that would issue a warning and print out what company the sucker was
licensed to, but would continue to operate if the CPUID was wrong.
This allowed emergency operation, while clearly keeping any real
company from running it on the wrong box (though I suppose of  
BigBox,

Inc. licensed it on one and ran it on two, it would be harder to
notice; the case I'm thinking of was when we were running the
Merrill-Lynch copy on another company's machine, WITH permission  
from

SAS; every time we invoked the compiler, it would whine and say
"Licensed to Merrill-Lynch").

Now, with systems management stuff that doesn't have a real UI that
gets invoked all the time, it's harder. The best I've seen allowed:
- multiple key entries in the CPUID file, so you didn't have to  
worry

about swapping files at expiration: you just added new entries and
eventually deleted the old ones. And you could keep all your  
CPUIDs in

a common file, shared (or replicated) across systems.
- Warned starting 30 days before expiration, on the operator's
console: "XYZ will expire in 30 days" (29, 28...).
- If it had a valid license (i.e., one with time on it but on the
wrong machine) would run in "emergency mode", whining on the
operator's console every 10 minutes or so, but still running (this
allowed for DR).
- Supported "universal" temporary keys, that could be
read/emailed/FAXed by support at 3AM if you really screwed up and  
were

dead in the water despite the above.

Now, this also meant that there were folks carrying beepers and temp
keys, so they could do that after-hours support.

Are you prepared to deal with all this? Is it worth it?

As you can tell, I'm not a fan of such mechanisms. But it's not my
decision (doh), so I'm trying to help :-)
--
zMan -- "I've got a mainframe and I'm not afraid to use it"




--
zMan -- "I've got a mainframe and I'm not afraid to use it"

- 
-

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / s

Re: cpu / machine identification

[Mike Schwab]

On Thu, Dec 29, 2011 at 9:14 PM, John McKown  wrote:
> On Thu, 2011-12-29 at 20:32 -0600, Brian Westerman wrote:
>> I didn't realize that a employee can bind the site, but I can see where that 
>> might actually be the case.
>>
>> I can imagine what would happen to a site like IBM in Dallas, should
>> Microsoft or Corel say, "we're coming on Tuesday to check every one of
>> your machines".  That would be very interesting.
>>
>> Brian
>>
>
> Reminds me vaguely of an internal auditor who wanted access to the z/OS
> system in order to verify that it was not compromised by Windows
> viruses. Was incensed that z/OS did not have any virus scanning software
> installed. Literally __could not__ understand why a Windows virus
> couldn't infect the mainframe. "software is software" and "a system is a
> system". Didn't understand that the z wasn't Intel compatible. Complete
> IT idiot.
>
> --
> John McKown
> Maranatha! <><

Would some of the macro worms be possible to infect some Linux
products with macros on x86 and x64 and S390x?

Our site was audited (I think by detecting software remotely).  We had
license various numbers of licenses for various versions of some
software products.  A later version of the software got included into
the default install image and was installed on lots more machines than
we had licenses for that version.  Cost our site 7 figures to license
what we had installed.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[John McKown]

Depends on what they want to do. HIPAA is a big deal in my shop. If they
just want SMF data, I normally run the job to create the dataset for
them and send it to them. No big deal about that. If they want a
"sysprog" level access (which has never happened), well, I'll do what
I'm told. But if it were me, I'd tell them to get a court order, siting
HIPAA. And get lots of legal documents signed by somebody like the
president or other high officer of the company. Maybe even many
somebodies.

On Thu, 2011-12-29 at 20:03 -0600, Brian Westerman wrote:
> I'm sorry Schmuel, normally I agree with your point on things, but I
> really have to disagree here.  It's not like I have no experience with
> other sites, we have hundreds of clients, and I have been to well over
> 80% of them in person, and I can state without much worry that the
> percentages would not be on my side that the far greater percentage
> (approaching 100%) would never agree to giving a vendor access to
> their site to "check up" on them.
> 
> Even when we go to a site as the "IBM" people, they go way out of
> their way to make sure that we stay focused on the problem and don't
> just "look around".  As a "non IBM" vendor, it would be even less
> likely that the client would just open their site to us.
> 
> In this case I hardily agree with the view that the the vendor would
> be told to go pound salt.  Imagine the security issues that would have
> to be dealt with to just give them an ID that has the capability to
> check.  
> 
> Brian

-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Linda Mooney]

Hi Brian, 



/snip 

I received an email between my last response and this one that said (a lot of 
things, but basically) that many sites (the grater percentage) don't know what 
they pay for their software because a) it's done by another department or their 
boss, or b) they only think about it when they first license the product and 
don't think about the cost involved until they either run low on budget and are 
trying to save some amount or they have a problem that makes them unhappy with 
the product that they are currently paying for. 

Is that true across the board with you people? 
/esnip 



All invoices have to be routed to our Accounts Payable folks to get paid here.  
In good budget times, and at the very last minute usually , the Accounts 
Payable folks would ask the technical contact (the sysprog) if the software was 
still being used and if there were any changes planned.  Then the invoice would 
get paid.  Vendors generally would NOT send an info copy of the invoice to the 
sysprog or a reminder of renewal time. :-( 



Now that we are in our 4th year of very bad budget (layoffs and LOTS of cuts) a 
senior sysprog has to justo every single piece of software that is billed, 
regardless of how much it costs.  Tucked in behind the existing process, a 
justo for each and every product has to be written and approved up the line 
before the invoice can be paid.  This can cause a lot of delay in getting the 
bill paid.  



My experience with having to write justos and try to keep keys up to date, is 
that if the vendor will email a renewal notice with a courtesy copy of the 
invoice to the senior sysprog (listed technical contact) - and ALSO send the 
invoice directly to Accounts Payable, payments have a much better chance of 
happening on time - without the need for temporary keys or extra stress.  



Linda 


- Original Message -


From: "Brian Westerman"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, December 29, 2011 6:42:29 PM 
Subject: Re: cpu / machine identification 

We have  DR support in our software, but I was under the impression that most 
of the DR sites were running the OS under VM and they simulated the serial 
anyway. 

I suppose their are sites that do not run the DR under VM, but don't the sites 
who don't run under VM know the serial number ahead of time, and wouldn't it be 
already built into the software, or they have a already setup job to enter the 
new serial(s)?  I know I would have it set up if it were me. 

This also has nothing to do with the question, but I have always thought that 
the vendor should be compensated for support of the DR testing anyway.  (this 
will probably cause a lot of angry responses).  It's a separate processor and 
the vendor has to support a problem that might occur on it just like they would 
if it were the primary processor, which may not have the issue.  If that were 
the case, then the vendor has to support your DR test for free.  Now if you are 
paying $50k for the software, it's probably a reasonable expectation, but if 
you are paying $2K to $5K it's not as reasonable.   

I received an email between my last response and this one that said (a lot of 
things, but basically) that many sites (the grater percentage) don't know what 
they pay for their software because a) it's done by another department or their 
boss, or b) they only think about it when they first license the product and 
don't think about the cost involved until they either run low on budget and are 
trying to save some amount or they have a problem that makes them unhappy with 
the product that they are currently paying for. 

Is that true across the board with you people? 

Brian 


On Thu, 29 Dec 2011 17:39:58 -0500, Scott Ford  wrote: 

>ZMan I am pretty well versed in pc/unix/mf and learning Appleseed... 
>Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
>product patches,etc for new CPUs.. 
> 
>Sent from my iPad 
> 
>On Dec 29, 2011, at 2:40 PM, zMan  wrote: 
> 
>> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote: 
>>> As A vendor I understand the CPU/serial situation but one has to consider 
>>> the less than honest customers and 'yes' I have experience that also 
>>> 
>>> Sent from my iPad 
>> 
>> ...points to the liabilities of communicating using mobile devices? :-) 
>> -- 
>> zMan -- "I've got a mainframe and I'm not afraid to use it" 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 
> 
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send emai

Re: cpu / machine identification

[John McKown]

On Thu, 2011-12-29 at 21:08 -0600, John McKown wrote:
> Depends on what they want to do. HIPAA is a big deal in my shop. If they
> just want SMF data, I normally run the job to create the dataset for
> them and send it to them. No big deal about that. If they want a
> "sysprog" level access (which has never happened), well, I'll do what
> I'm told. But if it were me, I'd tell them to get a court order, siting
> HIPAA. And get lots of legal documents signed by somebody like the
> president or other high officer of the company. Maybe even many
> somebodies.
> 
sed 's/siting/citing/g' 
> 
-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[John McKown]

We do our DR under z/VM. But we don't ask that the serial number be
altered. Unless otherwise specified in the VM guest definition, the CPU
serial number presented to z/OS is the hardware CPUID.

IIRC, you can tell z/VM to emulate the serial number, but not the
machine type. I.e. if you run on a z9BC at home, and a z10EC at DR, the
machine type will still be a z10EC even if the CPUID is changed. Again,
going by old memory, this is due to the differences in hardware
recovery.

On Thu, 2011-12-29 at 20:42 -0600, Brian Westerman wrote:
> We have  DR support in our software, but I was under the impression
> that most of the DR sites were running the OS under VM and they
> simulated the serial anyway.
> 
> I suppose their are sites that do not run the DR under VM, but don't
> the sites who don't run under VM know the serial number ahead of time,
> and wouldn't it be already built into the software, or they have a
> already setup job to enter the new serial(s)?  I know I would have it
> set up if it were me.
> 
> This also has nothing to do with the question, but I have always
> thought that the vendor should be compensated for support of the DR
> testing anyway.  (this will probably cause a lot of angry responses).
> It's a separate processor and the vendor has to support a problem that
> might occur on it just like they would if it were the primary
> processor, which may not have the issue.  If that were the case, then
> the vendor has to support your DR test for free.  Now if you are
> paying $50k for the software, it's probably a reasonable expectation,
> but if you are paying $2K to $5K it's not as reasonable.  
> 
> I received an email between my last response and this one that said (a
> lot of things, but basically) that many sites (the grater percentage)
> don't know what they pay for their software because a) it's done by
> another department or their boss, or b) they only think about it when
> they first license the product and don't think about the cost involved
> until they either run low on budget and are trying to save some amount
> or they have a problem that makes them unhappy with the product that
> they are currently paying for.
> 
> Is that true across the board with you people?
> 
> Brian
> 
> 
> On Thu, 29 Dec 2011 17:39:58 -0500, Scott Ford  wrote:
> 
> >ZMan I am pretty well versed in pc/unix/mf and learning Appleseed...
> >Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
> >product patches,etc for new CPUs..
> >
> >Sent from my iPad
> >
> >On Dec 29, 2011, at 2:40 PM, zMan  wrote:
> >
> >> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  
> >> wrote:
> >>> As A vendor I understand the CPU/serial situation but one has to consider 
> >>> the less than honest customers and 'yes' I have experience that also
> >>>
> >>> Sent from my iPad
> >>
> >> ...points to the liabilities of communicating using mobile devices? :-)
> >> --
> >> zMan -- "I've got a mainframe and I'm not afraid to use it"
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[John McKown]

On Thu, 2011-12-29 at 20:32 -0600, Brian Westerman wrote:
> I didn't realize that a employee can bind the site, but I can see where that 
> might actually be the case.
> 
> I can imagine what would happen to a site like IBM in Dallas, should
> Microsoft or Corel say, "we're coming on Tuesday to check every one of
> your machines".  That would be very interesting.
> 
> Brian
> 

Reminds me vaguely of an internal auditor who wanted access to the z/OS
system in order to verify that it was not compromised by Windows
viruses. Was incensed that z/OS did not have any virus scanning software
installed. Literally __could not__ understand why a Windows virus
couldn't infect the mainframe. "software is software" and "a system is a
system". Didn't understand that the z wasn't Intel compatible. Complete
IT idiot. 

-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

We have  DR support in our software, but I was under the impression that most 
of the DR sites were running the OS under VM and they simulated the serial 
anyway.

I suppose their are sites that do not run the DR under VM, but don't the sites 
who don't run under VM know the serial number ahead of time, and wouldn't it be 
already built into the software, or they have a already setup job to enter the 
new serial(s)?  I know I would have it set up if it were me.

This also has nothing to do with the question, but I have always thought that 
the vendor should be compensated for support of the DR testing anyway.  (this 
will probably cause a lot of angry responses).  It's a separate processor and 
the vendor has to support a problem that might occur on it just like they would 
if it were the primary processor, which may not have the issue.  If that were 
the case, then the vendor has to support your DR test for free.  Now if you are 
paying $50k for the software, it's probably a reasonable expectation, but if 
you are paying $2K to $5K it's not as reasonable.  

I received an email between my last response and this one that said (a lot of 
things, but basically) that many sites (the grater percentage) don't know what 
they pay for their software because a) it's done by another department or their 
boss, or b) they only think about it when they first license the product and 
don't think about the cost involved until they either run low on budget and are 
trying to save some amount or they have a problem that makes them unhappy with 
the product that they are currently paying for.

Is that true across the board with you people?

Brian


On Thu, 29 Dec 2011 17:39:58 -0500, Scott Ford  wrote:

>ZMan I am pretty well versed in pc/unix/mf and learning Appleseed...
>Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
>product patches,etc for new CPUs..
>
>Sent from my iPad
>
>On Dec 29, 2011, at 2:40 PM, zMan  wrote:
>
>> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote:
>>> As A vendor I understand the CPU/serial situation but one has to consider 
>>> the less than honest customers and 'yes' I have experience that also
>>>
>>> Sent from my iPad
>>
>> ...points to the liabilities of communicating using mobile devices? :-)
>> --
>> zMan -- "I've got a mainframe and I'm not afraid to use it"
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

I didn't realize that a employee can bind the site, but I can see where that 
might actually be the case.

I can imagine what would happen to a site like IBM in Dallas, should Microsoft 
or Corel say, "we're coming on Tuesday to check every one of your machines".  
That would be very interesting.

Brian

 On Thu, 29 Dec 2011 14:47:21 -0500, Tony Harminc  wrote:

>On 28 December 2011 20:58, Brian Westerman
> wrote:
>> I don't mean to be flippant, but I seriously almost spit my diet coke all 
>> over my screen when I read the previous reply about allowing the software 
>> company to audit their system. :)
>>
>> I really don't think any site would readily agree to have their site 
>> "audited" by a software company for compliance.
>>
>> It sounds good to say that, but in reality I really really doubt that anyone 
>> at just about any site would agree to it.  I can just imagine the dead 
>> silence that would happen when a marketing person says "oh yeh, and we will 
>> be here in sometime during the year and audit all of your CPU's and LPARs to 
>> make sure we can "really" trust you".
>>
>> After the silence, the sale would disappear. :)
>>
>> Please don't take offense with my response.  It just took me by surprise.
>
>I've seen Fortune 500 companies happily sign mainframe software
>contracts with vendor written auditing provisions; others who[se
>lawyers] routinely snipped out the auditing paragraph without comment,
>and others who negotiated the details.
>
>BTW, a number of popular desktop software products from well known
>vendors have audit clauses in the click-through licence agreement.
>Usually corporate Contracts doesn't see those, and it's less than
>clear if the individual employee can bind the company by clicking
>Accept.
>
>I've also seen what happened when a vendor tried to do an audit -
>consisting of asking for a subset of SMF records - on a random set of
>customers, some with audit clauses and some without, and for the most
>part it wasn't pleasant in either case.
>
>Tony H.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Sorry,

I found out that the quote is not on by default (the hard way :)) and also that 
I have to click on it BEFORE I enter any data.

I was answering a response that stated that if a site has a site license, that 
there should be no constraints on the code, but I wanted to point out that not 
all sites license the code for the entire site (some is for a single CPU or 
LPAR), and that there is no protection against the software becoming part of 
some systems programmer's goodie bag when he/she moves to the next site.  You 
can limit by date, that also doesn't provide proper protections.

I had wanted to point out that people lock their cars, even when they have the 
only key.  There are people that even lock their car in their own garage.  It's 
more work to unlock the car, but they do it anyway.  If you take your car to 
the shop to be worked on and park it in their lot, do you lock it?  Do they 
lock it when they are done?

When you take your key out of the ignition, the steering wheel locks in place.  
You can't turn the wheel without inserting your key, some people see that as a 
safety feature, others as a anti-theft feature, some people break the 
inter-lock that controls that "feature".  The safety and anti-theft parts have 
long since been rendered useless because of the technology in the cars computer 
circuitry, but if a car was shipped without the "feature" most people would see 
that as a defect and take it back to be fixed.

Actually reading back on the previous paragraph, it gets more away from the 
point than I wanted to be, but I'll leave it anyway because (while really 
tangential), it makes a point that I wanted to get to which is that the extra 
work required for something, in this case the maintenance of the keys for 
software at the site, is a bummer, but is also necessary because there are some 
sites (and some people) who will just not follow directions or abide by the 
rules and you cannot reasonably expect the vendor to take all the risk.  

Small vendors might know all of their clients personally and know if they can 
trust them with their code, frankly, if they do then they probably don't have 
very many clients.

A company like IBM or CA, who makes billions a year, can afford to be lax on 
control of their software (although CA isn't really that lax), and they up the 
price to everyone to make up for the "possibility" that someone isn't paying.  
The software has long since paid for itself and in many cases, there is other 
software that is better and cheaper, but people still see them as the first 
choice.  I'm not sure why, maybe it's like with a car, you wouldn't buy a car 
from Chevrolet and get the doors from Ford, even if Ford has a better door that 
fits perfectly.  It probably has nothing to do with that, but I honestly don't 
know why it is.

Our automation software is years ahead of IBM and CA's, and theirs cost 90 to 
95% more, but they still have the biggest market shares in automation software. 
 I don't know why, marketing might have something to do with it, but it's not 
like you see big marketing pushes for their automation software anywhere so I 
just don't know why it is.

The one thing I do know is that vendors have the right to protect their 
software and as long as it's reasonable protection, I don't see why a site 
would complain about it.  Most sites do not complain, but obviously some do, 
that's what started the thread after the person who entered the original 
request asked for comments.

Brian

 On Thu, 29 Dec 2011 15:02:14 +, Pommier, Rex R. 
 wrote:

>Brian,
>
>I see your point, but have a request for you.  Don't get quite so aggressive 
>with the electronic scissors on snipping away the context.  The beginning of 
>your comment below says it all - "That works...".  What's "that"?  Since there 
>have been several comments/points of view made, it would be much easier to 
>leave the comment you are replying to in your reply.
>
>Not trying to be flippant, mind you.  :-)
>
>Rex
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
>Brian Westerman
>Sent: Wednesday, December 28, 2011 8:02 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: cpu / machine identification
>
>That works for a site license and I agree with it for that type of license, 
>but what about sites that purchase a single processor license and have 4 
>processors, or a systems programmer that decides that he can fix his "friends" 
>problem by sending a copy of the code to them, or the one that decides to post 
>the code on facebook.  (I reaching with the facebook thing, but hopefully you 
>see my point).
>
>Brian
>
>

Re: cpu / machine identification

[Brian Westerman]

I'm sorry Schmuel, normally I agree with your point on things, but I really 
have to disagree here.  It's not like I have no experience with other sites, we 
have hundreds of clients, and I have been to well over 80% of them in person, 
and I can state without much worry that the percentages would not be on my side 
that the far greater percentage (approaching 100%) would never agree to giving 
a vendor access to their site to "check up" on them.

Even when we go to a site as the "IBM" people, they go way out of their way to 
make sure that we stay focused on the problem and don't just "look around".  As 
a "non IBM" vendor, it would be even less likely that the client would just 
open their site to us.

In this case I hardily agree with the view that the the vendor would be told to 
go pound salt.  Imagine the security issues that would have to be dealt with to 
just give them an ID that has the capability to check.  

Brian


On Thu, 29 Dec 2011 05:02:06 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <7026723933836234.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>12/28/2011
>   at 07:58 PM, Brian Westerman  said:
>
>>I really don't think any site would readily agree to have their site
>>"audited" by a software company for compliance.
>
>Why not?
>
>>After the silence, the sale would disappear. :)
>
>Perhaps at your site.
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Another test,

Okay, it appears that I have to click on the quote on the bottom right BEFORE I 
type anything here, so now I think I have it right.  Is there a way to turn on 
Quoting as a default?

Brian

On Thu, 29 Dec 2011 19:36:49 -0600, Brian Westerman 
 wrote:

>Sorry about that, I was sure that the original messages were appended, but I 
>am obviously wrong.  I think I probably just clicked on the send message 
>without pressing the quote first.
>
>Sorry again,
>
>Brian
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification - testing quote

[Brian Westerman]

This is a test to see if I am getting the quote by pressing the quote button at 
the bottom right

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

This is a test to see if the quote button on the bottom right is working.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

Sorry about that, I was sure that the original messages were appended, but I am 
obviously wrong.  I think I probably just clicked on the send message without 
pressing the quote first.

Sorry again,

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Scott Ford]

ZMan I am pretty well versed in pc/unix/mf and learning Appleseed...
Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
product patches,etc for new CPUs..

Sent from my iPad

On Dec 29, 2011, at 2:40 PM, zMan  wrote:

> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote:
>> As A vendor I understand the CPU/serial situation but one has to consider 
>> the less than honest customers and 'yes' I have experience that also
>> 
>> Sent from my iPad
> 
> ...points to the liabilities of communicating using mobile devices? :-)
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Tony Harminc]

On 28 December 2011 20:58, Brian Westerman
 wrote:
> I don't mean to be flippant, but I seriously almost spit my diet coke all 
> over my screen when I read the previous reply about allowing the software 
> company to audit their system. :)
>
> I really don't think any site would readily agree to have their site 
> "audited" by a software company for compliance.
>
> It sounds good to say that, but in reality I really really doubt that anyone 
> at just about any site would agree to it.  I can just imagine the dead 
> silence that would happen when a marketing person says "oh yeh, and we will 
> be here in sometime during the year and audit all of your CPU's and LPARs to 
> make sure we can "really" trust you".
>
> After the silence, the sale would disappear. :)
>
> Please don't take offense with my response.  It just took me by surprise.

I've seen Fortune 500 companies happily sign mainframe software
contracts with vendor written auditing provisions; others who[se
lawyers] routinely snipped out the auditing paragraph without comment,
and others who negotiated the details.

BTW, a number of popular desktop software products from well known
vendors have audit clauses in the click-through licence agreement.
Usually corporate Contracts doesn't see those, and it's less than
clear if the individual employee can bind the company by clicking
Accept.

I've also seen what happened when a vendor tried to do an audit -
consisting of asking for a subset of SMF records - on a random set of
customers, some with audit clauses and some without, and for the most
part it wasn't pleasant in either case.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote:
> As A vendor I understand the CPU/serial situation but one has to consider the 
> less than honest customers and 'yes' I have experience that also
>
> Sent from my iPad

...points to the liabilities of communicating using mobile devices? :-)
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Scott Ford]

As A vendor I understand the CPU/serial situation but one has to consider the 
less than honest customers and 'yes' I have experience that also

Sent from my iPad

On Dec 29, 2011, at 10:02 AM, "Pommier, Rex R."  
wrote:

> Brian,
> 
> I see your point, but have a request for you.  Don't get quite so aggressive 
> with the electronic scissors on snipping away the context.  The beginning of 
> your comment below says it all - "That works...".  What's "that"?  Since 
> there have been several comments/points of view made, it would be much easier 
> to leave the comment you are replying to in your reply.
> 
> Not trying to be flippant, mind you.  :-)
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Brian Westerman
> Sent: Wednesday, December 28, 2011 8:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: cpu / machine identification
> 
> That works for a site license and I agree with it for that type of license, 
> but what about sites that purchase a single processor license and have 4 
> processors, or a systems programmer that decides that he can fix his 
> "friends" problem by sending a copy of the code to them, or the one that 
> decides to post the code on facebook.  (I reaching with the facebook thing, 
> but hopefully you see my point).
> 
> Brian
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> The information contained in this e-mail may contain confidential and/or 
> privileged information and is intended for the sole use of the intended 
> recipient. If you are not the intended recipient, you are hereby notified 
> that any unauthorized use, disclosure, distribution or copying of this 
> communication is strictly prohibited and that you will be held responsible 
> for any such unauthorized activity, including liability for any resulting 
> damages. As appropriate, such incident(s) may also be reported to law 
> enforcement. If you received this e-mail in error, please reply to sender and 
> destroy or delete the message and any attachments. Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Pommier, Rex R.]

Brian,

I see your point, but have a request for you.  Don't get quite so aggressive 
with the electronic scissors on snipping away the context.  The beginning of 
your comment below says it all - "That works...".  What's "that"?  Since there 
have been several comments/points of view made, it would be much easier to 
leave the comment you are replying to in your reply.

Not trying to be flippant, mind you.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Brian Westerman
Sent: Wednesday, December 28, 2011 8:02 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: cpu / machine identification

That works for a site license and I agree with it for that type of license, but 
what about sites that purchase a single processor license and have 4 
processors, or a systems programmer that decides that he can fix his "friends" 
problem by sending a copy of the code to them, or the one that decides to post 
the code on facebook.  (I reaching with the facebook thing, but hopefully you 
see my point).

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <7026723933836234.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/28/2011
   at 07:58 PM, Brian Westerman  said:

>I really don't think any site would readily agree to have their site
>"audited" by a software company for compliance.

Why not?

>After the silence, the sale would disappear. :)

Perhaps at your site.  
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Count your fingers ... was cpu / machine identification

[Shane]

> I know of people that don't lock their cars ...

I never lock mine, and leave the windows down a few inches.
My German Shepherd needs fresh air in this climate. Anyone stupid
enough to put their hand in deserves all they get. The mutt is friendly
but slightly territorial.
Never had anything nicked, although am often met by people who want
to pat the fella.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

SV: cpu / machine identification

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> Brian Westerman
> Skickat: den 29 december 2011 03:10
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: cpu / machine identification
> 
... 
> I'm sure you lock your car, why do that if you have the only key?  :)
> 
> Brian

I know of people that don't lock their cars - to avoid damage if someone wants 
to get into the car. 
 

 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Robert A. Rosenberg]

At 20:10 -0600 on 12/28/2011, Brian Westerman wrote about Re: cpu / 
machine identification:


That's a good point, our code does put out the message at startup 
about the site it's licensed to.  But if someone was going to run it 
purposely and not pay, zapping the one instance of the name is not 
as hard as changing every page of a 300 page book.


That (Zapping the Registered Licensee Field) is not that hard to work 
check for. You do a check sum on the field and spot when it has been 
done. The routine to do this does not need to be hard coded but can 
be built on the fly as the the program executes. The same built on 
the fly code can also issue the ID message if the original field has 
been hacked. The use of built on the fly code and placing the result 
in a STORAGE acquired area makes it harder to find an circumvent (the 
actual build code is hidden by being interleaved in normal code that 
needs to run not as a simple block of code that can be bypassed by a 
zapped in branch).


I have seen this type of code in commercial products that I was 
responsible for developing and maintaining so I know it can and has 
been done. It is simple "Just In Time" type compilation.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shane]

On Wed, 28 Dec 2011 21:51:42 -0500 zMan wrote:


 
> Without any quoting, it's hard to tell what you're replying to...not
> trying to restart the quoting wars, but *some* reference is useful.

Absolutely agree. Normally I like to read Brians opinions, but those
last few just got unilaterally deleted.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

On Wed, Dec 28, 2011 at 9:02 PM, Brian Westerman
 wrote:
> That works for a site license and I agree with it for that type of license, 
> but what about sites that purchase a single processor license and have 4 
> processors, or a systems programmer that decides that he can fix his 
> "friends" problem by sending a copy of the code to them, or the one that 
> decides to post the code on facebook.  (I reaching with the facebook thing, 
> but hopefully you see my point).

Without any quoting, it's hard to tell what you're replying to...not
trying to restart the quoting wars, but *some* reference is useful.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

That works for a site license and I agree with it for that type of license, but 
what about sites that purchase a single processor license and have 4 
processors, or a systems programmer that decides that he can fix his "friends" 
problem by sending a copy of the code to them, or the one that decides to post 
the code on facebook.  (I reaching with the facebook thing, but hopefully you 
see my point).

Brian  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

That's a good point, our code does put out the message at startup about the 
site it's licensed to.  But if someone was going to run it purposely and not 
pay, zapping the one instance of the name is not as hard as changing every page 
of a 300 page book.

The licensing scheme isn't to make life hard for the normal user, it's to 
protect the product from the "bad guys".  

I'm sure you lock your car, why do that if you have the only key?  :)

Brian 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

We have our products tell how long they are licensed for (how much time is 
left) on each startup.  When it gets within 45 days we make it highlighted (but 
still rolls off the screen), then at 15 days it stays on the screen.  Then when 
it expires, we still have a "grace" period, that varies with the product and 
the site.  It's a little more work, but only has to be done once (when it 
starts up) and then sets bits that can be checked periodically for the "always 
up" products so that they don't have to do anything but compare once a day or 
so.  The overhead is extremely minimal, and we have not had complaints about 
the intrusiveness of the messages.

We don't like having that code at all, but unfortunately have been bitten in 
the past with sites that "forgot" to pay and ignore our requests for payment.  
there are two of them are still running the code from over 8 years ago (for 
free) and one of them actually asked us for a "update" to the newer version, 
but didn't want to move to it because it had the built-in expiration.  I guess 
that you could consider it a "lost" sale, but the alternative is that they just 
continue to run the old code (which is far less capable) for free.

So, while most sites are honest and would never consider running unpaid code, 
there are some (although very few) that don't care.  

The sad part is that we price our code low enough that any site can run it and 
save a lot of money over the cost of IBM's or CA's (etc.) code, and we even 
offer a further discount for the IBM-Main and Share members, but we still get 
calls from sites that are upgrading their OS and find that they are running our 
code and did not know it.  Sometimes it's carried there by migrating sysprogs, 
and sometimes the code was zapped to get around the checking.  Normally, they 
become customers, but sometimes (when we send them information on the cost) 
they simply disappear.  

There are sites paying tens of thousands to run IBM's or CA's automation 
products and don't blink at the cost, our customer base is more concerned about 
the overall cost and feature sets (we have more features at a MUCH lower cost, 
on the order of 2% to 5% of the cost for "theirs").  Those sites tend to tell 
us they are expiring soon (well before the 45 day reminder starts), and it 
works out well for all involved.

We have moved to 100% electronic delivery of invoices, and we were able to 
reduce our product costs even more because of the savings in people costs.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

I don't mean to be flippant, but I seriously almost spit my diet coke all over 
my screen when I read the previous reply about allowing the software company to 
audit their system. :)

I really don't think any site would readily agree to have their site "audited" 
by a software company for compliance.  

It sounds good to say that, but in reality I really really doubt that anyone at 
just about any site would agree to it.  I can just imagine the dead silence 
that would happen when a marketing person says "oh yeh, and we will be here in 
sometime during the year and audit all of your CPU's and LPARs to make sure we 
can "really" trust you".

After the silence, the sale would disappear. :)

Please don't take offense with my response.  It just took me by surprise.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In
,
on 12/26/2011
   at 11:22 AM, Sam Siegel  said:

>Please feel free to treat this as an open ended question related to
>licensing mechanism and provided any related advice and tips based on
>experience.

Whatever mechanism you use should take into account that the user
might have to run at a DR site and that he might have to run
calendar-related code with a date other than the current date. Also,
the code should be airtight and should err on the side of giving
permission; I can think of few better ways to lose a customer than to
have a product he paid for refuse to run because of a bug in the
licensing code.

A stickier question is what you want to do about customers who are
late renewing. Some government sites are always overdue. I know that
SAS Institute cuts them some slack; I'm not sure about other vendors.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Ed Finnell]

Dongle me this Imperial Leader...
 
 
In a message dated 12/27/2011 3:03:49 P.M. Central Standard Time,  
m...@mzelden.com writes:

Oh, the  stories I could tell


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Martin Packer]

This does raise the issue of WIBNI there was some way for an installation 
to name a machine? When I refer to a customer machine - because of what I 
get from SMF / RMF it's usually Plant/Serial as "xx-x". Most of my 
customers have other names for their machines.

Cheers, Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Sam Siegel]

All - Thanks for the huge response both on-list and off-list.  I've gotten
both business and technical details.  Exactly the type of information that
I was looking for.

THANKS AGAIN!

I'm especially happy to see that the signal-to-noise ratio is extremely
high!

I'm post some follow up question after I digest all of this input.

Cheers,
Sam

On Tue, Dec 27, 2011 at 12:06 PM, Mark Zelden  wrote:

> On Tue, 27 Dec 2011 11:14:47 -0800, Skip Robinson <
> jo.skip.robin...@sce.com> wrote:
>
> >Software 'keys' are a huge PITA for reasons not so far mentioned.
> >
> >-- In larger shops, software contracts are often managed exclusively by
> >bean-counter types far removed from the sysprogs who have to implement the
> >keys. When a product threatens to self destruct--or actually does so--the
> >responsible sysprog can got caught in the middle of a negotiation
> >shoot-out. Most vendors are kind enough to supply a 'temporary extension'
> >key while the lawyers mud wrestle. (It's not as sexy as you might imagine.
> >Or maybe it is.) The dire messages flying across the console--even
> >appearing in a user's joblog--are tawdry testament to our inability to
> >just get along.
> >
>
> I did mention this, but you had to read in-between the lines a little
> "it's easy for the "techies" to make mistakes since they often (usually?)
> don't know the T's and C's of all the software contracts. "
>
> >-- While most vendors these days supply their products to be (at least
> >optionally) installed with SMPE, they all view themselves as sole guardian
> >priests of the divine software protection sword. Each vendor's incarnation
> >of this sword is unique to that vendor or even specific product. This
> >creates a dependency on individual SMEs who must be engaged to implement
> >and promulgate a new key. Vacation and holiday schedules only complicate
> >this monster dance.
> >
> >I'm with Barry. Dispense with keys. Trust your customers. The potential
> >cost of a legal hassle should be enough to keep customers on the line. Or
> >close enough.
> >
>
> I have to come to the defense of one of my client's again here.  While
> the legal hassles and expense may not be a big deal for IBM and large
> ISVs like CA, BMC and others, most large companies have far deeper
> pockets than my client and the CPU protection is far more cost effective
> than having to fight it out in court.   That probably holds true for many
> of the smaller ISVs and certainly the ones that are pretty much a
> one or 2 man show.   Dave Cole's XDC comes to mind here (I haven't
> installed XDC in about 10 years, does it require a key?).
>
> Barry's MXG is the exception to the rule.  As he mentioned, it is all
> source
> code and probably is the best deal on the planet in terms of cost and
> maintenance.  :-)
>
> I am a sysprog... and agree with what you and others have said about
> what a huge PITA it is to deal with keys.  Believe me, I know.  I spend
> most of my time supporting a very large environment with many z196s
> and over 30 production LPARs supporting multiple companies.   But
> I completely understand a vendor's reason for doing whatever they want
> or must do to protect their intellectual property from either accidental
> or intentional misuse when putting food on their table depends on it.
> The honor system doesn't really work much better in the 21st century
> mainframe environment than it does (did) for software installed on your PC.
> Oh, the stories I could tell
>
> Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Mark Zelden]

On Tue, 27 Dec 2011 11:14:47 -0800, Skip Robinson  
wrote:

>Software 'keys' are a huge PITA for reasons not so far mentioned.
>
>-- In larger shops, software contracts are often managed exclusively by
>bean-counter types far removed from the sysprogs who have to implement the
>keys. When a product threatens to self destruct--or actually does so--the
>responsible sysprog can got caught in the middle of a negotiation
>shoot-out. Most vendors are kind enough to supply a 'temporary extension'
>key while the lawyers mud wrestle. (It's not as sexy as you might imagine.
>Or maybe it is.) The dire messages flying across the console--even
>appearing in a user's joblog--are tawdry testament to our inability to
>just get along.
>

I did mention this, but you had to read in-between the lines a little
"it's easy for the "techies" to make mistakes since they often (usually?)
don't know the T's and C's of all the software contracts. "  

>-- While most vendors these days supply their products to be (at least
>optionally) installed with SMPE, they all view themselves as sole guardian
>priests of the divine software protection sword. Each vendor's incarnation
>of this sword is unique to that vendor or even specific product. This
>creates a dependency on individual SMEs who must be engaged to implement
>and promulgate a new key. Vacation and holiday schedules only complicate
>this monster dance.
>
>I'm with Barry. Dispense with keys. Trust your customers. The potential
>cost of a legal hassle should be enough to keep customers on the line. Or
>close enough.
>

I have to come to the defense of one of my client's again here.  While
the legal hassles and expense may not be a big deal for IBM and large
ISVs like CA, BMC and others, most large companies have far deeper
pockets than my client and the CPU protection is far more cost effective
than having to fight it out in court.   That probably holds true for many
of the smaller ISVs and certainly the ones that are pretty much a 
one or 2 man show.   Dave Cole's XDC comes to mind here (I haven't
installed XDC in about 10 years, does it require a key?).

Barry's MXG is the exception to the rule.  As he mentioned, it is all source 
code and probably is the best deal on the planet in terms of cost and
maintenance.  :-)   

I am a sysprog... and agree with what you and others have said about
what a huge PITA it is to deal with keys.  Believe me, I know.  I spend
most of my time supporting a very large environment with many z196s
and over 30 production LPARs supporting multiple companies.   But 
I completely understand a vendor's reason for doing whatever they want
or must do to protect their intellectual property from either accidental 
or intentional misuse when putting food on their table depends on it.  
The honor system doesn't really work much better in the 21st century
mainframe environment than it does (did) for software installed on your PC.  
Oh, the stories I could tell

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Rob Scott
> Sent: Tuesday, December 27, 2011 1:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: cpu / machine identification
> 
> Sam
> 
> I would suggest a license key based on company/product  name 
> and date *only*.
> 
> CPUid schemes are such a PITA to administer for both customer 
> and vendor.
> 
> Using expiration dates and sufficiently load warning messages 
> (eg WTOs, prompts in the UI) as the expiration date 
> approaches keeps 99.99% of customers paying the bill on time.
>   
> 
> Rob Scott

I like what one publisher of epubs has done. I order a book from them. I get a 
URL to download a PDF. There is no DRM on the PDF. But my name is on the footer 
of every page. Yes, I know how to erase it, if I really wanted to. For 
software, I think some sort of header with a "whistleblower" address might be 
interesting. Nothing like a disgrunted employee to "stick to the company" if 
they can.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Rob Scott]

Sam

I would suggest a license key based on company/product  name and date *only*.

CPUid schemes are such a PITA to administer for both customer and vendor.

Using expiration dates and sufficiently load warning messages (eg WTOs, prompts 
in the UI) as the expiration date approaches keeps 99.99% of customers paying 
the bill on time.
  

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Sam Siegel
Sent: 26 December 2011 21:20
To: IBM-MAIN@bama.ua.edu
Subject: Re: cpu / machine identification

zMan - Thanks for the reply.  It is a new product - No customers yet.

I would like enough licensing to keep honest people honest and an operationally 
oriented reminder for the annual renewal.

Sam

On Mon, Dec 26, 2011 at 1:11 PM, zMan  wrote:

> Gahh, "IF BibBox, Inc".
>
> On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:
> > On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:
> >> Hello List - I'm attempting to create a licensing mechanism for a 
> >> bit of software.  I would like to be able to use a unique and 
> >> non-modifiable identifier as part of the mechanism.
> >>
> >> The CSRSI callable service and STSI instruction provide a variety 
> >> of hardware related identifiers.
> >>
> >> CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.
>  These
> >> appear directly related to PCCACPID (PCCA control block) and 
> >> Sequence
> Code
> >> (STSI basic machine configuration)..
> >>
> >> Is there any preference to using one field over the other?  What 
> >> are the advantages and disadvantages of using each field?
> >>
> >> Are there other fields (in same or other control blocks) that 
> >> should be used?
> >>
> >> Please feel free to treat this as an open ended question related to 
> >> licensing mechanism and provided any related advice and tips based 
> >> on experience.
> >
> > OK, I gotta ask -- what's the problem you're trying to solve? You 
> > don't trust your customers? In over a quarter century in the 
> > mainframe software business, I've come across ONE customer running 
> > software on an unlicensed box, and it was an oversight -- and a nice 
> > full-price bluebird for the sales rep. I don't believe "CPUIDs" are 
> > worth the hassle.
> >
> > Having said that, I would expect that any CPUID processing would 
> > work off, well, the CPUID. That's what customers understand.
> >
> > SAS Institute used to have a nice CPUID system for their C compiler 
> > that would issue a warning and print out what company the sucker was 
> > licensed to, but would continue to operate if the CPUID was wrong.
> > This allowed emergency operation, while clearly keeping any real 
> > company from running it on the wrong box (though I suppose of 
> > BigBox, Inc. licensed it on one and ran it on two, it would be 
> > harder to notice; the case I'm thinking of was when we were running 
> > the Merrill-Lynch copy on another company's machine, WITH permission 
> > from SAS; every time we invoked the compiler, it would whine and say 
> > "Licensed to Merrill-Lynch").
> >
> > Now, with systems management stuff that doesn't have a real UI that 
> > gets invoked all the time, it's harder. The best I've seen allowed:
> > - multiple key entries in the CPUID file, so you didn't have to 
> > worry about swapping files at expiration: you just added new entries 
> > and eventually deleted the old ones. And you could keep all your 
> > CPUIDs in a common file, shared (or replicated) across systems.
> > - Warned starting 30 days before expiration, on the operator's
> > console: "XYZ will expire in 30 days" (29, 28...).
> > - If it had a valid license (i.e., one with time on it but on the 
> > wrong machine) would run in "emergency mode", whining on the 
> > operator's console every 10 minutes or so, but still running (this 
> > allowed for DR).
> > - Supported "universal" temporary keys, that could be 
> > read/emailed/FAXed by support at 3AM if you really screwed up and 
> > were dead in the water despite the above.
> >
> > Now, this also meant that there were folks carrying beepers and temp 
> > keys, so they could do that after-hours support.
> >
> > Are you prepared to deal with all this? Is it worth it?
>

Re: cpu / machine identification

[Skip Robinson]

Software 'keys' are a huge PITA for reasons not so far mentioned. 

-- In larger shops, software contracts are often managed exclusively by 
bean-counter types far removed from the sysprogs who have to implement the 
keys. When a product threatens to self destruct--or actually does so--the 
responsible sysprog can got caught in the middle of a negotiation 
shoot-out. Most vendors are kind enough to supply a 'temporary extension' 
key while the lawyers mud wrestle. (It's not as sexy as you might imagine. 
Or maybe it is.) The dire messages flying across the console--even 
appearing in a user's joblog--are tawdry testament to our inability to 
just get along. 

-- While most vendors these days supply their products to be (at least 
optionally) installed with SMPE, they all view themselves as sole guardian 
priests of the divine software protection sword. Each vendor's incarnation 
of this sword is unique to that vendor or even specific product. This 
creates a dependency on individual SMEs who must be engaged to implement 
and promulgate a new key. Vacation and holiday schedules only complicate 
this monster dance.

I'm with Barry. Dispense with keys. Trust your customers. The potential 
cost of a legal hassle should be enough to keep customers on the line. Or 
close enough. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   zMan 
To: IBM-MAIN@bama.ua.edu
Date:   12/27/2011 10:43 AM
Subject:Re: cpu / machine identification
Sent by:IBM Mainframe Discussion List 



On Tue, Dec 27, 2011 at 8:55 AM, Mark Zelden  wrote:
> Obviously the point of view of someone who doesn't make a living by
> selling their software.

Au contraire, I sure do make my living selling software. My point is
that in my experience, the cost of fighting the CPUID battle isn't
worth it. The counterexamples cited are pathological -- given a CPUID,
such shops would just hack it (not that hard, no matter what anyone
says). The expired SAS shop Barry cites is another example of someone
going around it.

I just don't see the point.

FWIW, I've never had to live with the customer end of CPUIDs -- only
the vendor end. But I fail to see how they would ever be seen as a
boon by customers.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Mark Jacobs]

I'm a customer, with many products requiring CPU codes and other 
software based licensing schemes, and they are a PITA.


   * Every vendor does it differently.
   * Detailed documentation needs to be written and maintained for both
 DR situations and CPU push/pull activities.
   * Whenever we do a CPU push/pull it usually takes us weeks if not
 months for all the vendors to supply us with new permanent license
 codes, while in the mean time we're using temporary codes that
 have to be gotten and applied, with all the change control
 activities associated with that process.

If it up to me and I had a choice between two products, one with an 
software licensing mechanism, and one without, but with the legal right 
to perform audits in my environment I'd pick the second vendor almost 
all the time.


Mark Jacobs


On 12/27/11 13:40, zMan wrote:

On Tue, Dec 27, 2011 at 8:55 AM, Mark Zelden  wrote:
   

Obviously the point of view of someone who doesn't make a living by
selling their software.
 

Au contraire, I sure do make my living selling software. My point is
that in my experience, the cost of fighting the CPUID battle isn't
worth it. The counterexamples cited are pathological -- given a CPUID,
such shops would just hack it (not that hard, no matter what anyone
says). The expired SAS shop Barry cites is another example of someone
going around it.

I just don't see the point.

FWIW, I've never had to live with the customer end of CPUIDs -- only
the vendor end. But I fail to see how they would ever be seen as a
boon by customers.
   

--
Mark Jacobs
Time Customer Service
Tampa, FL


One of life's greatest mysteries is how the boy who
wasn't good enough to marry your daughter can be the
father of the smartest grandchild in the world.

Yiddish Proverb

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

On Tue, Dec 27, 2011 at 8:55 AM, Mark Zelden  wrote:
> Obviously the point of view of someone who doesn't make a living by
> selling their software.

Au contraire, I sure do make my living selling software. My point is
that in my experience, the cost of fighting the CPUID battle isn't
worth it. The counterexamples cited are pathological -- given a CPUID,
such shops would just hack it (not that hard, no matter what anyone
says). The expired SAS shop Barry cites is another example of someone
going around it.

I just don't see the point.

FWIW, I've never had to live with the customer end of CPUIDs -- only
the vendor end. But I fail to see how they would ever be seen as a
boon by customers.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Barry Merrill]

Long ago I had a phone call from India (proves how long ago this was!) for 
technical support, and it was a one line change I gave
over the phone, saying "put this change in and let me know if there's a problem 
in the morning".  He replied "we won't know until
Saturday, that's when we run SAS jobs", and when I asked why, he said "Well, I 
probably shouldn't tell you, but we haven't paid our
SAS License for several years; every Saturday we IPL with an ancient date and 
run our week's SAS jobs."

MXG's prime motivation to not check CPUID when we created that software in 1984 
was to avoid OUR need to keep track of CPU and to
avoid having to take the time to provide each customer with a new key, so MXG 
Software
has always been a single site license for ALL processors and ALL operating 
systems at the licensed address.

I can recall the shock of many contract-admin folks in those early years when 
they were upgrading to a new CPU when my Vice
President would reply "we don't need your CPUID; it's a site license; you can 
run MXG on anything there, including the coke
machine!"

Also, since MXG was always to be source code distributed, keys would not 
provide any protection!  The combination of the volatility
of the input data to MXG that requires frequent updates, so we can verify your 
license is active, a price so low that it can't be
undercut, so we can distribute the source, and users who know we are "Children 
of the 60's, giving away the keys to the kingdom", so
our users are friends as much as customers, has kept us truckin' for the past 
27 years.
 
And, on the rare occasion where a consolidation did create an unlicensed 
situation, payment for those missed years has always been
forthcoming, and usually because the techie want to make sure WE were paid.

But our primary goal has ALWAYS been to provide the tool set to keep our users 
employed and happy!

Barry Merrill


Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas TX 75229
214 351 1966 tel
214 350 3695 fax
www.mxg.com

P.S.  When the first Gulf War started, one of (or the one?) Australian aircraft 
carrier was hastily deployed, only to discover their
SAS License had expired, leading to a hasty series of radio messages to/from 
SAS Oz to get the new key.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Joel C. Ewing]

On 12/27/2011 07:55 AM, Mark Zelden wrote:

On Mon, 26 Dec 2011 16:11:02 -0500, zMan  wrote:



OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.



Obviously the point of view of someone who doesn't make a living by
selling their software.

I can tell you from personal experience (one of my clients) who I helped
write CPU protection for about 10 years ago that there were many instances
of unauthorized use and in at least one case I know about the abuse was
rampant.   I know a lot of the unauthorized use wasn't intentional, but a
lot of it was also or shops just didn't care since there was no checking.
Some of the companies that used this software outsourced their IT, and
ended up using it on different machines than those that were licensed.
Or the outsourcer copied it to other machines / environments / clients.
My client must have lost hundreds of thousands of dollars in
licensing / maintenance fees and fees from related litigation.

In my own personal experience as a sysprog, I know some of the
same things have happened unintentionally.   Consolidations, moving
LPARs around, creating / cloning new LPARs can lead to this and
when the software doesn't check it's easy for the "techies" to
make mistakes since they often (usually?) don't know the T's and
C's of all the software contracts.

So even though it can be a pain, I actually prefer that any vendor that
cares, checks the CPU id for authorization.   If the software has a "site
license" option, then have a method for a non-cpu specific key to generate
for the client.   Provide an easy way to change the key and a grace
period that won't put the shop's business in jeopardy because of a
missing / wrong key after a CPU upgrade or engine add.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/



Although most of my career was spent with configurations with no more 
than two independent mainframe systems, I can appreciate the additional 
confusion of trying to track inconsistent vendor license terms in a much 
larger environment and how that would raise the probability of 
unintended violations.


Thankfully I've never had direct experience with a company that was in 
process of outsourcing their mainframe operations, so I hadn't 
considered that aspect.  Obviously a company with no reservations about 
shafting its own IT department for short-term profit would probably have 
even less compunction about doing the same to its former software vendors.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Mark Zelden]

On Mon, 26 Dec 2011 16:11:02 -0500, zMan  wrote:

>
>OK, I gotta ask -- what's the problem you're trying to solve? You
>don't trust your customers? In over a quarter century in the mainframe
>software business, I've come across ONE customer running software on
>an unlicensed box, and it was an oversight -- and a nice full-price
>bluebird for the sales rep. I don't believe "CPUIDs" are worth the
>hassle.


Obviously the point of view of someone who doesn't make a living by
selling their software. 

I can tell you from personal experience (one of my clients) who I helped
write CPU protection for about 10 years ago that there were many instances
of unauthorized use and in at least one case I know about the abuse was 
rampant.   I know a lot of the unauthorized use wasn't intentional, but a 
lot of it was also or shops just didn't care since there was no checking.  
Some of the companies that used this software outsourced their IT, and
ended up using it on different machines than those that were licensed. 
Or the outsourcer copied it to other machines / environments / clients. 
My client must have lost hundreds of thousands of dollars in 
licensing / maintenance fees and fees from related litigation.  

In my own personal experience as a sysprog, I know some of the
same things have happened unintentionally.   Consolidations, moving
LPARs around, creating / cloning new LPARs can lead to this and
when the software doesn't check it's easy for the "techies" to 
make mistakes since they often (usually?) don't know the T's and
C's of all the software contracts.   

So even though it can be a pain, I actually prefer that any vendor that
cares, checks the CPU id for authorization.   If the software has a "site
license" option, then have a method for a non-cpu specific key to generate
for the client.   Provide an easy way to change the key and a grace
period that won't put the shop's business in jeopardy because of a 
missing / wrong key after a CPU upgrade or engine add.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Joel C. Ewing]

If you use CPUID and get the value that varies by LPAR, be sure to 
exclude from validation the digit that is LPAR-dependent  - having 
different authentication codes for a PROD vs. TEST LPAR means there is 
no way to test an authentication code without going live; and I second 
the need to support multiple CPUIDs, both to cover upgrades and allow 
multiple licensed CPUs at a site to use shared product files.


If validation is a must, suggest "Nag" alerts with continued full 
functionality at least a month in advance when license expiration 
approaches, or for the duration of the license on an incorrect CPUID to 
minimize client exposure during CPU upgrades or actual DR and minimize 
busywork with DR testing.  But don't flood system console with nag 
messages (especially highlighted ones), and if a highlighted console 
message, preferably at most one a day and in 8-5 time frame would be 
appreciated rather than someone getting an unnecessary midnight call.


Then there's always the "radical" approach of just using external means 
(e.g., letters, bills) to remind of license renewal requirements. 
Mainframe shops are used to paying for software, and none that I have 
dealt with would have condoned deliberate circumvention of licensing 
requirements.


Depending on the nature of the product, inability to get maintenance for 
an unlicensed product could be sufficient to eventually disable the 
product.  Since most z/OS shops must update z/OS at least every two 
years to keep current, perhaps building in a product maintenance 
requirement to update the maximum supported release of z/OS would be 
sufficient to force eventual product expiration if it is not under a 
maintenance contract.

  J C Ewing


On 12/26/2011 03:19 PM, Sam Siegel wrote:

zMan - Thanks for the reply.  It is a new product - No customers yet.

I would like enough licensing to keep honest people honest and an
operationally oriented reminder for the annual renewal.

Sam

On Mon, Dec 26, 2011 at 1:11 PM, zMan  wrote:


Gahh, "IF BibBox, Inc".

On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:

On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:

Hello List - I'm attempting to create a licensing mechanism for a bit
of software.  I would like to be able to use a unique and
non-modifiable identifier as part of the mechanism.

The CSRSI callable service and STSI instruction provide a variety of
hardware related identifiers.

CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.

  These

appear directly related to PCCACPID (PCCA control block) and Sequence

Code

(STSI basic machine configuration)..

Is there any preference to using one field over the other?  What are the
advantages and disadvantages of using each field?

Are there other fields (in same or other control blocks) that should be
used?

Please feel free to treat this as an open ended question related to
licensing mechanism and provided any related advice and tips based on
experience.


OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.

Having said that, I would expect that any CPUID processing would work
off, well, the CPUID. That's what customers understand.

SAS Institute used to have a nice CPUID system for their C compiler
that would issue a warning and print out what company the sucker was
licensed to, but would continue to operate if the CPUID was wrong.
This allowed emergency operation, while clearly keeping any real
company from running it on the wrong box (though I suppose of BigBox,
Inc. licensed it on one and ran it on two, it would be harder to
notice; the case I'm thinking of was when we were running the
Merrill-Lynch copy on another company's machine, WITH permission from
SAS; every time we invoked the compiler, it would whine and say
"Licensed to Merrill-Lynch").

Now, with systems management stuff that doesn't have a real UI that
gets invoked all the time, it's harder. The best I've seen allowed:
- multiple key entries in the CPUID file, so you didn't have to worry
about swapping files at expiration: you just added new entries and
eventually deleted the old ones. And you could keep all your CPUIDs in
a common file, shared (or replicated) across systems.
- Warned starting 30 days before expiration, on the operator's
console: "XYZ will expire in 30 days" (29, 28...).
- If it had a valid license (i.e., one with time on it but on the
wrong machine) would run in "emergency mode", whining on the
operator's console every 10 minutes or so, but still running (this
allowed for DR).
- Supported "universal" temporary keys, that could be
read/emailed/FAXed by support at 3AM if you really screwed up and were
dead in the water despite the above.

Now, this also meant that there

Re: cpu / machine identification

[Bernd Oppolzer]

For our system, we have the need to create UUIDs, which contain in the 
right part a twelve
byte hex number which identifies the machine uniquely world-wide (at 
least, that's the idea).

The left part is a (kind of) inverted timestamp.

We do this using some information from CSRSI and the LPAR number. On 
other platforms
like Unix and Windows this is done using the MAC address of the network 
controller.


If you're interested, I can try to extract the rules from the C source. 
IIRC, it's the machine serial

number, followed by the LPAR number.

Kind regards

Bernd



Am 26.12.2011 20:22, schrieb Sam Siegel:

Hello List - I'm attempting to create a licensing mechanism for a bit
of software.  I would like to be able to use a unique and
non-modifiable identifier as part of the mechanism.

The CSRSI callable service and STSI instruction provide a variety of
hardware related identifiers.

CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.  These
appear directly related to PCCACPID (PCCA control block) and Sequence Code
(STSI basic machine configuration)..

Is there any preference to using one field over the other?  What are the
advantages and disadvantages of using each field?

Are there other fields (in same or other control blocks) that should be
used?

Please feel free to treat this as an open ended question related to
licensing mechanism and provided any related advice and tips based on
experience.

Thanks,
Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Sam Siegel]

zMan - Thanks for the reply.  It is a new product - No customers yet.

I would like enough licensing to keep honest people honest and an
operationally oriented reminder for the annual renewal.

Sam

On Mon, Dec 26, 2011 at 1:11 PM, zMan  wrote:

> Gahh, "IF BibBox, Inc".
>
> On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:
> > On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:
> >> Hello List - I'm attempting to create a licensing mechanism for a bit
> >> of software.  I would like to be able to use a unique and
> >> non-modifiable identifier as part of the mechanism.
> >>
> >> The CSRSI callable service and STSI instruction provide a variety of
> >> hardware related identifiers.
> >>
> >> CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.
>  These
> >> appear directly related to PCCACPID (PCCA control block) and Sequence
> Code
> >> (STSI basic machine configuration)..
> >>
> >> Is there any preference to using one field over the other?  What are the
> >> advantages and disadvantages of using each field?
> >>
> >> Are there other fields (in same or other control blocks) that should be
> >> used?
> >>
> >> Please feel free to treat this as an open ended question related to
> >> licensing mechanism and provided any related advice and tips based on
> >> experience.
> >
> > OK, I gotta ask -- what's the problem you're trying to solve? You
> > don't trust your customers? In over a quarter century in the mainframe
> > software business, I've come across ONE customer running software on
> > an unlicensed box, and it was an oversight -- and a nice full-price
> > bluebird for the sales rep. I don't believe "CPUIDs" are worth the
> > hassle.
> >
> > Having said that, I would expect that any CPUID processing would work
> > off, well, the CPUID. That's what customers understand.
> >
> > SAS Institute used to have a nice CPUID system for their C compiler
> > that would issue a warning and print out what company the sucker was
> > licensed to, but would continue to operate if the CPUID was wrong.
> > This allowed emergency operation, while clearly keeping any real
> > company from running it on the wrong box (though I suppose of BigBox,
> > Inc. licensed it on one and ran it on two, it would be harder to
> > notice; the case I'm thinking of was when we were running the
> > Merrill-Lynch copy on another company's machine, WITH permission from
> > SAS; every time we invoked the compiler, it would whine and say
> > "Licensed to Merrill-Lynch").
> >
> > Now, with systems management stuff that doesn't have a real UI that
> > gets invoked all the time, it's harder. The best I've seen allowed:
> > - multiple key entries in the CPUID file, so you didn't have to worry
> > about swapping files at expiration: you just added new entries and
> > eventually deleted the old ones. And you could keep all your CPUIDs in
> > a common file, shared (or replicated) across systems.
> > - Warned starting 30 days before expiration, on the operator's
> > console: "XYZ will expire in 30 days" (29, 28...).
> > - If it had a valid license (i.e., one with time on it but on the
> > wrong machine) would run in "emergency mode", whining on the
> > operator's console every 10 minutes or so, but still running (this
> > allowed for DR).
> > - Supported "universal" temporary keys, that could be
> > read/emailed/FAXed by support at 3AM if you really screwed up and were
> > dead in the water despite the above.
> >
> > Now, this also meant that there were folks carrying beepers and temp
> > keys, so they could do that after-hours support.
> >
> > Are you prepared to deal with all this? Is it worth it?
> >
> > As you can tell, I'm not a fan of such mechanisms. But it's not my
> > decision (doh), so I'm trying to help :-)
> > --
> > zMan -- "I've got a mainframe and I'm not afraid to use it"
>
>
>
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

And one more thing: moderately forgiving formatting would be good.
This won't be an issue on z, of course, but I remember one CPUID
scheme on Linux that insisted on UNIX-style linends (even though the
data was a single line). So if you emailed a key to someone whose
email was on a Windows box, and they transferred the data as binary
(which it was -- also stupid), the key would look OK to the naked eye
but would fail.

If it's a bunch of hex pairs (8F3D2C11 etc.), support 8-nibble
groupings *or* single tokens. The latter are easier to cut & paste.
Etc.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

Gahh, "IF BibBox, Inc".

On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:
> On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:
>> Hello List - I'm attempting to create a licensing mechanism for a bit
>> of software.  I would like to be able to use a unique and
>> non-modifiable identifier as part of the mechanism.
>>
>> The CSRSI callable service and STSI instruction provide a variety of
>> hardware related identifiers.
>>
>> CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.  These
>> appear directly related to PCCACPID (PCCA control block) and Sequence Code
>> (STSI basic machine configuration)..
>>
>> Is there any preference to using one field over the other?  What are the
>> advantages and disadvantages of using each field?
>>
>> Are there other fields (in same or other control blocks) that should be
>> used?
>>
>> Please feel free to treat this as an open ended question related to
>> licensing mechanism and provided any related advice and tips based on
>> experience.
>
> OK, I gotta ask -- what's the problem you're trying to solve? You
> don't trust your customers? In over a quarter century in the mainframe
> software business, I've come across ONE customer running software on
> an unlicensed box, and it was an oversight -- and a nice full-price
> bluebird for the sales rep. I don't believe "CPUIDs" are worth the
> hassle.
>
> Having said that, I would expect that any CPUID processing would work
> off, well, the CPUID. That's what customers understand.
>
> SAS Institute used to have a nice CPUID system for their C compiler
> that would issue a warning and print out what company the sucker was
> licensed to, but would continue to operate if the CPUID was wrong.
> This allowed emergency operation, while clearly keeping any real
> company from running it on the wrong box (though I suppose of BigBox,
> Inc. licensed it on one and ran it on two, it would be harder to
> notice; the case I'm thinking of was when we were running the
> Merrill-Lynch copy on another company's machine, WITH permission from
> SAS; every time we invoked the compiler, it would whine and say
> "Licensed to Merrill-Lynch").
>
> Now, with systems management stuff that doesn't have a real UI that
> gets invoked all the time, it's harder. The best I've seen allowed:
> - multiple key entries in the CPUID file, so you didn't have to worry
> about swapping files at expiration: you just added new entries and
> eventually deleted the old ones. And you could keep all your CPUIDs in
> a common file, shared (or replicated) across systems.
> - Warned starting 30 days before expiration, on the operator's
> console: "XYZ will expire in 30 days" (29, 28...).
> - If it had a valid license (i.e., one with time on it but on the
> wrong machine) would run in "emergency mode", whining on the
> operator's console every 10 minutes or so, but still running (this
> allowed for DR).
> - Supported "universal" temporary keys, that could be
> read/emailed/FAXed by support at 3AM if you really screwed up and were
> dead in the water despite the above.
>
> Now, this also meant that there were folks carrying beepers and temp
> keys, so they could do that after-hours support.
>
> Are you prepared to deal with all this? Is it worth it?
>
> As you can tell, I'm not a fan of such mechanisms. But it's not my
> decision (doh), so I'm trying to help :-)
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

Wow, I can't seem to type OR read today. You get what I mean tho.

On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:
> Gahh, "IF BibBox, Inc".

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[zMan]

On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:
> Hello List - I'm attempting to create a licensing mechanism for a bit
> of software.  I would like to be able to use a unique and
> non-modifiable identifier as part of the mechanism.
>
> The CSRSI callable service and STSI instruction provide a variety of
> hardware related identifiers.
>
> CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.  These
> appear directly related to PCCACPID (PCCA control block) and Sequence Code
> (STSI basic machine configuration)..
>
> Is there any preference to using one field over the other?  What are the
> advantages and disadvantages of using each field?
>
> Are there other fields (in same or other control blocks) that should be
> used?
>
> Please feel free to treat this as an open ended question related to
> licensing mechanism and provided any related advice and tips based on
> experience.

OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.

Having said that, I would expect that any CPUID processing would work
off, well, the CPUID. That's what customers understand.

SAS Institute used to have a nice CPUID system for their C compiler
that would issue a warning and print out what company the sucker was
licensed to, but would continue to operate if the CPUID was wrong.
This allowed emergency operation, while clearly keeping any real
company from running it on the wrong box (though I suppose of BigBox,
Inc. licensed it on one and ran it on two, it would be harder to
notice; the case I'm thinking of was when we were running the
Merrill-Lynch copy on another company's machine, WITH permission from
SAS; every time we invoked the compiler, it would whine and say
"Licensed to Merrill-Lynch").

Now, with systems management stuff that doesn't have a real UI that
gets invoked all the time, it's harder. The best I've seen allowed:
- multiple key entries in the CPUID file, so you didn't have to worry
about swapping files at expiration: you just added new entries and
eventually deleted the old ones. And you could keep all your CPUIDs in
a common file, shared (or replicated) across systems.
- Warned starting 30 days before expiration, on the operator's
console: "XYZ will expire in 30 days" (29, 28...).
- If it had a valid license (i.e., one with time on it but on the
wrong machine) would run in "emergency mode", whining on the
operator's console every 10 minutes or so, but still running (this
allowed for DR).
- Supported "universal" temporary keys, that could be
read/emailed/FAXed by support at 3AM if you really screwed up and were
dead in the water despite the above.

Now, this also meant that there were folks carrying beepers and temp
keys, so they could do that after-hours support.

Are you prepared to deal with all this? Is it worth it?

As you can tell, I'm not a fan of such mechanisms. But it's not my
decision (doh), so I'm trying to help :-)
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

cpu / machine identification

[Sam Siegel]

Hello List - I'm attempting to create a licensing mechanism for a bit
of software.  I would like to be able to use a unique and
non-modifiable identifier as part of the mechanism.

The CSRSI callable service and STSI instruction provide a variety of
hardware related identifiers.

CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.  These
appear directly related to PCCACPID (PCCA control block) and Sequence Code
(STSI basic machine configuration)..

Is there any preference to using one field over the other?  What are the
advantages and disadvantages of using each field?

Are there other fields (in same or other control blocks) that should be
used?

Please feel free to treat this as an open ended question related to
licensing mechanism and provided any related advice and tips based on
experience.

Thanks,
Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN