I guess I’m not really explaining myself too well here. Firstly, I'm not suggesting doing anything illegal or anything that would violate any licensing agreements. (Jiminy Crickets, what sort of person do you think I am?)
In z/VM, I there is a command SET CPUID, that will change the CPU identifier for a virtual processor. As our DR runs a z/OS guest under z/VM. we have considered using this feature in order to not have to change the license keys for a number of products. We're already licensed to run at the site by all vendors. Some products have no license keys, so no problem. Others, like those provided by CA will issue a "nasty-gram" about an incorrect key, but will allow us to run, so still no problem. A few however, require a new key. A certain amount of "angst" occurs in obtaining and applying those keys. Yes, I suppose it is a customer service, documentation, training the staff, issue ... but it is an issue. One that I'd like to circumvent if I can. According to all our vendors, this does not violate or software agreement(s). Asking the vendors where they obtain the CPU identifier in order to validate their keys is proving somewhat difficult as in many cases, Level One support honestly doesn't know. I know I can just "run this and see what happens" but I was curious if there was a way to determine beforehand where or how a product was pulling the CPU identifier in order to validate their key. Anne R. Adams, CISSP DTI, Systems Engineering Sr. Mainframe Services Analyst 302.298.3196 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Longabaugh, Robert E Sent: Wednesday, September 14, 2016 5:54 PM To: [email protected] Subject: CA Technologies LMP key at DR sites (WAS: serial numbers ... real and imagine) Here are selected results from a search on "disaster recovery lmp site:ca.com". These Knowledge Base articles should clarify that recovery can proceed without having the correct recovery site LMP key in advance of a disaster drill, or if the CPU serial is different than the one that the LMP key was generated for. These articles were written by different product groups but apply across the board since products call CA Common Services for LMP checking. What will happen if I don't have valid LMPKEYs for my Disaster Recovery site? http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec471961.aspx How can LMP keys be obtained in an emergency? http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec476815.aspx Bob Longabaugh CA Technologies Storage Management -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steve Sent: Wednesday, September 14, 2016 2:05 PM To: [email protected] Subject: Re: serial numbers ... real and imagine Must of us have too many ethics to violate anything associated with M/F Licensing Steve -----Original Message----- From: "Dana Mitchell" <[email protected]> Sent: Wednesday, September 14, 2016 2:55pm To: [email protected] Subject: Re: serial numbers ... real and imagine Falls under one of my favorite sayings: Never ascribe to malice that which can be adequately explained by stupidity. Or the British version: cock-up before conspiracy Dana >On Wed, Sep 14, 2016 at 11:48 AM, Charles Mills <[email protected]> wrote: > >> Speaking as a vendor here -- and at the risk of flames -- it's not >> just "bad" customers. With the amount of outsourcing, turnover, >> overwork and layoffs of skilled people we were seeing a fair amount of >> "inadvertent" >> license violation before we implemented the serial number check. >> Junior sysprogs or managers who just assumed they could install the >> software on another LPAR. >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
