Re: cpu / machine identification
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 brian_wester...@syzygyinc.com 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 scott_j_f...@yahoo.com 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 joa...@swbell.net 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: SV: cpu / machine identification
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 bfairch...@rocketsoftware.com 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
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 zedgarhoo...@gmail.com 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 bfairch...@rocketsoftware.com 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; cpu / machine identification
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
-snip--: Zman, In that case a .45 automatic and a big dog comes in handy, lol , sorry just couldn't resist.. Regards, Scott unsnip--- 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: SV: cpu / machine identification
Rick, Like your style Sent from my iPad On Jan 3, 2012, at 5:23 PM, Rick Fochtman rfocht...@ync.net wrote: -snip--: Zman, In that case a .45 automatic and a big dog comes in handy, lol , sorry just couldn't resist.. Regards, Scott unsnip--- 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
SV: SV: cpu / machine identification
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 thomas.b...@swedbank.se 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
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 ba...@mxg.com To: IBM-MAIN@bama.ua.edu, Date: 01/01/2012 17:53 Subject: Re: cpu / machine identification Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 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 brian_wester...@syzygyinc.com 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
Re: cpu / machine identification
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 joa...@swbell.net 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
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 scott_j_f...@yahoo.com 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 joa...@swbell.net 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
On Sat, Dec 31, 2011 at 11:16 PM, Edward Jaffe edja...@phoenixsoftware.com 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
In 9920027903334789.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/31/2011 at 06:43 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
Re: cpu / machine identification
In 9693770902631563.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/31/2011 at 06:51 PM, Brian Westerman brian_wester...@syzygyinc.com 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
Re: cpu / machine identification
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 brian_wester...@syzygyinc.com 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.) shmuel+ibm-m...@patriot.net wrote: In 9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/29/2011 at 08:29 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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 -- 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
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 brian_wester...@syzygyinc.com 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
On 1/1/2012 6:37 AM, Mike Schwab wrote: On Sat, Dec 31, 2011 at 11:16 PM, Edward Jaffe edja...@phoenixsoftware.com 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
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
In 8724193196442157.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/29/2011 at 08:03 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
Re: cpu / machine identification
In cajtoo5-kjv_9ilhjagbqxfjaazyefkjdt8xrcrvvpnpuug0...@mail.gmail.com, on 12/29/2011 at 11:11 PM, Mike Schwab mike.a.sch...@gmail.com 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 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
Re: cpu / machine identification
In 0713029417803027.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/29/2011 at 08:42 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
Re: cpu / machine identification
In 9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/29/2011 at 08:29 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
Re: cpu / machine identification
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 jch...@ussco.com 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
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.) shmuel+ibm-m...@patriot.net wrote: In 8724193196442157.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/29/2011 at 08:03 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
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 hal9...@panix.com 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
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 brian_wester...@syzygyinc.com 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 hal9...@panix.com 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
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.) shmuel+ibm-m...@patriot.net wrote: In 9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/29/2011 at 08:29 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
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.) shmuel+ibm-m...@patriot.net wrote: In cajtoo5-kjv_9ilhjagbqxfjaazyefkjdt8xrcrvvpnpuug0...@mail.gmail.com, on 12/29/2011 at 11:11 PM, Mike Schwab mike.a.sch...@gmail.com 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 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
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 mike.a.sch...@gmail.com 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 brian_wester...@syzygyinc.com 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 hal9...@panix.com 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
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 brian_wester...@syzygyinc.com 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
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
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
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
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. rex.pomm...@cnasurety.com 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: SV: cpu / machine identification
Seems sort of counter-intuitive. :) Brian On Thu, 29 Dec 2011 10:35:21 +0100, Thomas Berg thomas.b...@swedbank.se 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
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 joa...@swbell.net 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: cpu / machine identification
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 m42tom-ibmm...@yahoo.com 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
-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
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
SV: cpu / machine identification
-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
Count your fingers ... was cpu / machine identification
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
Re: cpu / machine identification
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
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. rex.pomm...@cnasurety.com 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
On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford scott_j_f...@yahoo.com 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
In 7026723933836234.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/28/2011 at 07:58 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
Re: cpu / machine identification
On 28 December 2011 20:58, Brian Westerman brian_wester...@syzygyinc.com 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 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 zedgarhoo...@gmail.com wrote: On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford scott_j_f...@yahoo.com 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
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
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 - testing quote
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
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 brian_wester...@syzygyinc.com 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
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.) shmuel+ibm-m...@patriot.net wrote: In 7026723933836234.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/28/2011 at 07:58 PM, Brian Westerman brian_wester...@syzygyinc.com 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 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
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. rex.pomm...@cnasurety.com 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
Re: cpu / machine identification
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 t...@harminc.net wrote: On 28 December 2011 20:58, Brian Westerman brian_wester...@syzygyinc.com 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
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 scott_j_f...@yahoo.com 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 zedgarhoo...@gmail.com wrote: On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford scott_j_f...@yahoo.com 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
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
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 scott_j_f...@yahoo.com 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 zedgarhoo...@gmail.com wrote: On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford scott_j_f...@yahoo.com 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
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
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 g, 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 brian_wester...@syzygyinc.com 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 scott_j_f...@yahoo.com 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 zedgarhoo...@gmail.com wrote: On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford scott_j_f...@yahoo.com 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
Re: cpu / machine identification
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
On Thu, Dec 29, 2011 at 9:14 PM, John McKown joa...@swbell.net 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
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 zedgarhoo...@gmail.com wrote: Gahh, IF BibBox, Inc. On Mon, Dec 26, 2011 at 4:11 PM, zMan zedgarhoo...@gmail.com wrote: On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel s...@pscsi.net 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
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
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
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
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
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
On Wed, Dec 28, 2011 at 9:02 PM, Brian Westerman brian_wester...@syzygyinc.com 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
On Wed, 28 Dec 2011 21:51:42 -0500 zMan wrote: re Brian Westerman 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
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
On Mon, 26 Dec 2011 16:11:02 -0500, zMan zedgarhoo...@gmail.com 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
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, zManzedgarhoo...@gmail.com wrote: Gahh, IF BibBox, Inc. On Mon, Dec 26, 2011 at 4:11 PM, zManzedgarhoo...@gmail.com wrote: On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegels...@pscsi.net 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
Re: cpu / machine identification
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
On 12/27/2011 07:55 AM, Mark Zelden wrote: On Mon, 26 Dec 2011 16:11:02 -0500, zManzedgarhoo...@gmail.com 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
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
On Tue, Dec 27, 2011 at 8:55 AM, Mark Zelden m...@mzelden.com 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
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 Zeldenm...@mzelden.com 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
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 zedgarhoo...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 12/27/2011 10:43 AM Subject:Re: cpu / machine identification Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Tue, Dec 27, 2011 at 8:55 AM, Mark Zelden m...@mzelden.com 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
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 zedgarhoo...@gmail.com wrote: Gahh, IF BibBox, Inc. On Mon, Dec 26, 2011 at 4:11 PM, zMan zedgarhoo...@gmail.com wrote: On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel s...@pscsi.net 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
-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
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
Re: cpu / machine identification
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 m...@mzelden.com 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
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
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
In cafmxnwkun21ydhzuvbvrececbcrqci1ybm_v75cqb+vkeha...@mail.gmail.com, on 12/26/2011 at 11:22 AM, Sam Siegel s...@pscsi.net 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 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
cpu / machine identification
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
Re: cpu / machine identification
On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel s...@pscsi.net 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
Re: cpu / machine identification
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 zedgarhoo...@gmail.com 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
Gahh, IF BibBox, Inc. On Mon, Dec 26, 2011 at 4:11 PM, zMan zedgarhoo...@gmail.com wrote: On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel s...@pscsi.net 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
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 - 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 zedgarhoo...@gmail.com wrote: Gahh, IF BibBox, Inc. On Mon, Dec 26, 2011 at 4:11 PM, zMan zedgarhoo...@gmail.com wrote: On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel s...@pscsi.net 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
